[PATCH 2/2] drm/radeon: remove bapm callbacks

[Deucher, Alexander]

> -Original Message-
> From: Lucas Stach [mailto:dev at lynxeye.de]
> Sent: Thursday, April 23, 2015 5:28 PM
> To: Deucher, Alexander; Koenig, Christian; David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 2/2] drm/radeon: remove bapm callbacks
> 
> Trying to disable BAPM on battery power does not fix the problematic
> Trinity mobile parts. Fixing those probably need a more complex solution,
> like doing a complete reinit of the DPM state. This will take more work
> and most likely it will not be possible to map this to a single callback.
> 
> Even worse trying to change the BAPM state mid flight is breaking BAPM
> on Richland mobile parts that are otherwise completely stable with BAPM
> enabled.

Do you have any examples of this?  This was added to fix bapm stability on 
mobile parts and did help on a number of systems.  Bapm is disabled by default 
since it is so problematic on a lot of systems.  Ripping all of this out 
doesn't seem like it will really help anything.

Alex

> 
> As there are no users of this hook anymore we can just remove the calling
> infrastructure.
> 
> Signed-off-by: Lucas Stach 
> ---
> I've did some pretty extensive tests with one of the problematic Trinity
> mobile parts. I was able to figure out a stable config with BAPM enabled
> for this, but unfortunately the power consumption rose quite a bit. So on
> Trinity one has to disable BAPM while on battery power. I found a sequence

Can you elaborate on this?  This seems to contradict what the patch does.

> to enable/disable BAPM mid flight without hanging the GPU, but the SMC
> seemed to be stuck after that, as no DPM power level changes were
> happening
> anymore.
> ---
>  drivers/gpu/drm/radeon/radeon.h  |  2 --
>  drivers/gpu/drm/radeon/radeon_asic.c |  1 -
>  drivers/gpu/drm/radeon/radeon_asic.h |  1 -
>  drivers/gpu/drm/radeon/radeon_pm.c   |  4 
>  drivers/gpu/drm/radeon/trinity_dpm.c | 11 ---
>  5 files changed, 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon.h
> b/drivers/gpu/drm/radeon/radeon.h
> index 33d5a4f..93659d2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1980,7 +1980,6 @@ struct radeon_asic {
>   int (*force_performance_level)(struct radeon_device *rdev,
> enum radeon_dpm_forced_level level);
>   bool (*vblank_too_short)(struct radeon_device *rdev);
>   void (*powergate_uvd)(struct radeon_device *rdev, bool
> gate);
> - void (*enable_bapm)(struct radeon_device *rdev, bool
> enable);
>   void (*fan_ctrl_set_mode)(struct radeon_device *rdev, u32
> mode);
>   u32 (*fan_ctrl_get_mode)(struct radeon_device *rdev);
>   int (*set_fan_speed_percent)(struct radeon_device *rdev,
> u32 speed);
> @@ -2949,7 +2948,6 @@ static inline void radeon_ring_write(struct
> radeon_ring *ring, uint32_t v)
>  #define radeon_dpm_force_performance_level(rdev, l) rdev->asic-
> >dpm.force_performance_level((rdev), (l))
>  #define radeon_dpm_vblank_too_short(rdev) rdev->asic-
> >dpm.vblank_too_short((rdev))
>  #define radeon_dpm_powergate_uvd(rdev, g) rdev->asic-
> >dpm.powergate_uvd((rdev), (g))
> -#define radeon_dpm_enable_bapm(rdev, e) rdev->asic-
> >dpm.enable_bapm((rdev), (e))
> 
>  /* Common functions */
>  /* AGP */
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 2a33e38..fa11abc 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1818,7 +1818,6 @@ static struct radeon_asic trinity_asic = {
>   .print_power_state = _dpm_print_power_state,
>   .debugfs_print_current_performance_level =
> _dpm_debugfs_print_current_performance_level,
>   .force_performance_level =
> _dpm_force_performance_level,
> - .enable_bapm = _dpm_enable_bapm,
>   },
>   .pflip = {
>   .page_flip = _page_flip,
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 85d76da..605be51 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -673,7 +673,6 @@ void
> trinity_dpm_debugfs_print_current_performance_level(struct
> radeon_device *r
>struct seq_file *m);
>  int trinity_dpm_force_performance_level(struct radeon_device *rdev,
>   enum radeon_dpm_forced_level
> level);
> -void trinity_dpm_enable_bapm(struct radeon_device *rdev, bool enable);
> 
>  /* DCE6 - SI */
>  void dce6_bandwidth_update(struct radeon_device *rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index c1ba83a..a78d146 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -74,10 +74,6 @@ void radeon_pm_acpi_event_handler(struct
> radeon_device *rdev)
>  

git pull] drm for v4.1-rc1

[Alex Deucher]

On Thu, Apr 23, 2015 at 5:30 PM, Bjorn Helgaas  wrote:
> [+cc Matthew]
>
> On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
>> Hmm. The odd Intel PCI resource mess is back.
>>
>> Or maybe it never went away.
>>
>> I get these when suspending. Things *work*, but it's really spamming
>> my logs a fair bit:
>>
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   pci_bus :01: Allocating resources
>>   pci_bus :02: Allocating resources
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>
>> That resource is complete garbage. "flags 0x2" is not even a valid
>> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
>> that is valid, then it should also have have had the IORESOURCE_MEM
>> bit, and it doesn't.
>
> Your i915 does not have a ROM BAR in hardware.  If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
> shadow ROM image at 0xC.  Is there a shadow image even if the
> device itself doesn't have a ROM BAR?

Very likely yes.  With integrated APUs and mobile dGPUs, the vbios
image is often stored as part of the system rom rather than as a
dedicated rom for the GPU.  The vbios image is then copied to the
shadow location during sbios init to provide OS access to the rom.

Alex

>
> We could fabricate a resource even if the BAR doesn't exist, e.g.,
> "flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
> would be ugly and error-prone in other places that use the ROM.
>
> Matthew added dev->rom for ROM images supplied by the platform
> (84c1b80e3263 ("PCI: Add support for non-BAR ROMs")).  A shadow
> image seems like a similar thing.  I think it would be cleaner to get
> rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
> 0xC" if there's a shadow image, e.g.:
>
>   int pcibios_add_device(struct pci_dev *dev)
>   {
> if (dev-is-default-vga-device) {
>   dev->rom = 0xC;
>   dev->romlen = 0x2;
> }
>
> pa_data = boot_params.hdr.setup_data;
> while (pa_data) {
>   ...
>   if (data->type == SETUP_PCI) {
> rom = (struct pci_setup_rom *)data;
>
> if (dev-is-rom-dev) {
>   dev->rom = ...
>   dev->romlen = rom->pcilen;
> }
>   }
> }
>
> But the rules for figuring out which image to use seem ...
> complicated.
>
> Bjorn
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH v2] drm/i915: cope with large i2c transfers

[Daniel Vetter]

On Tue, Apr 21, 2015 at 10:12:19AM -0700, Linus Torvalds wrote:
> On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
>  wrote:
> > The hardware, according to the specs, is limited to 256 byte transfers,
> > and current driver has no protections in case users attempt to do larger
> > transfers. The code will just stomp over status register and mayhem
> > ensues.
> 
> Thanks, looks good.
> 
> David/Daniel - should I take this directly, or can I expect to just
> get it from the drm tree?

I asked Jani to pick this up. I'm horribly jetlagged and just repacking
for my vacation so probably shouldn't touch git branches right now ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH -next] drm/i915/audio: remove duplicated include from intel_audio.c

[Daniel Vetter]

On Wed, Apr 22, 2015 at 10:50:55AM +0800, John Hunter wrote:
> Sure, but I need Daniel to admit that, because maybe include the two header
> file make it easier to understand.
> And after checked other files in drm/i915, I found that a lot other file do
> the
> same thing(include both header file). So I will just wait Daniel to wait up
> and
> give me the order :-)

drm/i915 headers are a bit a chaos anyway, so I'm not sure how useful that
would be really. And generally the trend in linux (and drm) is to have
split-up headers, so moving everyone to just include intel_drv.h would be
the "wrong" direction.

tbh I just don't have an opinion really ;-)
-Daniel

> 
> On Wed, Apr 22, 2015 at 10:35 AM, yongjun_wei at trendmicro.com.cn <
> yongjun_wei at trendmicro.com.cn> wrote:
> 
> >  Hi John,
> >
> >
> >
> > Feel free to submit a new patch.
> >
> >
> >
> > Regards,
> >
> > Yongjun Wei
> >
> >
> >
> > *From:* John Hunter [mailto:zhjwpku at gmail.com]
> > *Sent:* 2015年4月22日 10:30
> > *To:* weiyj_lk at 163.com; Daniel Vetter; Jani Nikula; David Airlie; Yongjun
> > Wei (RD-CN); intel-gfx at lists.freedesktop.org;
> > dri-devel at lists.freedesktop.org; open list
> > *Subject:* Re: [Intel-gfx] [PATCH -next] drm/i915/audio: remove
> > duplicated include from intel_audio.c
> >
> >
> >
> > Hi,
> >
> >
> >
> > I think maybe we should remove both of the two lines:
> >
> > #include "intel_drv.h"
> >
> > #include "i915_drv.h"
> >
> > Because we have* two* "intel_drv.h" and *one* "i915_drv.h", and
> >
> > "i915_drv.h" has already been included in the "intel_drv.h".
> >
> >
> >
> > I not sure whether i am right. If you need me to do the patch,
> >
> > let me know.
> >
> >
> >
> >
> >
> > On Thu, Apr 16, 2015 at 10:30 PM, Daniel Vetter  wrote:
> >
> > On Thu, Apr 16, 2015 at 09:11:08PM +0800, weiyj_lk at 163.com wrote:
> > > From: Wei Yongjun 
> > >
> > > Remove duplicated include.
> > >
> > > Signed-off-by: Wei Yongjun 
> >
> > Queued for -next, thanks for the patch.
> > -Daniel
> >
> > > ---
> > >  drivers/gpu/drm/i915/intel_audio.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 2396cc7..d00d488 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -28,7 +28,6 @@
> > >
> > >  #include 
> > >  #include 
> > > -#include "intel_drv.h"
> > >  #include "i915_drv.h"
> > >
> > >  /**
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> >
> >
> > --
> >
> > Best regards
> >
> > Junwang Zhao
> >
> > Microprocessor Research and Develop Center
> >
> > Department of Computer Science 
> >
> > Peking University
> >
> > Beijing, 100871, PRC
> >
> > ===
> >
> > This message has been analyzed by Deep Discovery Email Inspector.
> >
> >
> >
> > TREND MICRO EMAIL NOTICE
> > The information contained in this email and any attachments is confidential
> > and may be subject to copyright or other intellectual property protection.
> > If you are not the intended recipient, you are not authorized to use or
> > disclose this information, and we request that you notify us by reply mail 
> > or
> > telephone and delete the original message from your mail system.
> >
> >
> 
> 
> -- 
> Best regards
> Junwang Zhao
> Microprocessor Research and Develop Center
> Department of Computer Science 
> Peking University
> Beijing, 100871, PRC

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


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

[PATCH] amdkfd: Remove unessary void pointer cast

[Firo Yang]

kmalloc() returns a void pointer - no need to cast it in
drivers/gpu/drm/amd/amdkfd/kfd_process.c::kfd_process_destroy_delayed()

Signed-off-by: Firo Yang 
---
 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 945d622..4d7bc95 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -203,8 +203,7 @@ static void kfd_process_destroy_delayed(struct rcu_head 
*rcu)

mmdrop(p->mm);

-   work = (struct kfd_process_release_work *)
-   kmalloc(sizeof(struct kfd_process_release_work), GFP_ATOMIC);
+   work = kmalloc(sizeof(struct kfd_process_release_work), GFP_ATOMIC);

if (work) {
INIT_WORK((struct work_struct *) work, kfd_process_wq_release);
-- 
2.1.0

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

San Zamoyski  changed:

   What|Removed |Added

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

--- Comment #20 from San Zamoyski  ---
Works fine now with:

glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD ARUBA
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel
(git-9450bd5 2015-04-22 trusty-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.6.0-devel (git-9450bd5 2015-04-22
trusty-oibaf-ppa)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.0-devel (git-9450bd5
2015-04-22 trusty-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Thanks!

-- 
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/20150423/435e30bf/attachment.html>

[PATCH 2/2] amdgpu: add public bo list interface v2

[Christian König]

From: Christian König 

v2: cleanup comments and function parameter

Signed-off-by: Christian König 
Reviewed-by: Jammy Zhou 
Reviewed-by: Alex Deucher 
---
 amdgpu/amdgpu.h| 51 --
 amdgpu/amdgpu_bo.c | 56 +
 amdgpu/amdgpu_cs.c | 77 +++---
 amdgpu/amdgpu_internal.h   |  6 
 tests/amdgpu/basic_tests.c |  8 +++--
 tests/amdgpu/cs_tests.c| 12 ++--
 6 files changed, 123 insertions(+), 87 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 7a85982..66e5df0 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -166,6 +166,11 @@ typedef struct amdgpu_context *amdgpu_context_handle;
 typedef struct amdgpu_bo *amdgpu_bo_handle;

 /**
+ * Define handle for list of BOs
+ */
+typedef struct amdgpu_bo_list *amdgpu_bo_list_handle;
+
+/**
  * Define handle to be used when dealing with command
  * buffers (a.k.a. ibs)
  *
@@ -400,17 +405,9 @@ struct amdgpu_cs_request {
uint32_t   ring;

/**
-* Specify number of resource handles passed.
-* Size of 'handles' array
-*
+* List handle with resources used by this request.
 */
-   uint32_t number_of_resources;
-
-   /** Array of resources used by submission. */
-   amdgpu_bo_handle   *resources;
-
-   /** Array of resources flags. This is optional and can be NULL. */
-   uint8_t *resource_flags;
+   amdgpu_bo_list_handle resources;

/** Number of IBs to submit in the field ibs. */
uint32_t number_of_ibs;
@@ -788,6 +785,40 @@ int amdgpu_bo_wait_for_idle(amdgpu_bo_handle buf_handle,
uint64_t timeout_ns,
bool *buffer_busy);

+/**
+ * Creates a BO list handle for command submission.
+ *
+ * \param   dev- \c [in] Device handle.
+ *See #amdgpu_device_initialize()
+ * \param   number_of_resources- \c [in] Number of BOs in the list
+ * \param   resources  - \c [in] List of BO handles
+ * \param   resource_prios - \c [in] Optional priority for each handle
+ * \param   result - \c [out] Created BO list handle
+ *
+ * \return   0 on success\n
+ *  >0 - AMD specific error code\n
+ *  <0 - Negative POSIX Error code
+ *
+ * \sa amdgpu_bo_list_destroy()
+*/
+int amdgpu_bo_list_create(amdgpu_device_handle dev,
+ uint32_t number_of_resources,
+ amdgpu_bo_handle *resources,
+ uint8_t *resource_prios,
+ amdgpu_bo_list_handle *result);
+
+/**
+ * Destroys a BO list handle.
+ *
+ * \param   handle - \c [in] BO list handle.
+ *
+ * \return   0 on success\n
+ *  >0 - AMD specific error code\n
+ *  <0 - Negative POSIX Error code
+ *
+ * \sa amdgpu_bo_list_create()
+*/
+int amdgpu_bo_list_destroy(amdgpu_bo_list_handle handle);

 /*
  * Special GPU Resources
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index ce7e9d1..e5744d6 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -620,3 +620,59 @@ int amdgpu_create_bo_from_user_mem(amdgpu_device_handle 
dev,
info->virtual_mc_base_address = bo->virtual_mc_base_address;
return r;
 }
+
+int amdgpu_bo_list_create(amdgpu_device_handle dev,
+ uint32_t number_of_resources,
+ amdgpu_bo_handle *resources,
+ uint8_t *resource_prios,
+ amdgpu_bo_list_handle *result)
+{
+   struct drm_amdgpu_bo_list_entry *list;
+   union drm_amdgpu_bo_list args;
+   unsigned i;
+   int r;
+
+   list = alloca(sizeof(struct drm_amdgpu_bo_list_entry) * 
number_of_resources);
+
+   memset(, 0, sizeof(args));
+   args.in.operation = AMDGPU_BO_LIST_OP_CREATE;
+   args.in.bo_number = number_of_resources;
+   args.in.bo_info_size = sizeof(struct drm_amdgpu_bo_list_entry);
+   args.in.bo_info_ptr = (uint64_t)(uintptr_t)list;
+
+   for (i = 0; i < number_of_resources; i++) {
+   list[i].bo_handle = resources[i]->handle;
+   if (resource_prios)
+   list[i].bo_priority = resource_prios[i];
+   else
+   list[i].bo_priority = 0;
+   }
+
+   r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_BO_LIST,
+   , sizeof(args));
+   if (r)
+   return r;
+
+   *result = calloc(1, sizeof(struct amdgpu_bo_list));
+   (*result)->dev = dev;
+   (*result)->handle = args.out.list_handle;
+   return 0;
+}
+
+int amdgpu_bo_list_destroy(amdgpu_bo_list_handle list)
+{
+   union drm_amdgpu_bo_list args;
+   int r;
+
+   memset(, 0, sizeof(args));
+   args.in.operation = AMDGPU_BO_LIST_OP_DESTROY;
+   args.in.list_handle = list->handle;
+
+  

[PATCH 1/2] amdgpu: cleanup public interface

[Christian König]

From: Christian König 

Remove the mostly unused device parameter, for the few cases
where we really need it keep a copy in the context structure.

Signed-off-by: Christian König 
Reviewed-by: Jammy Zhou 
Reviewed-by: Alex Deucher 
---
 amdgpu/amdgpu.h|  24 +++---
 amdgpu/amdgpu_cs.c | 115 +++--
 amdgpu/amdgpu_internal.h   |   2 +
 tests/amdgpu/basic_tests.c |  33 +++--
 tests/amdgpu/cs_tests.c|  14 +++---
 5 files changed, 78 insertions(+), 110 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 90dc33c..7a85982 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -882,7 +882,6 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev,
  *
  * Destroy GPU execution context when not needed any more
  *
- * \param   dev- \c [in] Device handle. See 
#amdgpu_device_initialize()
  * \param   context - \c [in] GPU Context handle
  *
  * \return   0 on success\n
@@ -892,13 +891,11 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev,
  * \sa amdgpu_cs_ctx_create()
  *
 */
-int amdgpu_cs_ctx_free(amdgpu_device_handle dev,
-  amdgpu_context_handle context);
+int amdgpu_cs_ctx_free(amdgpu_context_handle context);

 /**
  * Query reset state for the specific GPU Context
  *
- * \param   dev- \c [in] Device handle. See 
#amdgpu_device_initialize()
  * \param   context - \c [in]  GPU Context handle
  * \param   state   - \c [out] Reset state status
  *
@@ -909,8 +906,7 @@ int amdgpu_cs_ctx_free(amdgpu_device_handle dev,
  * \sa amdgpu_cs_ctx_create()
  *
 */
-int amdgpu_cs_query_reset_state(amdgpu_device_handle dev,
-   amdgpu_context_handle context,
+int amdgpu_cs_query_reset_state(amdgpu_context_handle context,
enum amdgpu_cs_ctx_reset_state *state);


@@ -924,7 +920,6 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle dev,
  * Allocate memory to be filled with PM4 packets and be served as the first
  * entry point of execution (a.k.a. Indirect Buffer)
  *
- * \param   dev- \c [in] Device handle. See 
#amdgpu_device_initialize()
  * \param   context - \c [in]  GPU Context which will use IB
  * \param   ib_size - \c [in]  Size of allocation
  * \param   output  - \c [out] Pointer to structure to get information about
@@ -937,8 +932,7 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle dev,
  * \sa amdgpu_cs_free_ib()
  *
 */
-int amdgpu_cs_alloc_ib(amdgpu_device_handle dev,
-  amdgpu_context_handle context,
+int amdgpu_cs_alloc_ib(amdgpu_context_handle context,
   enum amdgpu_cs_ib_size ib_size,
   struct amdgpu_cs_ib_alloc_result *output);

@@ -946,8 +940,6 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev,
  * If UMD has allocates IBs which doesn’t need any more than those IBs must
  * be explicitly freed
  *
- * \param   dev- \c [in] Device handle. See 
#amdgpu_device_initialize()
- * \param   context - \c [in] GPU Context containing IB
  * \param   handle  - \c [in] IB handle
  *
  * \return   0 on success\n
@@ -960,9 +952,7 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev,
  * \sa amdgpu_cs_alloc_ib()
  *
 */
-int amdgpu_cs_free_ib(amdgpu_device_handle dev,
- amdgpu_context_handle context,
- amdgpu_ib_handle handle);
+int amdgpu_cs_free_ib(amdgpu_ib_handle handle);

 /**
  * Send request to submit command buffers to hardware.
@@ -1011,8 +1001,7 @@ int amdgpu_cs_free_ib(amdgpu_device_handle dev,
  * amdgpu_cs_query_fence_status()
  *
 */
-int amdgpu_cs_submit(amdgpu_device_handle  dev,
-amdgpu_context_handle context,
+int amdgpu_cs_submit(amdgpu_context_handle context,
 uint64_t flags,
 struct amdgpu_cs_request *ibs_request,
 uint32_t number_of_requests,
@@ -1038,8 +1027,7 @@ int amdgpu_cs_submit(amdgpu_device_handle  dev,
  *
  * \sa amdgpu_cs_submit()
 */
-int amdgpu_cs_query_fence_status(amdgpu_device_handle dev,
-struct amdgpu_cs_query_fence *fence,
+int amdgpu_cs_query_fence_status(struct amdgpu_cs_query_fence *fence,
 uint32_t *expired);


diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 614904d..d6b4b2d 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -42,8 +42,7 @@
  *
  * \return  0 on success otherwise POSIX Error code
 */
-static int amdgpu_cs_create_ib(amdgpu_device_handle dev,
-  amdgpu_context_handle context,
+static int amdgpu_cs_create_ib(amdgpu_context_handle context,
   enum amdgpu_cs_ib_size ib_size,
   amdgpu_ib_handle *ib)
 {
@@ -79,7 +78,7 @@ static int amdgpu_cs_create_ib(amdgpu_device_handle dev,

alloc_buffer.preferred_heap = AMDGPU_GEM_DOMAIN_GTT;

-   r = amdgpu_bo_alloc(dev,

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

Kevin Sarendranath  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #6 from Kevin Sarendranath  ---
Well that explains it. Good to know it's not a real issue.

Thanks again for the help.

-- 
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/20150423/4ac389af/attachment.html>

[PATCH libdrm] Add missing includes

[Emil Velikov]

On 22/04/15 16:19, Greg Hackmann wrote:
> On Tue, Apr 21, 2015 at 11:31 AM, Emil Velikov  
> wrote:
>>
>> I'm not sure why I haven't hit this while building with Android-x86's
>> bionic, although it's the right thing to do.
> 
> Maybe a difference in bionic versions?  I know the bionic team made
> some recent (post-5.1) changes that unintentionally exposed a handful
> of other missing #includes in our tree.
> 
Could be. I've never really bothered checking the bionic (both
downstream patches and version) that Android-x86 uses.

>> From a quick look I cannot see libdrm in the AOSP build. Are you
>> experimenting with a libdrm based hwcompositor again :-)
> 
> Yeah.  That's where I want to end up in the long term, anyway.  I've
> said publicly that we'd eventually like to converge with upstream on
> this, and I still mean it.  :)
> 
Great glad to hear. We have a GSoC student that is working on it this
summer, so things might be closer than expected.

May I suggest that you ping/send patches to the list early and often.
There is a lot of traffic, and most people are busy with their own
hardware so patches do get missed/forgotten.

Another good idea is to pop over at #dri-devel at FreeNode, and have a
chat with the guys in real time - someone might be able to find a
solution/steer you in the right direction :-)

Cheers,
Emil

[PATCH v2] modetest: initialize handles/pitches in set_plane()

[Tobias Jakobi]

Hello Ilia!


On 2015-04-23 16:32, Ilia Mirkin wrote:
> On Thu, Apr 23, 2015 at 9:39 AM, Tobias Jakobi
>  wrote:
>> Hello Ilia,
>> 
>> On 2015-04-21 21:15, Ilia Mirkin wrote:
>>> 
>>> I know it was immensely useful to me when I was adding YUV plane
>>> support to nouveau. Seemed to work as advertised at the time (1.5y
>>> ago) for YUYV, UYVY, and NV12.
>>> 
>>>   -ilia
>> 
>> maybe you can help me with that question.
>> 
>> Let's consider a user of the DRM interface that wants to feed NV12 
>> data to
>> it. NV12 is bi-planar, so the user should provide two
>> handles/pitches/offsets describing chroma and luma plane respectively. 
>> But
>> most of the time chroma and luma is contiguous in memory, with nothing 
>> in
>> between.
>> 
>> I was wondering if it is an allowed setup to request NV12 as 
>> pixelformat,
>> but only to provide _one_ handle/pitch/offset? (implying that we are 
>> in the
>> contiguous setting)
> 
> Uhm... I'm no authority on the matter, merely vouching for the
> usefulness of the modetest tool :) However I was never aware of any
> contiguousness assumptions in NV12, afaik the two different planes are
> different :) It could also cause issues if you had, a, say, 32x30
> image but whatever hw produced it wanted to make it 32x32. You'd end
> up with an offset between the two planes which wouldn't be specified.
> FWIW on the (much older) NVIDIA gpu's that I added support for, it
> assumes a separate offset:
> 
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
> nv_fb->nvbo->bo.offset + fb->offsets[1]);
> 
> Note that as far as the HW is concerned, it's an entirely separate
> memory location, not even an offset from the Y plane -- it could be 2
> totally separate bo's for all it cares.
Thanks for the insight! That's kind of what I expected.

What confused me though is that the v4l2 API has this:
http://www.hep.by/gnu/kernel/media/V4L2-PIX-FMT-NV12M.html

Maybe pixelformats are passed around differently in v4l2, but as far as 
I can see, the difference between v4l2-NV12 and v4l2-NV12M doesn't exist 
in DRM land. As soon as NV12 is used, we always have two planes given 
explicitly.



> Also, as another datapoint, the VP3 and newer video decoding units on
> NVIDIA cards (generally speaking GeForce 200+) have firmware that
> produces the Y and UV data as completely separate pieces of data as
> well. On VP2 they had to be in the same buffer, but you could provide
> an explicit offset to the UV bit.
OK, so the Exynos video processor kinda does the same here. It needs 
separate pointers to chroma and luma.


> 
>   -ilia


With best wishes,
Tobias

[PATCH v3 7/7] tests/exynos: replace return by break

[Tobias Jakobi]

The 'usage' function already does exit(0), so that this
'return -EINVAL' is never called. Just put a break there
to avoid confusion.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/exynos_fimg2d_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index e64bb32..64dacfa 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -689,7 +689,7 @@ int main(int argc, char **argv)
break;
default:
usage(argv[0]);
-   return -EINVAL;
+   break;
}
}

-- 
2.0.5

[PATCH v3 6/7] exynos: fimg2d: fix return codes

[Tobias Jakobi]

Even if flushing the command buffer doesn't succeed, the
G2D calls would still return zero. Fix this by just passing
the flush return code.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 1a99f17..05ea7bc 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -364,9 +364,7 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image 
*img,
bitblt.data.fast_solid_color_fill_en = 1;
g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val);

-   g2d_flush(ctx);
-
-   return 0;
+   return g2d_flush(ctx);
 }

 /**
@@ -449,9 +447,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
rop4.data.unmasked_rop3 = G2D_ROP3_SRC;
g2d_add_cmd(ctx, ROP4_REG, rop4.val);

-   g2d_flush(ctx);
-
-   return 0;
+   return g2d_flush(ctx);
 }

 /**
@@ -561,9 +557,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct 
g2d_image *src,
pt.data.y = dst_y + dst_h;
g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val);

-   g2d_flush(ctx);
-
-   return 0;
+   return g2d_flush(ctx);
 }

 /**
@@ -670,9 +664,7 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
pt.data.y = dst_y + h;
g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val);

-   g2d_flush(ctx);
-
-   return 0;
+   return g2d_flush(ctx);
 }

 /**
@@ -800,7 +792,5 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct 
g2d_image *src,
pt.data.y = dst_y + dst_h;
g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val);

-   g2d_flush(ctx);
-
-   return 0;
+   return g2d_flush(ctx);
 }
-- 
2.0.5

[PATCH v3 5/7] tests/exynos: add fimg2d event test

[Tobias Jakobi]

This tests async processing of G2D jobs. A separate thread is spawned
to monitor the DRM fd for events and check whether a G2D job was
completed.

v2: Add GPLv2 header, argument handling and documentation.
Test is only installed when requested.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/Makefile.am   |  11 +-
 tests/exynos/exynos_fimg2d_event.c | 326 +
 2 files changed, 335 insertions(+), 2 deletions(-)
 create mode 100644 tests/exynos/exynos_fimg2d_event.c

diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index e82d199..357d6b8 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -20,16 +20,23 @@ endif

 if HAVE_INSTALL_TESTS
 bin_PROGRAMS += \
-   exynos_fimg2d_perf
+   exynos_fimg2d_perf \
+   exynos_fimg2d_event
 else
 noinst_PROGRAMS += \
-   exynos_fimg2d_perf
+   exynos_fimg2d_perf \
+   exynos_fimg2d_event
 endif

 exynos_fimg2d_perf_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/exynos/libdrm_exynos.la

+exynos_fimg2d_event_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/exynos/libdrm_exynos.la \
+   -lpthread
+
 exynos_fimg2d_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/libkms/libkms.la \
diff --git a/tests/exynos/exynos_fimg2d_event.c 
b/tests/exynos/exynos_fimg2d_event.c
new file mode 100644
index 000..d1cb90e
--- /dev/null
+++ b/tests/exynos/exynos_fimg2d_event.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2015 - Tobias Jakobi
+ *
+ * This 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.
+ *
+ * It 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.
+ * You should have received a copy of the GNU General Public License
+ * along with it. If not, see .
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "exynos_drm.h"
+#include "exynos_drmif.h"
+#include "exynos_fimg2d.h"
+
+struct g2d_job {
+   unsigned int id;
+   unsigned int busy;
+};
+
+struct exynos_evhandler {
+   struct pollfd fds;
+   struct exynos_event_context evctx;
+};
+
+struct threaddata {
+   unsigned int stop;
+   struct exynos_device *dev;
+   struct exynos_evhandler evhandler;
+};
+
+static void g2d_event_handler(int fd, unsigned int cmdlist_no, unsigned int 
tv_sec,
+   unsigned int tv_usec, 
void *user_data)
+{
+   struct g2d_job *job = user_data;
+
+   fprintf(stderr, "info: g2d job (id = %u, cmdlist number = %u) 
finished!\n",
+   job->id, cmdlist_no);
+
+   job->busy = 0;
+}
+
+static void setup_g2d_event_handler(struct exynos_evhandler *evhandler, int fd)
+{
+   evhandler->fds.fd = fd;
+   evhandler->fds.events = POLLIN;
+   evhandler->evctx.base.version = DRM_EVENT_CONTEXT_VERSION;
+   evhandler->evctx.version = EXYNOS_EVENT_CONTEXT_VERSION;
+   evhandler->evctx.g2d_event_handler = g2d_event_handler;
+}
+
+static void* threadfunc(void *arg) {
+   const int timeout = -1;
+   struct threaddata *data;
+
+   data = arg;
+
+   while (1) {
+   if (data->stop) break;
+
+   data->evhandler.fds.revents = 0;
+
+   if (poll(>evhandler.fds, 1, timeout) < 0)
+   continue;
+
+   if (data->evhandler.fds.revents & (POLLHUP | POLLERR))
+   continue;
+
+   if (data->evhandler.fds.revents & POLLIN)
+   exynos_handle_event(data->dev, >evhandler.evctx);
+
+   usleep(500);
+   }
+
+   pthread_exit(0);
+}
+
+/*
+ * We need to wait until all G2D jobs are finished, otherwise we
+ * potentially remove a BO which the engine still operates on.
+ * This results in the following kernel message:
+ * [drm:exynos_drm_gem_put_dma_addr] *ERROR* failed to lookup gem object.
+ * Also any subsequent BO allocations fail then with:
+ * [drm:exynos_drm_alloc_buf] *ERROR* failed to allocate buffer.
+ */
+static void wait_all_jobs(struct g2d_job* jobs, unsigned num_jobs)
+{
+   unsigned i;
+
+   for (i = 0; i < num_jobs; ++i) {
+   while (jobs[i].busy)
+   usleep(500);
+   }
+
+}
+
+static struct g2d_job* free_job(struct g2d_job* jobs, unsigned num_jobs)
+{
+   unsigned i;
+
+   for (i = 0; i < num_jobs; ++i) {
+   if (jobs[i].busy == 0)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static int g2d_work(struct g2d_context *ctx, struct g2d_image 

[PATCH v3 4/7] exynos: fimg2d: add g2d_exec2

[Tobias Jakobi]

This is a more 'flexible' version of g2d_exec allowing to pass
some flags which modify the behaviour of g2d_exec. Currently
only the 'async' operation flag is supported.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 15 +--
 exynos/exynos_fimg2d.h |  6 ++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index e90ffed..1a99f17 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -288,13 +288,24 @@ drm_public void g2d_config_event(struct g2d_context *ctx, 
void *userdata)
  */
 drm_public int g2d_exec(struct g2d_context *ctx)
 {
-   struct drm_exynos_g2d_exec exec;
+   return g2d_exec2(ctx, G2D_EXEC_FLAG_NORMAL);
+}
+
+/**
+ * g2d_exec2 - same as 'g2d_exec' but allow to pass some flags.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ */
+drm_public int g2d_exec2(struct g2d_context *ctx, unsigned int flags)
+{
+   struct drm_exynos_g2d_exec exec = {0};
int ret;

if (ctx->cmdlist_nr == 0)
return -EINVAL;

-   exec.async = 0;
+   if (flags & G2D_EXEC_FLAG_ASYNC)
+   exec.async = 1;

ret = drmIoctl(ctx->fd, DRM_IOCTL_EXYNOS_G2D_EXEC, );
if (ret < 0) {
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 421249d..8f9ba23 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -187,6 +187,11 @@ enum e_g2d_acoeff_mode {
G2D_ACOEFF_MODE_MASK
 };

+enum e_g2d_exec_flag {
+   G2D_EXEC_FLAG_NORMAL = (0 << 0),
+   G2D_EXEC_FLAG_ASYNC = (1 << 0)
+};
+
 union g2d_point_val {
unsigned int val;
struct {
@@ -305,6 +310,7 @@ struct g2d_context *g2d_init(int fd);
 void g2d_fini(struct g2d_context *ctx);
 void g2d_config_event(struct g2d_context *ctx, void *userdata);
 int g2d_exec(struct g2d_context *ctx);
+int g2d_exec2(struct g2d_context *ctx, unsigned int flags);
 int g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img,
unsigned int x, unsigned int y, unsigned int w,
unsigned int h);
-- 
2.0.5

[PATCH libdrm 0/5] modetest: fix misc when terminates modetest

[Emil Velikov]

On 22/04/15 02:05, Joonyoung Shim wrote:
> Hi Emil,
> 
> On 04/22/2015 05:16 AM, Emil Velikov wrote:
>> Hi Joonyoung,
>>
>> On 13/04/15 08:31, Joonyoung Shim wrote:
>>> Hi all,
>>>
>>> This patchset is to fix properly about buffer and framebuffer resources
>>> when terminates modetest of libdrm.
>>>
>> The series looks great (incl. the MAKE_RGB_INFO fix) and barring any
>> objections I'll push it by the end of the week. Just a small sidenote -
>> some of the commit messages are a bit hard to read. Hope you don't mind
>> if I change them slightly before pushing.
> 
> It's ok, i guess i should thank you.
> 
I seriously won't be offended if you don't, so it's entirely up-to you.

Cheers
Emil

[PATCH v2] modetest: initialize handles/pitches in set_plane()

[Emil Velikov]

Hi Ilia,

On 21/04/15 19:15, Ilia Mirkin wrote:
> On Tue, Apr 21, 2015 at 4:10 PM, Emil Velikov  
> wrote:
>> Hi Tobias,
>>
>> On 20/04/15 19:50, Tobias Jakobi wrote:
>>> Only the 'offsets' array was initialized to zero.
>>> Since bo_create only sets the handles which are
>>> necessary, were we passing garbage data to the
>>> kernel when calling drmModeAddFB2 later.
>>>
>>> The issue only seems to appear when passing e.g.
>>> NV12 data to the kernel, a case where not only
>>> handles[0] is used. I therefore also removed the
>>> corresponding comment.
>>>
>>> v2: Do the same for set_mode(), set_cursors()
>>> and test_page_flip().
>>>
>> Nice catch. I will push this in a day or so, unless someone objects.
>>
>> This and the other patches from Joonyoung Shim make me question how many
>> people have seriously used this tool.
> 
> I know it was immensely useful to me when I was adding YUV plane
> support to nouveau. Seemed to work as advertised at the time (1.5y
> ago) for YUYV, UYVY, and NV12.
> 
Hah... your reply was authored 55 minutes before mine, according to
Blunderbird :)

Back to the original topic - most likely I'm underestimating the shear
permutation of ways the tool can be used. Glad to hear that it was
useful for your work - perhaps we changed something that "broke" in
after that :-\


-Emil

[PATCH] drm: Implement drmHandleEvent2()

[Tobias Jakobi]

Hello,

since it might not be entirely clear how to use this, here's how the 
Exynos libdrm would use it:
https://patchwork.kernel.org/patch/6263151/

With best wishes,
Tobias



On 2015-04-23 15:32, Tobias Jakobi wrote:
> Basically this is an extended version of drmHandleEvent().
> 
> drmHandleEvent() only handles core events (like e.g. page flips),
> but since kernel DRM drivers might use vendor-specific events
> to signal userspace the completion of pending jobs, etc., its
> desirable to provide a way to handle these without putting
> vendor-specific code in the core libdrm.
> 
> To use this you provide drmHandleEvent2() with a function that
> handles your non-core events (and some opaque pointer).
> 
> The signature of that function looks like this:
> void vendor(int fd, struct drm_event *e, void *custom_data);
> 
> 'fd' is the DRM file descriptor, 'e' the non-core event, and
> 'custom_data' the aforementioned opaque pointer.
> 
> This way we don't have to maintain a copy of drmHandleEvent()
> in the vendor code.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  xf86drm.h | 13 +
>  xf86drmMode.c | 10 +-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/xf86drm.h b/xf86drm.h
> index 40c55c9..ad0ae1c 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -741,8 +741,21 @@ typedef struct _drmEventContext {
> 
>  } drmEventContext, *drmEventContextPtr;
> 
> +typedef void (*drmEventVendorHandler)(int fd, struct drm_event *e,
> + void *custom_data);
> +
>  extern int drmHandleEvent(int fd, drmEventContextPtr evctx);
> 
> +/*
> + * drmHandleEvent2() is an extended variant of drmHandleEvent() which
> + * allows handling of vendor-specific/non-core events.
> + * The function pointer 'vendorhandler' is used (if non-zero) to
> + * process non-core events. The opaque pointer 'data' is passed as
> + * the 'custom_data' argument.
> + */
> +extern int drmHandleEvent2(int fd, drmEventContextPtr evctx,
> + drmEventVendorHandler vendorhandler, void *data);
> +
>  extern char *drmGetDeviceNameFromFd(int fd);
>  extern int drmGetNodeTypeFromFd(int fd);
> 
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 1333da4..e68e3e2 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -857,7 +857,8 @@ int drmModeCrtcSetGamma(int fd, uint32_t crtc_id,
> uint32_t size,
>   return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETGAMMA, );
>  }
> 
> -int drmHandleEvent(int fd, drmEventContextPtr evctx)
> +int drmHandleEvent2(int fd, drmEventContextPtr evctx,
> + drmEventVendorHandler vendorhandler, void *data)
>  {
>   char buffer[1024];
>   int len, i;
> @@ -900,6 +901,8 @@ int drmHandleEvent(int fd, drmEventContextPtr 
> evctx)
>U642VOID (vblank->user_data));
>   break;
>   default:
> + if (vendorhandler)
> + vendorhandler(fd, e, data);
>   break;
>   }
>   i += e->length;
> @@ -908,6 +911,11 @@ int drmHandleEvent(int fd, drmEventContextPtr 
> evctx)
>   return 0;
>  }
> 
> +int drmHandleEvent(int fd, drmEventContextPtr evctx)
> +{
> + return drmHandleEvent2(fd, evctx, NULL, NULL);
> +}
> +
>  int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t fb_id,
>   uint32_t flags, void *user_data)
>  {

git pull] drm for v4.1-rc1

[Bjorn Helgaas]

[+cc Matthew]

On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
> 
> Or maybe it never went away.
> 
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
> 
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   pci_bus :01: Allocating resources
>   pci_bus :02: Allocating resources
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
> 
> That resource is complete garbage. "flags 0x2" is not even a valid
> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
> that is valid, then it should also have have had the IORESOURCE_MEM
> bit, and it doesn't.

Your i915 does not have a ROM BAR in hardware.  If the default video
device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
even though the resource flags are zero because the BAR itself doesn't
exist.

If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
shadow ROM image at 0xC.  Is there a shadow image even if the
device itself doesn't have a ROM BAR?

We could fabricate a resource even if the BAR doesn't exist, e.g.,
"flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
would be ugly and error-prone in other places that use the ROM.

Matthew added dev->rom for ROM images supplied by the platform
(84c1b80e3263 ("PCI: Add support for non-BAR ROMs")).  A shadow
image seems like a similar thing.  I think it would be cleaner to get
rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
0xC" if there's a shadow image, e.g.:

  int pcibios_add_device(struct pci_dev *dev)
  {
if (dev-is-default-vga-device) {
  dev->rom = 0xC;
  dev->romlen = 0x2;
}

pa_data = boot_params.hdr.setup_data;
while (pa_data) {
  ...
  if (data->type == SETUP_PCI) {
rom = (struct pci_setup_rom *)data;

if (dev-is-rom-dev) {
  dev->rom = ...
  dev->romlen = rom->pcilen;
}
  }
}

But the rules for figuring out which image to use seem ...
complicated.

Bjorn

[PATCH v3 3/7] exynos/fimg2d: add g2d_config_event

[Tobias Jakobi]

This enables us to pass command buffers to the kernel which
trigger an event on the DRM fd upon completion.
The final goal is to enable asynchronous operation of the
G2D engine, similar to async page flips.

Passing the event userdata pointer through the G2D context
was chosen to not change the current API (e.g. by adding
a userdata argument to each public functions).

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 27 +--
 exynos/exynos_fimg2d.h |  2 ++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index fc605ed..e90ffed 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -202,8 +202,15 @@ static int g2d_flush(struct g2d_context *ctx)
cmdlist.cmd_buf = (uint64_t)(uintptr_t)>cmd_buf[0];
cmdlist.cmd_nr = ctx->cmd_nr;
cmdlist.cmd_buf_nr = ctx->cmd_buf_nr;
-   cmdlist.event_type = G2D_EVENT_NOT;
-   cmdlist.user_data = 0;
+
+   if (ctx->event_userdata) {
+   cmdlist.event_type = G2D_EVENT_NONSTOP;
+   cmdlist.user_data = (uint64_t)(uintptr_t)(ctx->event_userdata);
+   ctx->event_userdata = NULL;
+   } else {
+   cmdlist.event_type = G2D_EVENT_NOT;
+   cmdlist.user_data = 0;
+   }

ctx->cmd_nr = 0;
ctx->cmd_buf_nr = 0;
@@ -259,6 +266,22 @@ drm_public void g2d_fini(struct g2d_context *ctx)
 }

 /**
+ * g2d_config_event - setup userdata configuration for a g2d event.
+ * The next invocation of a g2d call (e.g. g2d_solid_fill) is
+ * then going to flag the command buffer as 'nonstop'.
+ * Completion of the command buffer execution can then be
+ * determined by using drmHandleEvent on the DRM fd.
+ * The userdata is 'consumed' in the process.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @userdata: a pointer to the user data
+ */
+drm_public void g2d_config_event(struct g2d_context *ctx, void *userdata)
+{
+   ctx->event_userdata = userdata;
+}
+
+/**
  * g2d_exec - start the dma to process all commands summited by g2d_flush().
  *
  * @ctx: a pointer to g2d_context structure.
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 9db0c88..421249d 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -298,10 +298,12 @@ struct g2d_context {
unsigned intcmd_nr;
unsigned intcmd_buf_nr;
unsigned intcmdlist_nr;
+   void*event_userdata;
 };

 struct g2d_context *g2d_init(int fd);
 void g2d_fini(struct g2d_context *ctx);
+void g2d_config_event(struct g2d_context *ctx, void *userdata);
 int g2d_exec(struct g2d_context *ctx);
 int g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img,
unsigned int x, unsigned int y, unsigned int w,
-- 
2.0.5

[PATCH v3 2/7] tests/exynos: add fimg2d performance analysis

[Tobias Jakobi]

Currently only fast solid color clear performance is measured.
A large buffer is allocated and solid color clear operations
are executed on it with randomly chosen properties (position
and size of the region, clear color). Execution time is
measured and output together with the amount of pixels
processed.

The 'simple' variant only executes one G2D command buffer at
a time, while the 'multi' variant executes multiple ones. This
can be used to measure setup/exec overhead.

The test also serves a stability check. If clocks/voltages are
too high or low respectively, the test quickly reveals this.

v2: Add GPLv2 header, argument handling and documentation.
Tool is only installed when requested.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/Makefile.am  |  19 ++-
 tests/exynos/exynos_fimg2d_perf.c | 320 ++
 2 files changed, 337 insertions(+), 2 deletions(-)
 create mode 100644 tests/exynos/exynos_fimg2d_perf.c

diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index b21d016..e82d199 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -5,16 +5,31 @@ AM_CFLAGS = \
-I $(top_srcdir)/exynos \
-I $(top_srcdir)

+bin_PROGRAMS =
+noinst_PROGRAMS =
+
 if HAVE_LIBKMS
 if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
+bin_PROGRAMS += \
exynos_fimg2d_test
 else
-noinst_PROGRAMS = \
+noinst_PROGRAMS += \
exynos_fimg2d_test
 endif
 endif

+if HAVE_INSTALL_TESTS
+bin_PROGRAMS += \
+   exynos_fimg2d_perf
+else
+noinst_PROGRAMS += \
+   exynos_fimg2d_perf
+endif
+
+exynos_fimg2d_perf_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/exynos/libdrm_exynos.la
+
 exynos_fimg2d_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/libkms/libkms.la \
diff --git a/tests/exynos/exynos_fimg2d_perf.c 
b/tests/exynos/exynos_fimg2d_perf.c
new file mode 100644
index 000..e52e0d8
--- /dev/null
+++ b/tests/exynos/exynos_fimg2d_perf.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright (C) 2015 - Tobias Jakobi
+ *
+ * This 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.
+ *
+ * It 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.
+ * You should have received a copy of the GNU General Public License
+ * along with it. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "exynos_drm.h"
+#include "exynos_drmif.h"
+#include "exynos_fimg2d.h"
+
+static int output_mathematica = 0;
+
+static int fimg2d_perf_simple(struct exynos_bo *bo, struct g2d_context *ctx,
+   unsigned buf_width, unsigned buf_height, unsigned 
iterations)
+{
+   struct timespec tspec = { 0 };
+   struct g2d_image img = { 0 };
+
+   unsigned long long g2d_time;
+   unsigned i;
+   int ret = 0;
+
+   img.width = buf_width;
+   img.height = buf_height;
+   img.stride = buf_width * 4;
+   img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+   img.buf_type = G2D_IMGBUF_GEM;
+   img.bo[0] = bo->handle;
+
+   srand(time(NULL));
+
+   printf("starting simple G2D performance test\n");
+   printf("buffer width = %u, buffer height = %u, iterations = %u\n",
+   buf_width, buf_height, iterations);
+
+   if (output_mathematica)
+   putchar('{');
+
+   for (i = 0; i < iterations; ++i) {
+   unsigned x, y, w, h;
+
+   x = rand() % buf_width;
+   y = rand() % buf_height;
+
+   if (x == (buf_width - 1))
+   x -= 1;
+   if (y == (buf_height - 1))
+   y -= 1;
+
+   w = rand() % (buf_width - x);
+   h = rand() % (buf_height - y);
+
+   if (w == 0) w = 1;
+   if (h == 0) h = 1;
+
+   img.color = rand();
+
+   ret = g2d_solid_fill(ctx, , x, y, w, h);
+
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   if (ret == 0)
+   ret = g2d_exec(ctx);
+
+   if (ret != 0) {
+   fprintf(stderr, "error: iteration %u failed (x = %u, y 
= %u, w = %u, h = %u)\n",
+   i, x, y, w, h);
+   break;
+   } else {
+   struct timespec end = { 0 };
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   g2d_time = (end.tv_sec - tspec.tv_sec) * 10ULL;
+   g2d_time += (end.tv_nsec - tspec.tv_nsec);
+
+   if (output_mathematica) {
+  

[PATCH v3 1/7] exynos: Introduce exynos_handle_event()

[Tobias Jakobi]

Used to handle kernel events specific to the Exynos platform.
Currently only G2D events are handled.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_drm.c   | 28 
 exynos/exynos_drm.h   | 12 
 exynos/exynos_drmif.h | 26 ++
 3 files changed, 66 insertions(+)

diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
index c5dd948..3a3d6b1 100644
--- a/exynos/exynos_drm.c
+++ b/exynos/exynos_drm.c
@@ -42,6 +42,8 @@
 #include "exynos_drm.h"
 #include "exynos_drmif.h"

+#define U642VOID(x) ((void *)(unsigned long)(x))
+
 /*
  * Create exynos drm device object.
  *
@@ -374,3 +376,29 @@ exynos_vidi_connection(struct exynos_device *dev, uint32_t 
connect,

return 0;
 }
+
+static void
+exynos_handle_vendor(int fd, struct drm_event *e, void *custom_data)
+{
+   struct drm_exynos_g2d_event *g2d;
+   struct exynos_event_context *ctx = custom_data;
+
+   switch (e->type) {
+   case DRM_EXYNOS_G2D_EVENT:
+   if (ctx->version < 1 || ctx->g2d_event_handler == NULL)
+   break;
+   g2d = (struct drm_exynos_g2d_event *)e;
+   ctx->g2d_event_handler(fd, g2d->cmdlist_no, g2d->tv_sec,
+   g2d->tv_usec, 
U642VOID(g2d->user_data));
+   break;
+
+   default:
+   break;
+   }
+}
+
+drm_public int
+exynos_handle_event(struct exynos_device *dev, struct exynos_event_context 
*ctx)
+{
+   return drmHandleEvent2(dev->fd, >base, exynos_handle_vendor, ctx);
+}
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index 256c02f..c3af0ac 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec {
 #define DRM_IOCTL_EXYNOS_G2D_EXEC  DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)

+/* EXYNOS specific events */
+#define DRM_EXYNOS_G2D_EVENT   0x8000
+
+struct drm_exynos_g2d_event {
+   struct drm_eventbase;
+   __u64   user_data;
+   __u32   tv_sec;
+   __u32   tv_usec;
+   __u32   cmdlist_no;
+   __u32   reserved;
+};
+
 #endif
diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
index c7c1d44..626e399 100644
--- a/exynos/exynos_drmif.h
+++ b/exynos/exynos_drmif.h
@@ -54,6 +54,25 @@ struct exynos_bo {
uint32_tname;
 };

+#define EXYNOS_EVENT_CONTEXT_VERSION 1
+
+/*
+ * Exynos Event Context structure.
+ *
+ * @base: base context (for core events).
+ * @version: version info similar to the one in 'drmEventContext'.
+ * @g2d_event_handler: handler for G2D events.
+ */
+struct exynos_event_context {
+   drmEventContext base;
+
+   int version;
+
+   void (*g2d_event_handler)(int fd, unsigned int cmdlist_no,
+ unsigned int tv_sec, 
unsigned int tv_usec,
+ void *user_data);
+};
+
 /*
  * device related functions:
  */
@@ -83,4 +102,11 @@ int exynos_prime_fd_to_handle(struct exynos_device *dev, 
int fd,
 int exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
uint32_t ext, void *edid);

+/*
+ * event handling related functions:
+ */
+int exynos_handle_event(struct exynos_device *dev,
+   struct exynos_event_context *ctx);
+
+
 #endif /* EXYNOS_DRMIF_H_ */
-- 
2.0.5

drm/exynos: add async G2D execution to libdrm (v3)

[Tobias Jakobi]

Hello,

this series exposes async execution of G2D command buffers to userspace. Also 
includes is a small performance analysis test, which can also be used to stress 
test the engine. The async operation is of 
course also tested.

Please review and let me know what I can improve.

v3: Rewrote handling of vendor-specific events. The series is now based on [1]. 
Also added two small fixes (error handling, break statement).


With best wishes,
Tobias

[1] https://patchwork.kernel.org/patch/6262541/

[PATCH 1/2] drm: add libdrm_amdgpu

[Emil Velikov]

Hi Alex,
On 21/04/15 16:39, Alex Deucher wrote:
> This is the new ioctl wrapper used by the new admgpu driver.
> It's primarily used by xf86-video-amdgpu and mesa.
> 
Glad to see amdgpu finally out :-)

Can we annotate the private symbols with drm_private, in both
declaration and definition ? It will hide the symbols, plus will make
the leap towards Solaris support a bit smaller.


> Signed-off-by: Alex Deucher 
> ---
>  Makefile.am|5 +
>  amdgpu/Makefile.am |   55 ++
>  amdgpu/amdgpu.h| 1278 
> 
>  amdgpu/amdgpu_bo.c |  622 +
>  amdgpu/amdgpu_cs.c |  981 ++
>  amdgpu/amdgpu_device.c |  242 +
>  amdgpu/amdgpu_gpu_info.c   |  275 ++
>  amdgpu/amdgpu_internal.h   |  210 
>  amdgpu/amdgpu_vamgr.c  |  169 ++
>  amdgpu/libdrm_amdgpu.pc.in |   10 +
>  amdgpu/util_double_list.h  |  146 +
>  amdgpu/util_hash.c |  382 +
>  amdgpu/util_hash.h |   99 
>  amdgpu/util_hash_table.c   |  257 +
>  amdgpu/util_hash_table.h   |   65 +++
>  amdgpu/util_math.h |   32 ++
>  configure.ac   |   20 +
>  include/drm/amdgpu_drm.h   |  600 +
>  18 files changed, 5448 insertions(+)
>  create mode 100644 amdgpu/Makefile.am
>  create mode 100644 amdgpu/amdgpu.h
>  create mode 100644 amdgpu/amdgpu_bo.c
>  create mode 100644 amdgpu/amdgpu_cs.c
>  create mode 100644 amdgpu/amdgpu_device.c
>  create mode 100644 amdgpu/amdgpu_gpu_info.c
>  create mode 100644 amdgpu/amdgpu_internal.h
>  create mode 100644 amdgpu/amdgpu_vamgr.c
>  create mode 100644 amdgpu/libdrm_amdgpu.pc.in
>  create mode 100644 amdgpu/util_double_list.h
>  create mode 100644 amdgpu/util_hash.c
>  create mode 100644 amdgpu/util_hash.h
>  create mode 100644 amdgpu/util_hash_table.c
>  create mode 100644 amdgpu/util_hash_table.h
>  create mode 100644 amdgpu/util_math.h
>  create mode 100644 include/drm/amdgpu_drm.h
> 

> --- /dev/null
> +++ b/amdgpu/Makefile.am

> +AM_CFLAGS = \
> + $(WARN_CFLAGS)

> -Wno-switch-enum \
>From a quick look you should be OK without this. If that's not the case,
it might be worth looking into ?

> + -I$(top_srcdir) \
> + -I$(top_srcdir)/amdgpu \
You can drop this line.

> + $(PTHREADSTUBS_CFLAGS) \
> + -I$(top_srcdir)/include/drm
> +
> +libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
> +libdrm_amdgpu_ladir = $(libdir)
> +libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:1 -no-undefined
Considering that this is the first public version shouldn't this be 1:0:0 ?

> +libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
> +
> +libdrm_amdgpu_la_SOURCES = \
> + amdgpu_gpu_info.c \
> + amdgpu_device.c \
> + amdgpu_bo.c \
> + util_hash.c \
> + util_hash_table.c \
> + amdgpu_vamgr.c \
> + amdgpu_cs.c
> +
Please include all files, and sort them alphabetically, something like:

amdgpu_bo.c
amdgpu_cs.c
amdgpu_device.c
amdgpu_gpu_info.c
amdgpu_internal.h
amdgpu_vamgr.c
util_double_list.h
util_hash.c
util_hash.h
util_hash_table.c
util_hash_table.h
util_math.h

One might want to drop util_double_list.h if you go for my suggestion below.

> +nodist_EXTRA_libdrm_amdgpu_la_SOURCES = dummy.cxx
> +
There are no C++ sources or static libs based on such so you can drop this.

> +EXTRA_DIST = libdrm_amdgpu.pc.in
You don't need this.

> --- /dev/null
> +++ b/amdgpu/amdgpu.h

> +#ifndef _amdgpu_h_
> +#define _amdgpu_h_
> +
Capitalise the header guard name ?

> +#include 
> +#include 
> +

Albeit not so common in libdrm, you can add make the header C++ safe.

#if defined(__cplusplus)
extern "C" {
#endif


> +struct amdgpu_bo_alloc_request {
> + /** Allocation request. It must be aligned correctly. */
> + uint64_t alloc_size;
> +
> + /**
> +  * It may be required to have some specific alignment requirements
> +  * for physical back-up storage (e.g. for displayable surface).
> +  * If 0 there is no special alignment requirement
> +  */
> + uint64_t phys_alignment;
> +
> + /**
> +  * UMD should specify where to allocate memory and how it
> +  * will be accessed by the CPU.
> +  */
> + uint32_t preferred_heap;
> +
Worth adding a pad ?

> + /** Additional flags passed on allocation */
> + uint64_t flags;
> +};

> +struct amdgpu_bo_info {
> + /** Allocated memory size */
> + uint64_t alloc_size;
> +
> + /**
> +  * It may be required to have some specific alignment requirements
> +  * for physical back-up storage.
> +  */
> + uint64_t phys_alignment;
> +
> + /**
> +  * Assigned virtual MC Base Address.
> +  * \note  This information will be returned only if this buffer was
> +  * allocated in the same process otherwise 0 will be returned.
> + */
> + uint64_t virtual_mc_base_address;
> +
> + /** Heap where to allocate memory. */
> + uint32_t 

[PATCH v4 06/10] cec: add HDMI CEC framework

[Hans Verkuil]

On 04/23/2015 03:03 PM, Kamil Debski wrote:
> From: 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]
> Signed-off-by: Kamil Debski 
> ---
>  Documentation/cec.txt |  396 
>  drivers/media/Kconfig |6 +
>  drivers/media/Makefile|2 +
>  drivers/media/cec.c   | 1161 
> +
>  include/media/cec.h   |  140 ++
>  include/uapi/linux/Kbuild |1 +
>  include/uapi/linux/cec.h  |  303 
>  7 files changed, 2009 insertions(+)
>  create mode 100644 Documentation/cec.txt
>  create mode 100644 drivers/media/cec.c
>  create mode 100644 include/media/cec.h
>  create mode 100644 include/uapi/linux/cec.h
> 
> diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
> new file mode 100644
> index 000..bb6d66c
> --- /dev/null
> +++ b/include/uapi/linux/cec.h
> @@ -0,0 +1,303 @@
> +
> +/* Userspace has to configure the adapter state (enable/disable) */
> +#define CEC_CAP_STATE(1 << 0)
> +/* Userspace has to configure the physical address */
> +#define CEC_CAP_PHYS_ADDR(1 << 1)
> +/* Userspace has to configure the logical addresses */
> +#define CEC_CAP_LOG_ADDRS(1 << 2)
> +/* Userspace can transmit messages */
> +#define CEC_CAP_TRANSMIT (1 << 3)
> +/* Userspace can receive messages */
> +#define CEC_CAP_RECEIVE  (1 << 4)
> +/* Userspace has to configure the vendor id */
> +#define CEC_CAP_VENDOR_ID(1 << 5)
> +/* The hardware has the possibility to work in the promiscuous mode */
> +#define CEC_CAP_PROMISCUOUS  (1 << 6)

Since promiscuous support has been dropped, this capability needs to be
dropped as well.

> +
> +struct cec_caps {
> + __u32 available_log_addrs;
> + __u32 capabilities;
> + __u32 vendor_id;
> + __u8  version;
> + __u8  reserved[11];

I'd increase this to 31.

> +};
> +
> +struct cec_log_addrs {
> + __u8 cec_version;
> + __u8 num_log_addrs;
> + __u8 primary_device_type[CEC_MAX_LOG_ADDRS];
> + __u8 log_addr_type[CEC_MAX_LOG_ADDRS];
> + __u8 log_addr[CEC_MAX_LOG_ADDRS];
> +
> + /* CEC 2.0 */
> + __u8 all_device_types;
> + __u8 features[CEC_MAX_LOG_ADDRS][12];
> +
> + __u8 reserved[9];

I'd increase this to 65 or so.

Regards,

Hans

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

--- Comment #5 from Alex Deucher  ---
(In reply to Kevin Sarendranath from comment #0)
> The system being used is a Lenovo Thinkpad configured with an R7 M260DX
> discrete card attached to an A10-7300. Upon booting it, the kernel spits out
> this message:
> 
> 
> [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller
> 

This message is from the dGPU which is not connected to any displays so it can
be ignored.  The backlight control is properly initialized on the APU which is
the chip that controls the backlight.

[2.419773] [drm] radeon atom DIG backlight initialized

> 
> with the quirk of having the brightness hotkeys not being able to control
> the brightness. Looking into the radeon source, here is where the call came
> from (radeon_acpi.c):

What the brightness keys do is up to the OEM.  On most modern laptops, they
tend to just generate key press events rather than actually changing the
brightness or generating acpi events.  It's up to the desktop environment to
map that event to the brightness controls exposed by the kernel.

-- 
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/20150423/bb18d33b/attachment-0001.html>

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

--- Comment #4 from Kevin Sarendranath  ---
Thanks for pointing out PRIME. 

Here's the dmesg and xorg logs.

-- 
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/20150423/a2031ff1/attachment.html>

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

--- Comment #3 from Kevin Sarendranath  ---
Created attachment 115297
  --> https://bugs.freedesktop.org/attachment.cgi?id=115297=edit
xorg log

-- 
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/20150423/7b6c8bbd/attachment.html>

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

--- Comment #2 from Kevin Sarendranath  ---
Created attachment 115296
  --> https://bugs.freedesktop.org/attachment.cgi?id=115296=edit
dmesg output

-- 
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/20150423/229a9bab/attachment.html>

git pull] drm for v4.1-rc1

[Matthew Garrett]

On Thu, Apr 23, 2015 at 3:47 PM, Linus Torvalds
 wrote:

> I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
> yes, if what this is all about is the magic video ROM at 0xc, then

It's used in the PCI layer to say "Read from 0xc rather than the
ROM BAR" and then ends up as a shorthand for "Was this the boot video
device" in various places because we're bad at software.

> There is no way to see that from the PCI device state, because as
> mentioned, quite often the "ROM" is entirely fake, and is not just
> some shadowed copy of a real underlying hardware ROM, but is
> fundamentally just a RAM image decompressed from some other source and
> then marked read-only.

If only - nvidias used to rewrite their image at runtime.

-- 
Matthew Garrett | matthew.garrett at coreos.com

git pull] drm for v4.1-rc1

[Linus Torvalds]

On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
 wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas  wrote:
>>
>>   int pcibios_add_device(struct pci_dev *dev)
>>   {
>> if (dev-is-default-vga-device) {
>>   dev->rom = 0xC;
>>   dev->romlen = 0x2;
>> }
>
> I don't know what we want to do here. This is, at some level,
> fundamentally wrong - however, it also wouldn't surprise me if this is
> also the only copy of the video ROM we have on some UEFI systems,
> especially since I believe that Windows 7 still required that there be
> a legacy ROM it could use for bootloader modesetting on UEFI
> platforms. So simply making this conditional on BIOS may break
> existing machines. But if there *is* a ROM there then we should be
> able to id it from the usual video ROM signature?

I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
yes, if what this is all about is the magic video ROM at 0xc, then

 (a) it should have nothing what-so-ever to do with the actual PCI
BAR, since it's been *ages* since people actually had an expansion rom
like that, and it's much more common that the video ROM comes as part
of the system BIOS on laptops etc.

 (b) yes, the sane thing to do would be to just look for the ROM
signature, 0x55 0xaa at 2kB incrementing headers (and checking the
proper checksum too).

There is no way to see that from the PCI device state, because as
mentioned, quite often the "ROM" is entirely fake, and is not just
some shadowed copy of a real underlying hardware ROM, but is
fundamentally just a RAM image decompressed from some other source and
then marked read-only.

   Linus

[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

[Chris Wilson]

On Thu, Apr 23, 2015 at 02:34:24PM +, Antoine, Peter wrote:
> Before the patch the system required rebooting (driver crash and/or kernel 
> panic).
> Now the application gets terminated.

It should have an GPF which should not have required a reboot, but
terminated the application. Unless you set it to automatically reboot.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2] modetest: initialize handles/pitches in set_plane()

[Tobias Jakobi]

Hello Ilia,

On 2015-04-21 21:15, Ilia Mirkin wrote:
> I know it was immensely useful to me when I was adding YUV plane
> support to nouveau. Seemed to work as advertised at the time (1.5y
> ago) for YUYV, UYVY, and NV12.
> 
>   -ilia
maybe you can help me with that question.

Let's consider a user of the DRM interface that wants to feed NV12 data 
to it. NV12 is bi-planar, so the user should provide two 
handles/pitches/offsets describing chroma and luma plane respectively. 
But most of the time chroma and luma is contiguous in memory, with 
nothing in between.

I was wondering if it is an allowed setup to request NV12 as 
pixelformat, but only to provide _one_ handle/pitch/offset? (implying 
that we are in the contiguous setting)


With best wishes,
Tobias

[PATCH] drm: Implement drmHandleEvent2()

[Tobias Jakobi]

Basically this is an extended version of drmHandleEvent().

drmHandleEvent() only handles core events (like e.g. page flips),
but since kernel DRM drivers might use vendor-specific events
to signal userspace the completion of pending jobs, etc., its
desirable to provide a way to handle these without putting
vendor-specific code in the core libdrm.

To use this you provide drmHandleEvent2() with a function that
handles your non-core events (and some opaque pointer).

The signature of that function looks like this:
void vendor(int fd, struct drm_event *e, void *custom_data);

'fd' is the DRM file descriptor, 'e' the non-core event, and
'custom_data' the aforementioned opaque pointer.

This way we don't have to maintain a copy of drmHandleEvent()
in the vendor code.

Signed-off-by: Tobias Jakobi 
---
 xf86drm.h | 13 +
 xf86drmMode.c | 10 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/xf86drm.h b/xf86drm.h
index 40c55c9..ad0ae1c 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -741,8 +741,21 @@ typedef struct _drmEventContext {

 } drmEventContext, *drmEventContextPtr;

+typedef void (*drmEventVendorHandler)(int fd, struct drm_event *e,
+   void *custom_data);
+
 extern int drmHandleEvent(int fd, drmEventContextPtr evctx);

+/*
+ * drmHandleEvent2() is an extended variant of drmHandleEvent() which
+ * allows handling of vendor-specific/non-core events.
+ * The function pointer 'vendorhandler' is used (if non-zero) to
+ * process non-core events. The opaque pointer 'data' is passed as
+ * the 'custom_data' argument.
+ */
+extern int drmHandleEvent2(int fd, drmEventContextPtr evctx,
+   drmEventVendorHandler vendorhandler, void *data);
+
 extern char *drmGetDeviceNameFromFd(int fd);
 extern int drmGetNodeTypeFromFd(int fd);

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 1333da4..e68e3e2 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -857,7 +857,8 @@ int drmModeCrtcSetGamma(int fd, uint32_t crtc_id, uint32_t 
size,
return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETGAMMA, );
 }

-int drmHandleEvent(int fd, drmEventContextPtr evctx)
+int drmHandleEvent2(int fd, drmEventContextPtr evctx,
+   drmEventVendorHandler vendorhandler, void *data)
 {
char buffer[1024];
int len, i;
@@ -900,6 +901,8 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
 U642VOID (vblank->user_data));
break;
default:
+   if (vendorhandler)
+   vendorhandler(fd, e, data);
break;
}
i += e->length;
@@ -908,6 +911,11 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
return 0;
 }

+int drmHandleEvent(int fd, drmEventContextPtr evctx)
+{
+   return drmHandleEvent2(fd, evctx, NULL, NULL);
+}
+
 int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t fb_id,
uint32_t flags, void *user_data)
 {
-- 
2.0.5

[Intel-gfx] [PATCH 2/5] drm: Fixes unsafe deference in locks.

[Chris Wilson]

On Thu, Apr 23, 2015 at 03:07:55PM +0100, Peter Antoine wrote:
> This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
> ioctl is called before the lock is created or after it has been destroyed.
> The code will deference a NULL pointer. This ioctl is a root ioctl so
> exploitation is limited.

You've turned an application crash into an application crash...
Just with a slightly less verbose kernel log.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

[Chris Wilson]

On Thu, Apr 23, 2015 at 03:07:54PM +0100, Peter Antoine wrote:
> This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
> is called by a application that has not had a lock created by it. This
> crash can be caused by any application from all users.

Crashing the application is still a crash...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 5/5] drm: Make Legacy Context access functions optional.

[Peter Antoine]

As these functions are only used by one driver and there are security holes
in these functions. Make the functions optional.

These changes are based on the two patches:
  commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
  Author: Dave Airlie 

And the commit that the above patch reverts:
  commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
  Author: Daniel Vetter 

This should now turn off the context feature.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/drm_context.c | 36 
 drivers/gpu/drm/drm_drv.c | 12 +++-
 2 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 1febcd3..09af26c 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -53,6 +53,9 @@ struct drm_ctx_list {
  */
 void drm_legacy_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
 {
+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
mutex_lock(>struct_mutex);
idr_remove(>ctx_idr, ctx_handle);
mutex_unlock(>struct_mutex);
@@ -87,6 +90,9 @@ static int drm_legacy_ctxbitmap_next(struct drm_device * dev)
  */
 int drm_legacy_ctxbitmap_init(struct drm_device * dev)
 {
+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
idr_init(>ctx_idr);
return 0;
 }
@@ -101,6 +107,9 @@ int drm_legacy_ctxbitmap_init(struct drm_device * dev)
  */
 void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
 {
+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
mutex_lock(>struct_mutex);
idr_destroy(>ctx_idr);
mutex_unlock(>struct_mutex);
@@ -119,6 +128,9 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev, 
struct drm_file *file)
 {
struct drm_ctx_list *pos, *tmp;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
mutex_lock(>ctxlist_mutex);

list_for_each_entry_safe(pos, tmp, >ctxlist, head) {
@@ -161,6 +173,9 @@ int drm_legacy_getsareactx(struct drm_device *dev, void 
*data,
struct drm_local_map *map;
struct drm_map_list *_entry;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
mutex_lock(>struct_mutex);

map = idr_find(>ctx_idr, request->ctx_id);
@@ -205,6 +220,9 @@ int drm_legacy_setsareactx(struct drm_device *dev, void 
*data,
struct drm_local_map *map = NULL;
struct drm_map_list *r_list = NULL;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
mutex_lock(>struct_mutex);
list_for_each_entry(r_list, >maplist, head) {
if (r_list->map
@@ -311,6 +329,9 @@ int drm_legacy_resctx(struct drm_device *dev, void *data,
struct drm_ctx ctx;
int i;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
if (res->count >= DRM_RESERVED_CONTEXTS) {
memset(, 0, sizeof(ctx));
for (i = 0; i < DRM_RESERVED_CONTEXTS; i++) {
@@ -341,6 +362,9 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
struct drm_ctx_list *ctx_entry;
struct drm_ctx *ctx = data;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
ctx->handle = drm_legacy_ctxbitmap_next(dev);
if (_DRM_LOCKING_CONTEXT(ctx->handle) == DRM_KERNEL_CONTEXT) {
/* Skip kernel's context and get a new one. */
@@ -384,6 +408,9 @@ int drm_legacy_getctx(struct drm_device *dev, void *data,
 {
struct drm_ctx *ctx = data;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
/* This is 0, because we don't handle any context flags */
ctx->flags = 0;

@@ -406,6 +433,9 @@ int drm_legacy_switchctx(struct drm_device *dev, void *data,
 {
struct drm_ctx *ctx = data;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
DRM_DEBUG("%d\n", ctx->handle);
return drm_context_switch(dev, dev->last_context, ctx->handle);
 }
@@ -426,6 +456,9 @@ int drm_legacy_newctx(struct drm_device *dev, void *data,
 {
struct drm_ctx *ctx = data;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
DRM_DEBUG("%d\n", ctx->handle);
drm_context_switch_complete(dev, file_priv, ctx->handle);

@@ -448,6 +481,9 @@ int drm_legacy_rmctx(struct drm_device *dev, void *data,
 {
struct drm_ctx *ctx = data;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
DRM_DEBUG("%d\n", ctx->handle);
if (_DRM_LOCKING_CONTEXT(ctx->handle) != 

[PATCH 4/5] drm: Make HW_LOCK access functions optional.

[Peter Antoine]

As these functions are only used by one driver and there are security holes
in these functions. Make the functions optional.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/drm_lock.c|  6 ++
 drivers/gpu/drm/i915/i915_dma.c   |  3 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c |  3 ++-
 include/drm/drmP.h| 23 ---
 include/uapi/drm/i915_drm.h   |  1 +
 5 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 94500930..b61d4c7 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -61,6 +61,9 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
struct drm_master *master = file_priv->master;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
++file_priv->lock_count;

if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
@@ -153,6 +156,9 @@ int drm_legacy_unlock(struct drm_device *dev, void *data, 
struct drm_file *file_
struct drm_lock *lock = data;
struct drm_master *master = file_priv->master;

+   if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
+   return -EINVAL;
+
if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
DRM_ERROR("Process %d using kernel context %d\n",
  task_pid_nr(current), lock->context);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e44116f..c771ef0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -163,6 +163,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
if (!value)
return -ENODEV;
break;
+   case I915_PARAM_HAS_LEGACY_CONTEXT:
+   value = drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT);
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8763deb..936b423 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -940,7 +940,8 @@ static struct drm_driver
 driver_stub = {
.driver_features =
DRIVER_USE_AGP |
-   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
+   DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
+   DRIVER_KMS_LEGACY_CONTEXT,

.load = nouveau_drm_load,
.unload = nouveau_drm_unload,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 62c40777..367e42f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -137,17 +137,18 @@ void drm_err(const char *format, ...);
 /*@{*/

 /* driver capabilities and requirements mask */
-#define DRIVER_USE_AGP 0x1
-#define DRIVER_PCI_DMA 0x8
-#define DRIVER_SG  0x10
-#define DRIVER_HAVE_DMA0x20
-#define DRIVER_HAVE_IRQ0x40
-#define DRIVER_IRQ_SHARED  0x80
-#define DRIVER_GEM 0x1000
-#define DRIVER_MODESET 0x2000
-#define DRIVER_PRIME   0x4000
-#define DRIVER_RENDER  0x8000
-#define DRIVER_ATOMIC  0x1
+#define DRIVER_USE_AGP 0x1
+#define DRIVER_PCI_DMA 0x8
+#define DRIVER_SG  0x10
+#define DRIVER_HAVE_DMA0x20
+#define DRIVER_HAVE_IRQ0x40
+#define DRIVER_IRQ_SHARED  0x80
+#define DRIVER_GEM 0x1000
+#define DRIVER_MODESET 0x2000
+#define DRIVER_PRIME   0x4000
+#define DRIVER_RENDER  0x8000
+#define DRIVER_ATOMIC  0x1
+#define DRIVER_KMS_LEGACY_CONTEXT  0x2

 /***/
 /** \name Macros to make printk easier */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 4851d66..0ad611a2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_REVISION  32
 #define I915_PARAM_SUBSLICE_TOTAL   33
 #define I915_PARAM_EU_TOTAL 34
+#define I915_PARAM_HAS_LEGACY_CONTEXT   35

 typedef struct drm_i915_getparam {
int param;
-- 
1.9.1

[PATCH 3/5] drm: Possible lock priority escalation.

[Peter Antoine]

If an application that has a driver lock created, wants the lock the
kernel context, it is not allowed to. If the call to drm_lock has a
context of 0, it is rejected. If you set the context to _DRM_LOCK_CONT
then call drm lock, it will pass the context == DRM_KERNEL_CONTEXT checks.
But as the DRM_LOCK_CONT bits are not part of the context id this allows
operations on the DRM_KERNEL_CONTEXT.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/drm_context.c | 6 +++---
 drivers/gpu/drm/drm_lock.c| 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 96350d1..1febcd3 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -123,7 +123,7 @@ void drm_legacy_ctxbitmap_flush(struct drm_device *dev, 
struct drm_file *file)

list_for_each_entry_safe(pos, tmp, >ctxlist, head) {
if (pos->tag == file &&
-   pos->handle != DRM_KERNEL_CONTEXT) {
+   _DRM_LOCKING_CONTEXT(pos->handle) != DRM_KERNEL_CONTEXT) {
if (dev->driver->context_dtor)
dev->driver->context_dtor(dev, pos->handle);

@@ -342,7 +342,7 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
struct drm_ctx *ctx = data;

ctx->handle = drm_legacy_ctxbitmap_next(dev);
-   if (ctx->handle == DRM_KERNEL_CONTEXT) {
+   if (_DRM_LOCKING_CONTEXT(ctx->handle) == DRM_KERNEL_CONTEXT) {
/* Skip kernel's context and get a new one. */
ctx->handle = drm_legacy_ctxbitmap_next(dev);
}
@@ -449,7 +449,7 @@ int drm_legacy_rmctx(struct drm_device *dev, void *data,
struct drm_ctx *ctx = data;

DRM_DEBUG("%d\n", ctx->handle);
-   if (ctx->handle != DRM_KERNEL_CONTEXT) {
+   if (_DRM_LOCKING_CONTEXT(ctx->handle) != DRM_KERNEL_CONTEXT) {
if (dev->driver->context_dtor)
dev->driver->context_dtor(dev, ctx->handle);
drm_legacy_ctxbitmap_free(dev, ctx->handle);
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 070dd5d..94500930 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -63,7 +63,7 @@ int drm_legacy_lock(struct drm_device *dev, void *data,

++file_priv->lock_count;

-   if (lock->context == DRM_KERNEL_CONTEXT) {
+   if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
DRM_ERROR("Process %d using kernel context %d\n",
  task_pid_nr(current), lock->context);
return -EINVAL;
@@ -153,7 +153,7 @@ int drm_legacy_unlock(struct drm_device *dev, void *data, 
struct drm_file *file_
struct drm_lock *lock = data;
struct drm_master *master = file_priv->master;

-   if (lock->context == DRM_KERNEL_CONTEXT) {
+   if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
DRM_ERROR("Process %d using kernel context %d\n",
  task_pid_nr(current), lock->context);
return -EINVAL;
-- 
1.9.1

[PATCH 2/5] drm: Fixes unsafe deference in locks.

[Peter Antoine]

This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
ioctl is called before the lock is created or after it has been destroyed.
The code will deference a NULL pointer. This ioctl is a root ioctl so
exploitation is limited.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/drm_context.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 9b23525..96350d1 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -277,7 +277,13 @@ static int drm_context_switch_complete(struct drm_device 
*dev,
 {
dev->last_context = new;/* PRE/POST: This is the _only_ writer. 
*/

-   if (!_DRM_LOCK_IS_HELD(file_priv->master->lock.hw_lock->lock)) {
+   if (file_priv->master->lock.hw_lock == NULL) {
+   DRM_ERROR(
+   "Device has been unregistered. Hard exit. Process %d\n",
+   task_pid_nr(current));
+   send_sig(SIGTERM, current, 0);
+   return -EPERM;
+   } else if (!_DRM_LOCK_IS_HELD(file_priv->master->lock.hw_lock->lock)) {
DRM_ERROR("Lock isn't held after context switch\n");
}

-- 
1.9.1

[PATCH 1/5] drm: Kernel Crash in drm_unlock

[Peter Antoine]

This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
is called by a application that has not had a lock created by it. This
crash can be caused by any application from all users.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/drm_lock.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index f861361..070dd5d 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -159,6 +159,14 @@ int drm_legacy_unlock(struct drm_device *dev, void *data, 
struct drm_file *file_
return -EINVAL;
}

+   if (!master->lock.hw_lock) {
+   DRM_ERROR(
+   "Device has been unregistered. Hard exit. Process %d\n",
+   task_pid_nr(current));
+   send_sig(SIGTERM, current, 0);
+   return -EPERM;
+   }
+
if (drm_legacy_lock_free(>lock, lock->context)) {
/* FIXME: Should really bail out here. */
}
-- 
1.9.1

[PATCH 0/5] HW_LOCK Security Patches

[Peter Antoine]

The following series of patches fix a number of security holes in the i915
driver (actually in drm but...). The first three patches remove the actual
security issues that have been found. The last two patches make the functions
optional for all drivers. The only driver that has this feature turned on is
the Nouveau driver, thus hopefully not breaking that driver.

The patch set has been tested on the Intel platforms but has not been tested
on the Nouveau driver. Hopefully someone with a working card and the right
combination of drmlib can verify that the patches do what they say.

There is a i-g-t test that goes with this patchset, but that test SHOULD NOT
be run before the kernel is patches as the test will crash the driver and/or
make the kernel panic.

Peter.

Peter Antoine (5):
  drm: Kernel Crash in drm_unlock
  drm: Fixes unsafe deference in locks.
  drm: Possible lock priority escalation.
  drm: Make HW_LOCK access functions optional.
  drm: Make Legacy Context access functions optional.

 drivers/gpu/drm/drm_context.c | 50 ---
 drivers/gpu/drm/drm_drv.c | 12 +
 drivers/gpu/drm/drm_lock.c| 18 +++--
 drivers/gpu/drm/i915/i915_dma.c   |  3 +++
 drivers/gpu/drm/nouveau/nouveau_drm.c |  3 ++-
 include/drm/drmP.h| 23 
 include/uapi/drm/i915_drm.h   |  1 +
 7 files changed, 87 insertions(+), 23 deletions(-)

-- 
1.9.1

[PATCH i-g-t] tests/drm_hw_lock: Tests for hw_lock fixes.

[Peter Antoine]

There are several issues with the hardware locks functions that stretch
from kernel crashes to priority escalations. This new test will test the
the fixes for these features.

This test will cause a driver/kernel crash on un-patched kernels, the
following patches should be applied to stop the crashes:

  drm: Kernel Crash in drm_unlock
  drm: Fixes unsafe deference in locks.

Issue: VIZ-5485
Signed-off-by: Peter Antoine 
---
 lib/ioctl_wrappers.c   |  19 +
 lib/ioctl_wrappers.h   |   1 +
 tests/Makefile.sources |   1 +
 tests/drm_hw_lock.c| 207 +
 4 files changed, 228 insertions(+)
 create mode 100644 tests/drm_hw_lock.c

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 000d394..ad8b3d3 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -964,6 +964,25 @@ bool gem_has_bsd2(int fd)
 {
return gem_has_enable_ring(fd,LOCAL_I915_PARAM_HAS_BSD2);
 }
+#define I915_PARAM_HAS_LEGACY_CONTEXT   35
+bool drm_has_legacy_context(int fd)
+{
+   int tmp = 0;
+   drm_i915_getparam_t gp;
+
+   memset(, 0, sizeof(gp));
+   gp.value = 
+   gp.param = I915_PARAM_HAS_LEGACY_CONTEXT;
+
+   /*
+* if legacy context param is not supported, then it's old and we
+* can assume that the HW_LOCKS are supported.
+*/
+   if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) != 0)
+   return true;
+
+   return tmp == 1;
+}
 /**
  * gem_available_aperture_size:
  * @fd: open i915 drm file descriptor
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index ced7ef3..3adc700 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -120,6 +120,7 @@ bool gem_has_bsd(int fd);
 bool gem_has_blt(int fd);
 bool gem_has_vebox(int fd);
 bool gem_has_bsd2(int fd);
+bool drm_has_legacy_context(int fd);
 bool gem_uses_aliasing_ppgtt(int fd);
 int gem_available_fences(int fd);
 uint64_t gem_available_aperture_size(int fd);
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 71de6de..2f69afc 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -84,6 +84,7 @@ TESTS_progs_M = \
pm_sseu \
prime_self_import \
template \
+   drm_hw_lock \
$(NULL)

 TESTS_progs = \
diff --git a/tests/drm_hw_lock.c b/tests/drm_hw_lock.c
new file mode 100644
index 000..aad50ba
--- /dev/null
+++ b/tests/drm_hw_lock.c
@@ -0,0 +1,207 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Peter Antoine 
+ */
+
+/*
+ * Testcase: Test the HW_LOCKs for correct support and non-crashing.
+ *
+ * This test will check that he hw_locks are only g_supported for drivers that
+ * require that support. If it is not g_supported then the functions all return
+ * the correct error code.
+ *
+ * If g_supported it will check that the functions do not crash when the crash
+ * tests are used, also that one of the tests is a security level escalation
+ * that should be rejected.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "drmtest.h"
+#include "igt_core.h"
+#include "ioctl_wrappers.h"
+
+#ifndef DRM_KERNEL_CONTEXT
+#  define DRM_KERNEL_CONTEXT   (0)
+#endif
+
+#ifndef _DRM_LOCK_HELD
+#  define _DRM_LOCK_HELD   0x8000U /**< Hardware lock is held */
+#endif
+
+#ifndef _DRM_LOCK_CONT
+#  define _DRM_LOCK_CONT   0x4000U /**< Hardware lock is contended */
+#endif
+
+static boolg_sig_fired;
+static boolg_supported;
+static struct sigaction old_action;
+
+static void sig_term_handler(int value)
+{
+   g_sig_fired = true;
+}
+
+static bool set_term_handler(void)
+{
+   static struct sigaction new_action;
+
+   new_action.sa_handler = sig_term_handler;
+   sigemptyset(_action.sa_mask);
+   new_action.sa_flags = 0;
+
+   igt_assert(sigaction(SIGTERM, _action, _action) == 0);
+
+   if 

[PATCH v4 09/10] cec: adv7511: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support to the adv7511 driver.

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

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 12d9320..d56e110 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

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

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

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

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

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

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

[PATCH v4 08/10] cec: adv7604: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support to the adv7604 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
[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]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7604.c |  207 ++-
 1 file changed, 206 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 60ffcf0..4921276 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -38,6 +38,7 @@
 #include 

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

 #define ADV76XX_OP_SWAP_CB_CR  (1 << 0)

+#define ADV76XX_MAX_ADDRS (3)
+
 enum adv76xx_type {
ADV7604,
ADV7611,
@@ -159,6 +162,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;
@@ -424,7 +431,15 @@ 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_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+   return io_write(sd, reg, (io_read(sd, reg) & mask) | 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);
 }
@@ -457,6 +472,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_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+}
+
 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
 {
struct adv76xx_state *state = to_state(sd);
@@ -1865,6 +1886,183 @@ 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 int adv76xx_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv76xx_state *state = to_state(sd);
+

[PATCH v4 07/10] v4l2-subdev: add HDMI CEC ops

[Kamil Debski]

From: Hans Verkuil 

Add callbacks to the v4l2_subdev_video_ops.

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

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

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

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

 /*
-- 
1.7.9.5

[PATCH v4 06/10] cec: add HDMI CEC framework

[Kamil Debski]

From: 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]
Signed-off-by: Kamil Debski 
---
 Documentation/cec.txt |  396 
 drivers/media/Kconfig |6 +
 drivers/media/Makefile|2 +
 drivers/media/cec.c   | 1161 +
 include/media/cec.h   |  140 ++
 include/uapi/linux/Kbuild |1 +
 include/uapi/linux/cec.h  |  303 
 7 files changed, 2009 insertions(+)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..2b6c08a
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,396 @@
+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_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK  4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM   5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV  (1 << 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD  (1 << 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER   (1 << 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH  (1 << 2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV   0
+#define CEC_LOG_ADDR_TYPE_RECORD   1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM  4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B   5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+   /* internal fields removed */
+
+   u16 phys_addr;
+   u32 capabilities;
+   u8 version;
+   u8 num_log_addrs;
+   u8 prim_device[CEC_MAX_LOG_ADDRS];
+   u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+   u8 log_addr[CEC_MAX_LOG_ADDRS];
+
+   int (*adap_enable)(struct cec_adapter *adap, bool enable);
+   int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+   int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+   

[PATCH v4 05/10] rc: Add HDMI CEC protoctol handling

[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 
---
 drivers/media/rc/keymaps/Makefile |1 +
 drivers/media/rc/keymaps/rc-cec.c |  144 +
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-core.h   |1 +
 include/media/rc-map.h|5 +-
 5 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

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

[PATCH v4 04/10] HID: add HDMI CEC specific keycodes

[Kamil Debski]

Add HDMI CEC specific keycodes to the keycodes definition.

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

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 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
-- 
1.7.9.5

[PATCH v4 03/10] dts: exynos4412-odroid*: enable the HDMI CEC device

[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 
---
 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 8de12af..e50862d 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -469,6 +469,10 @@
status = "okay";
};

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

[PATCH v4 02/10] dts: exynos4: add node for the HDMI CEC device

[Kamil Debski]

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

Signed-off-by: Kamil Debski 
---
 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>;
-- 
1.7.9.5

[PATCH v4 01/10] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[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 
---
 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 {
-- 
1.7.9.5

[PATCH v4 00/10] HDMI CEC framework

[Kamil Debski]

Hi,

This is the fourth version of the HDMI CEC framework. I would like to thank
for all the comments and suggestions to the previous versions of this patch.
I believe that the code has matured enough to be tagged as PATCH and not RFC
as in previous version.

This patchset is base on the linux-next tree. I believe that there will be
some comments to it and there will be some things to fix, hence I am sending
this version now. The next version with appropriate fixes will be based on the
next RC (which I guess will be released soon).

The promiscuous mode included in the previous version caused some discussion and
I decided to drop it. In my opinion it can be useful for debugging, but on the
other hand I believe it can be easily added at a later time, if appropriate.

Best wishes,
Kamil Debski

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 to the cec.h file

Original cover letter
=

Hi,

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

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

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

Best wishes,
Kamil Debski

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

Hans Verkuil (4):
  cec: add HDMI CEC framework
  v4l2-subdev: add HDMI CEC ops
  cec: adv7604: add cec support.
  cec: adv7511: add cec support.

Kamil Debski (6):
  dts: exynos4*: add HDMI CEC pin definition to pinctrl
  dts: exynos4: add node for the HDMI CEC device
  dts: exynos4412-odroid*: enable the HDMI CEC device
  HID: add HDMI CEC specific keycodes
  rc: Add HDMI CEC protoctol handling
  cec: s5p-cec: Add s5p-cec driver

 Documentation/cec.txt  |  396 +++
 .../devicetree/bindings/media/s5p-cec.txt  |   33 +
 arch/arm/boot/dts/exynos4.dtsi |   12 +
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi  |7 +
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 +
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi  |7 +
 drivers/media/Kconfig  |6 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c| 1161 
 drivers/media/i2c/adv7511.c|  347 +-
 drivers/media/i2c/adv7604.c|  207 +++-
 drivers/media/platform/Kconfig |   10 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 ++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  283 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |   76 ++
 drivers/media/rc/keymaps/Makefile  |1 +
 drivers/media/rc/keymaps/rc-cec.c  |  144 +++
 drivers/media/rc/rc-main.c |1 +
 include/media/adv7511.h|6 +-
 include/media/cec.h|  140 +++
 include/media/rc-core.h|1 +
 include/media/rc-map.h |5 +-
 include/media/v4l2-subdev.h|8 +
 include/uapi/linux/Kbuild  |1 +
 include/uapi/linux/cec.h   |  303 +
 include/uapi/linux/input.h |   12 +
 30 files changed, 

git pull] drm for v4.1-rc1

[Matthew Garrett]

On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas  wrote:

> Your i915 does not have a ROM BAR in hardware.  If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
> shadow ROM image at 0xC.  Is there a shadow image even if the
> device itself doesn't have a ROM BAR?

On UEFI systems, there's no special reason to believe that there's
anything at 0xc - it depends on whether a CSM got loaded or not.
Everything is awful. So...

>   int pcibios_add_device(struct pci_dev *dev)
>   {
> if (dev-is-default-vga-device) {
>   dev->rom = 0xC;
>   dev->romlen = 0x2;
> }

I don't know what we want to do here. This is, at some level,
fundamentally wrong - however, it also wouldn't surprise me if this is
also the only copy of the video ROM we have on some UEFI systems,
especially since I believe that Windows 7 still required that there be
a legacy ROM it could use for bootloader modesetting on UEFI
platforms. So simply making this conditional on BIOS may break
existing machines. But if there *is* a ROM there then we should be
able to id it from the usual video ROM signature?

[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

[Antoine, Peter]

Before the patch the system required rebooting (driver crash and/or kernel 
panic).
Now the application gets terminated.

This follows the pattern in the other parts of this code that checks that 
pointer.

Peter.

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Thursday, April 23, 2015 3:20 PM
To: Antoine, Peter
Cc: intel-gfx at lists.freedesktop.org; airlied at redhat.com; dri-devel at 
lists.freedesktop.org; daniel.vetter at ffwll.ch
Subject: Re: [Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock

On Thu, Apr 23, 2015 at 03:07:54PM +0100, Peter Antoine wrote:
> This patch fixes a possible kernel crash when drm_unlock 
> (DRM_IOCTL_UNLOCK) is called by a application that has not had a lock 
> created by it. This crash can be caused by any application from all users.

Crashing the application is still a crash...
-Chris

--
Chris Wilson, Intel Open Source Technology Centre

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #40 from Alex Deucher  ---
(In reply to Alex Deucher from comment #39)
> (In reply to Christophe Migliorini from comment #38)
> > Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply
> > ok and it works.  Sorry for the inconvenience.
> > (perhaps one should consider pushing these two upstream instead of the fist
> > one?)...
> 
> Those patches are upstream as well.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bc13018b5eba26ca229b33763c9e61fac31a1925
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8aff6ad5a393b8e2ad00dce4d278ecf41397bf0d

-- 
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/20150423/a201466c/attachment.html>

[PATCH] drm/msm: Attach assigned encoder to eDP and DSI connectors

[Hai Li]

drm_mode_connector_attach_encoder() function call is missing
during eDP and DSI connector initialization. As a result,
no encoder is returned by DRM_IOCTL_MODE_GETCONNECTOR system
call. This change is to fix this issue.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.c   | 10 +-
 drivers/gpu/drm/msm/dsi/dsi_manager.c   |  6 +-
 drivers/gpu/drm/msm/edp/edp_connector.c |  2 ++
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 28d1f95..ad50b80 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -177,6 +177,11 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}

+   for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
+   encoders[i]->bridge = msm_dsi->bridge;
+   msm_dsi->encoders[i] = encoders[i];
+   }
+
msm_dsi->connector = msm_dsi_manager_connector_init(msm_dsi->id);
if (IS_ERR(msm_dsi->connector)) {
ret = PTR_ERR(msm_dsi->connector);
@@ -185,11 +190,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}

-   for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
-   encoders[i]->bridge = msm_dsi->bridge;
-   msm_dsi->encoders[i] = encoders[i];
-   }
-
priv->bridges[priv->num_bridges++]   = msm_dsi->bridge;
priv->connectors[priv->num_connectors++] = msm_dsi->connector;

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index ee3ebca..0a40f3c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -462,7 +462,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct drm_connector *connector = NULL;
struct dsi_connector *dsi_connector;
-   int ret;
+   int ret, i;

dsi_connector = devm_kzalloc(msm_dsi->dev->dev,
sizeof(*dsi_connector), GFP_KERNEL);
@@ -495,6 +495,10 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
if (ret)
goto fail;

+   for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
+   drm_mode_connector_attach_encoder(connector,
+   msm_dsi->encoders[i]);
+
return connector;

 fail:
diff --git a/drivers/gpu/drm/msm/edp/edp_connector.c 
b/drivers/gpu/drm/msm/edp/edp_connector.c
index d8812e8..b4d1b46 100644
--- a/drivers/gpu/drm/msm/edp/edp_connector.c
+++ b/drivers/gpu/drm/msm/edp/edp_connector.c
@@ -151,6 +151,8 @@ struct drm_connector *msm_edp_connector_init(struct msm_edp 
*edp)
if (ret)
goto fail;

+   drm_mode_connector_attach_encoder(connector, edp->encoder);
+
return connector;

 fail:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #39 from Alex Deucher  ---
(In reply to Christophe Migliorini from comment #38)
> Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply
> ok and it works.  Sorry for the inconvenience.
> (perhaps one should consider pushing these two upstream instead of the fist
> one?)...

Those patches are upstream as well.

-- 
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/20150423/e3594312/attachment.html>

[PATCH 2/2] drm/exynos: cleanup exynos_drm_plane

[Tobias Jakobi]

Remove the unused fields of struct exynos_drm_plane.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e12ecb5..c80331b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -73,11 +73,6 @@ enum exynos_drm_output_type {
  * @zpos: order of overlay layer(z position).
  * @index_color: if using color key feature then this value would be used
  * as index color.
- * @default_win: a window to be enabled.
- * @color_key: color key on or off.
- * @local_path: in case of lcd type, local path mode on or off.
- * @transparency: transparency on or off.
- * @activated: activated or not.
  * @enabled: enabled or not.
  * @resume: to resume or not.
  *
@@ -110,11 +105,6 @@ struct exynos_drm_plane {
unsigned int zpos;
unsigned int index_color;

-   bool default_win:1;
-   bool color_key:1;
-   bool local_path:1;
-   bool transparency:1;
-   bool activated:1;
bool enabled:1;
bool resume:1;
 };
-- 
2.0.5

[PATCH 1/2] drm/exynos: mixer: cleanup pixelformat handling

[Tobias Jakobi]

Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Then select the mixer pixelformat (pf) in mixer_graph_buffer() based on
the plane's pf (and not bpp).
Also add handling of RGB565 and XRGB1555 to the switch statement and
exit early if the plane has an unsupported pf.

Partially based on 'drm/exynos: enable/disable blend based on pixel
format' by Gustavo Padovan .

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index fbec750..1bd23ee 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -44,6 +44,12 @@
 #define MIXER_WIN_NR   3
 #define MIXER_DEFAULT_WIN  0

+/* The pixelformats that are natively supported by the mixer. */
+#define MIXER_PIXELFORMAT_RGB565 4
+#define MIXER_PIXELFORMAT_ARGB1555 5
+#define MIXER_PIXELFORMAT_ARGB 6
+#define MIXER_PIXELFORMAT_ARGB 7
+
 struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -531,20 +537,26 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)

plane = >planes[win];

-   #define RGB565 4
-   #define ARGB1555 5
-   #define ARGB 6
-   #define ARGB 7
+   switch (plane->pixel_format) {
+   case DRM_FORMAT_XRGB:
+   fmt = MIXER_PIXELFORMAT_ARGB;
+   break;
+
+   case DRM_FORMAT_XRGB1555:
+   fmt = MIXER_PIXELFORMAT_ARGB1555;
+   break;

-   switch (plane->bpp) {
-   case 16:
-   fmt = ARGB;
+   case DRM_FORMAT_RGB565:
+   fmt = MIXER_PIXELFORMAT_RGB565;
break;
-   case 32:
-   fmt = ARGB;
+
+   case DRM_FORMAT_XRGB:
+   fmt = MIXER_PIXELFORMAT_ARGB;
break;
+
default:
-   fmt = ARGB;
+   DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
+   return;
}

/* check if mixer supports requested scaling setup */
-- 
2.0.5

drm/exynos: two small fixes (v2)

[Tobias Jakobi]

Hello,

I've modified the two patches in [1] so that they now apply to Inki's 
exynos-drm-next branch. The pixelformat one was rewritten, so that it doesn't 
rely on Gustavo's blending patch (which seems to need 
more discussion). The field cleanup patch was extended as Joonyoung suggested.

Since the patches changes considerably during that, I've dropped the rb tags 
(I'm not sure how this is handled?)

With best wishes,
Tobias


[1] http://www.spinics.net/lists/linux-samsung-soc/msg43702.html

[Bug 90151] Laptop Backlight Issue with Hybrid Graphics System

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

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

Alex Deucher  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

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

[PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent

[Tobias Jakobi]

Hello Emil,

On 2015-04-21 20:14, Emil Velikov wrote:
> Hi Tobias,
> 
> On 30/03/15 13:04, Tobias Jakobi wrote:
>> Hello,
>> 
>> On 2015-03-30 02:02, Rob Clark wrote:
>>> so, iirc, vmwgfx also has some custom events..  not really sure if
>>> they have their own hand-rolled drmHandleEvent() or if they have
>>> another way of catching those.
>>> 
>>> Maybe we need some more flexible way to register handlers for driver
>>> custom events?  But everyone adding their own thing to
>>> drmHandleEvent() doesn't really seem so nice..  that said, I'm not
>>> sure how much to care.  If it is just exynos and vmwgfx, then telling
>>> them to use there own version of of drmHandleEvent() might be ok.  
>>> But
>>> if driver custom events somehow become more popular, maybe we want a
>>> better solution..
>> 
>> would something like this work for you guys:
>> https://www.math.uni-bielefeld.de/~tjakobi/archive/0001-custom-events.patch
>> 
>> (this is not compile tested or anything, just a draft)
>> 
>> Basically this introduces drmHandleEvent2, which is drmHandleEvent 
>> with
>> two additional arguments. The first one being a function pointer 
>> through
>> which the 'remaining' events (which are not handled by the common 
>> code)
>> are handled, and some (opaque) pointer to data that the handler might 
>> need.
>> 
>> In the vendor specific code I then introcuded exynos_handle_event 
>> which
>> calls dramHandleEvent2 with a properly setup handler. vmwgfx could do
>> the same here I guess.
>> 
> I'm assuming that one of the concerns here is about adding API for a
> single (and not so common) user to the core library.
> 
> From a quick look at the mesa and xf86-video-vmware I cannot see the
> vmwgfx driver using events. It has some definitions in vmwgfx_drm.h but
> that's about it.
> 
> That aside - the drmHandleEvent2 approach looks like a massive
> improvement over the original patch. Personally I do not see any
> problems with it and think that it's a good way forward.
> 
> Perhaps you can come over to #dri-devel and ping the devs to get some
> more feedback. As the topic is not a priority for most of them your
> suggestions has mostly gone unnoticed.
I'm going to flesh out the non-exynos patches some more before sending 
them to the ML for discussion.


With best wishes,
Tobias

Initial amdgpu driver release

[Emil Velikov]

On 21/04/15 16:41, Alex Deucher wrote:
> On Tue, Apr 21, 2015 at 11:56 AM, Emil Velikov  
> wrote:
>> Hi Alex,
>>
>> On 20 April 2015 at 23:33, Alex Deucher  wrote:
>>> I'm pleased to announce the initial release of the new amdgpu driver.
>>> This is a partial replacement for the radeon driver for newer AMD
>>> asics.  A number of components are still shared.  Here is a comparison
>>> of the radeon and amdgpu stacks:
>>>
>>> 1. radeon stack
>>> kernel driver: radeon.ko
>>> libdrm: libdrm_radeon
>>> mesa: radeon, r200, r300, r600, radeonsi
>>> ddx: xf86-video-ati
>>>
>>> 2. amdgpu stack
>>> kernel driver: amdgpu.ko
>>> libdrm: libdrm_amdgpu
>>> mesa: radeonsi
>>> ddx: xf86-video-amdgpu
>>>
>>> Older asics will continue to be supported by the radeon stack; new
>>> asics will be supported by the amdgpu stack.  CI (Sea Islands) asics
>>> have support in both driver stacks, but this is purely for testing
>>> purposes.  CI parts are officially supported in the radeon stack.
>>> Support for CI on the amdgpu stack is determined by a config option in
>>> the kernel.  CI support is not enabled by default for amdgpu.
>>>
>>> Most of our focus has been on Carrizo support, so there are some gaps
>>> in the dGPU support for Tonga and Iceland, notably power management.
>>> Those gaps will be filled in eventually.
>>>
>>> Also included in this code base are full register headers for just
>>> about every block on the asics.
>>>
>>> Barring the gaps mentioned above, the driver stack is functionally on
>>> par with radeon including:
>>> - OpenGL 3.3 support using the radeonsi mesa driver
>>> - Video decode support using UVD
>>> - Video encode support using VCE
>>>
>>> The code can be found in the amdgpu branches of the following git trees.
>>> xf86-video-amdgpu:
>>> http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu
>>> libdrm:
>>> http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu
>>> kernel:
>>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu
>>> mesa:
>>> http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
>>>
>>> To test the new driver stack you will need to specify a device section
>>> in your xorg.conf with the driver set to amdgpu rather than radeon.
>>>
>>> Please review!
>>>
>> Do you plan to sending out the libdrm patches to the ML ? I have a few
>> comments that you might be interested in :-)
> 
> Yeah, just sent them out now.  Ran out of time last night.  Some of
> the patches in the kernel and the ddx patch are really big so probably
> too big for the ML.
> 
Fair enough, did not mean to come out as impatient - was the first thing
that pope at my email client after a short break.

Just a random question on the ddx front - do you see many benefits of
supporting old xservers ? If you target xserver 1.16 and later you can
drop a fair bit of code/wrappers
 - Non DRI2 enabled xserver.
 - HAS_DEVPRIVATEKEYREC (new with 1.10, released 4+ years ago)
 - xorg-list (new with 1.12, released 3+ years ago)
 - DRI2_PRIME (new with 1.13, released 2+ years ago)
 - AMDGPU_PIXMAP_SHARING (XF86_CRTC_VERSION >= 5, new with 1.13)
 - Support for external the glamor library (new with 1.16)

While you're there you might want to drop support for xextproto pre 7.1.
7.1.0 was released 6+ years ago.

The README and .gitignore mention xf86-video-ati.

Hope you find any of the above useful :)

-Emil

[Bug 25361] realloc(): invalid next size in cs_begin at radeon_cs_legacy.c

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

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

Christian Hartmann  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Christian Hartmann  ---
just out of date

-- 
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/20150423/ee90b1a7/attachment.html>

[PATCH v2] modetest: initialize handles/pitches in set_plane()

[Ilia Mirkin]

On Thu, Apr 23, 2015 at 9:39 AM, Tobias Jakobi
 wrote:
> Hello Ilia,
>
> On 2015-04-21 21:15, Ilia Mirkin wrote:
>>
>> I know it was immensely useful to me when I was adding YUV plane
>> support to nouveau. Seemed to work as advertised at the time (1.5y
>> ago) for YUYV, UYVY, and NV12.
>>
>>   -ilia
>
> maybe you can help me with that question.
>
> Let's consider a user of the DRM interface that wants to feed NV12 data to
> it. NV12 is bi-planar, so the user should provide two
> handles/pitches/offsets describing chroma and luma plane respectively. But
> most of the time chroma and luma is contiguous in memory, with nothing in
> between.
>
> I was wondering if it is an allowed setup to request NV12 as pixelformat,
> but only to provide _one_ handle/pitch/offset? (implying that we are in the
> contiguous setting)

Uhm... I'm no authority on the matter, merely vouching for the
usefulness of the modetest tool :) However I was never aware of any
contiguousness assumptions in NV12, afaik the two different planes are
different :) It could also cause issues if you had, a, say, 32x30
image but whatever hw produced it wanted to make it 32x32. You'd end
up with an offset between the two planes which wouldn't be specified.
FWIW on the (much older) NVIDIA gpu's that I added support for, it
assumes a separate offset:

nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
nv_fb->nvbo->bo.offset + fb->offsets[1]);

Note that as far as the HW is concerned, it's an entirely separate
memory location, not even an offset from the Y plane -- it could be 2
totally separate bo's for all it cares.

Also, as another datapoint, the VP3 and newer video decoding units on
NVIDIA cards (generally speaking GeForce 200+) have firmware that
produces the Y and UV data as completely separate pieces of data as
well. On VP2 they had to be in the same buffer, but you could provide
an explicit offset to the UV bit.

  -ilia

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #38 from Christophe Migliorini <mig+freedesktop at 
chene.vingt-et-un-cinq.fr> ---
Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply ok
and it works.  Sorry for the inconvenience.
(perhaps one should consider pushing these two upstream instead of the fist
one?)...

-- 
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/20150423/998cd162/attachment.html>