date:20161024



On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> Looks like .last_flush reference is left at teardown.
> Leak reported by CONFIG_SLUB_DEBUG.
>
> Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
> Signed-off-by: Grazvydas Ignotas 
Reviewed-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index ded57dd..d6c2839 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1774,5 +1774,6 @@ void amdgpu_vm_manager_fini(struct amdgpu_device *adev)
>   fence_put(adev->vm_manager.ids[i].first);
>   amdgpu_sync_free(&adev->vm_manager.ids[i].active);
>   fence_put(id->flushed_updates);
> + fence_put(id->last_flush);
>   }
>   }

[Bug 95017] [drm:radeon_ib_ring_tests] ERROR radeon: failed testing IB on GFX ring (-35).

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

--- Comment #17 from Michel DÃ¤nzer  ---
(In reply to erhard_f from comment #15)
> Played around a bit with xorg and kernel options on my G5 and worked out
> that I can drive the Radeon 9650 at AGP x8 if I disable DRI completely via
> Option "NoAccel" "true" in /etc/xorg.conf.
> 
> I had no GPU-lockups since then

Sure, because you're not actually using the problematic AGP functionality. :)


> and xorg is much more responsive despite lacking DRI hardware acceleration
> (radeon.agpmode=-1 with DRI enabled).

FWIW, the value of the radeon.agpmode parameter shouldn't matter if you disable
DRI (which BTW means no GPU hardware acceleration can be used at all).

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

[PATCH] drm/amdgpu: fix sched fence slab teardown

Acked-by: Chunming Zhou 

On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
> after a grace period. During teardown, there is no guarantee all
> callbacks have finished, so sched_fence_slab may be destroyed before
> all fences have been freed. If we are lucky, this results in some slab
> warnings, if not, we get a crash in one of rcu threads because callback
> is called after amdgpu has already been unloaded.
>
> Fix it with a rcu_barrier().
>
> Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release")
> Signed-off-by: Grazvydas Ignotas 
> ---
>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index 963a24d..910b8d5 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
>   {
>   if (sched->thread)
>   kthread_stop(sched->thread);
> + rcu_barrier();
>   if (atomic_dec_and_test(&sched_fence_slab_ref))
>   kmem_cache_destroy(sched_fence_slab);
>   }

[PATCH] drm/amdgpu: release parent fence reference



On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> It's done in amd_sched_hw_job_reset(), but not in normal job processing.
> Leak reported by CONFIG_SLUB_DEBUG.
>
> Signed-off-by: Grazvydas Ignotas 
> ---
>   CONFIG_SLUB_DEBUG reports more leaks related to ioctls,
>   but I was unable to track them down...
>
>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index 910b8d5..cfb686e 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -522,6 +522,8 @@ static void amd_sched_process_job(struct fence *f, struct 
> fence_cb *cb)
>   
>   trace_amd_sched_process_job(s_fence);
>   fence_put(&s_fence->finished);
> + fence_put(s_fence->parent);
If I remember correctly, parent was put in sched fence release.

Regards,
David Zhou
> + s_fence->parent = NULL;
>   wake_up_interruptible(&sched->wake_up_worker);
>   }
>

[PATCH] drm/amdgpu: fix fence slab teardown

Acked-by: Chunming Zhou 

On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> To free fences, call_rcu() is used, which calls amdgpu_fence_free()
> after a grace period. During teardown, there is no guarantee all
> callbacks have finished, so amdgpu_fence_slab may be destroyed before
> all fences have been freed. If we are lucky, this results in some slab
> warnings, if not, we get a crash in one of rcu threads because callback
> is called after amdgpu has already been unloaded.
>
> Fix it with a rcu_barrier().
>
> Fixes: b44135351a3a ("drm/amdgpu: RCU protected amdgpu_fence_release")
> Signed-off-by: Grazvydas Ignotas 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> index 3a2e42f..77b34ec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> @@ -68,6 +68,7 @@ int amdgpu_fence_slab_init(void)
>   
>   void amdgpu_fence_slab_fini(void)
>   {
> + rcu_barrier();
>   kmem_cache_destroy(amdgpu_fence_slab);
>   }
>   /*

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call



On 10/22/2016 12:13 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>>
>>
>> On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote:
>>> On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:


 On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
>> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
>>> On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
 In any case, I don't agree with converting it to a DRM bridge - that
 will mean that we have to split the driver into two pieces, the bridge
 part handling the mode set specifics, and a connector/encoder part 
 which
 handles the detection/edid stuff.

 We might as well keep the whole thing as the classical 
 connector/encoder
 rather than introducing this additional layer of complexity.
>>>
>>> We have different ways to instantiate external HDMI encoders, and that's
>>> not good. I believe everybody agrees that drm encoder slave has to go, 
>>> so
>>> that's already one problem solved (or rather solvable, it still requires
>>> someone to do the work). We will then be left with two different 
>>> methods,
>>> drm bridge and non-bridge component-based instantiation. We need to
>>> somehow merge the two, and I'm open to discussions on how the end result
>>> should look like.
>>
>> I think you're idea really doesn't work - and I think your idea that
>> component-based is somehow separate from other methods is wrong.
>>
>> Look at iMX for example - even converting all the code that could be
>> a bridge to be a bridge will not get rid of its use of the component
>> instantiation, because you still have other components that need to
>> come from elsewhere.  The same is true of armada as well.
>
> Don't get me wrong, I'm certainly not against the component framework 
> itself.
> A way to bind multiple independent devices together is needed. We have a
> similar framework in V4L2 called v4l2-async, and I'd like to see it moved 
> to
> the component framework at some point to unify code. Some changes to the
> component framework might be needed to support needs of V4L2 that are
> currently not applicable to DRM/KMS, but there's nothing major there.
>
>> Moreover, as I've already said, converting tda998x to a DRM bridge
>> will not get rid of the encoder/connector part, because it _is_ a
>> connector in the DRM sense - it provides the detection and EDID
>> reading.
>>
>> So, what would we achieve by splitting the driver into a DRM bridge
>> and DRM encoder/connector?
>
> Please note that DRM bridge doesn't split the DRM connector out of the 
> bridge,
> bridges instantiate drm_connector objects. In that sense they don't differ
> much from the model implemented by the tda998x driver.
>
> I however believe that connectors should be split out DRM bridge drivers, 
> for
> the simple reason that bridges can be chained. The output of a bridge 
> isn't
> guaranteed to be a connector but can be another bridge. We managed not to 
> have
> to deal with that in a generic way so far in mainline, but we'll run into 
> the
> problem one of these days, and a solution will be needed. There's no rush
> right now, and this is unrelated to converting tda998x to DRM bridge.
>
>> We would still need the component helper to manage the binding of
>> the connector part, which would also then have to register a DRM
>> bridge in addition to a DRM encoder and providing the DRM connector
>> as we can't have two device drivers bound to the same i2c device.
>> What we get is more complexity in the driver.
>
> DRM bridges indeed don't create encoders. That task is left to the display
> driver. The reason is the same as above: bridges can be chained (including
> with an internal encoder that is not modelled as a bridge, and that's a 
> case
> we have today), while the KMS model exposes a single encoder to userspace.
> Exposing DRM encoder objects as part of the KMS UABI was probably a 
> mistake.
> Better solutions would have been to expose no encoder at all or all 
> encoders
> in the chain. We are however stuck with this model as we can't break the 
> UABI.
> For that reason a DRM encoder object doesn't represent an encoder but a 
> chain
> of encoders. As a DRM bridge models a single encoder, the DRM encoder 
> object
> must be created at a higher level, in the display driver.

 One more thing is that the TDA998x in its current form won't work
 with KMS drivers that create their own drm_encoder objects to represent
 t

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call



On 10/21/2016 11:39 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>> 3) Rough conversion to bridge:
>
> So I thought I might give this a try, and see what's needed to complete
> the patch, but...
>
> I thought we'd got past the dark ages of email clients screwing up
> patches, but it seems not.  This patch is totally screwed that it's
> not worth even sending - it has been:
>
> - wrapped
> - white-space damaged
>
> which makes it pretty hard to undo all the damage.  Please use a
> better mail client which doesn't screw up patches, or send it as a
> plain text attachment.  Thanks.

Sorry about that. I'll post out a proper patch for this once we resolve
the drm_bridge shortcomings you've mentioned. I can create one if you
want to try it now.

Thanks,
Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

On Sat, Oct 22, 2016 at 05:46:30PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> On Sat, Oct 22, 2016 at 04:01:14PM +0200, Daniel Vetter wrote:
> > On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> > > > This function provides a way for the driver to redo a
> > > > modeset on the current mode and retry the link training
> > > > at a lower link rate/lane count/bpp. This will get called
> > > > incase the link training fails during the current modeset.
> > > > 
> > > > Cc: dri-devel at lists.freedesktop.org
> > > > Cc: Jani Nikula 
> > > > Cc: Daniel Vetter 
> > > > Cc: Ville Syrjala 
> > > > Signed-off-by: Manasi Navare 
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > > > +
> > > >  include/drm/drm_atomic_helper.h |  1 +
> > > >  2 files changed, 59 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index f936276..0c1614e 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > > > drm_connector *connector,
> > > >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> > > >  
> > > >  /**
> > > > + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> > > > + * @connector: DRM connector
> > > > + *
> > > > + * Provides a way to redo a modeset with the current mode so that it 
> > > > can
> > > > + * drop the bpp, link rate/lane count and retry the link training.
> > > > + *
> > > > + * Returns:
> > > > + * Returns 0 on success, negative errno numbers on failure.
> > > > + */
> > > > +int
> > > > +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> > > > +{
> > > > +   struct drm_device *dev = connector->dev;
> > > > +   struct drm_modeset_acquire_ctx ctx;
> > > > +   struct drm_atomic_state *state;
> > > > +   struct drm_connector_state *connector_state;
> > > > +   struct drm_crtc_state *crtc_state;
> > > > +   int ret = 0;
> > > > +
> > > > +   drm_modeset_acquire_init(&ctx, 0);
> > > > +   state = drm_atomic_state_alloc(dev);
> > > > +   if (!state) {
> > > > +   ret = -ENOMEM;
> > > > +   goto fail;
> > > > +   }
> > > > +   state->acquire_ctx = &ctx;
> > > > +retry:
> > > > +   ret = 0;
> > > > +   connector_state = drm_atomic_get_connector_state(state, 
> > > > connector);
> > > > +   if (IS_ERR(connector_state)) {
> > > > +   ret = PTR_ERR(connector_state);
> > > > +   goto fail;
> > > > +   }
> > > > +   if (!connector_state->crtc)
> > > > +   goto fail;
> > > > +
> > > > +   crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > +   
> > > > connector_state->crtc);
> > > > +   crtc_state->connectors_changed = true;
> > > 
> > > This line here only works if the driver uses the helpers for checking and
> > > commit, and when it doesn't overwrite connectors_changed. I think the
> > > kerneldoc should mention this.
> > > 
> > > The other issue: You cannot call this from modeset code itself because of
> > > recursion. I think this also must be mentioned.
> > 
> > And if this indeed does a modeset then we have again the same issue as
> > with upfront link training when the pipe is supposed to be on: Userspace
> > can observe the kernel playing tricks because the vblank support will be
> > temporarily disabled.
> > 
> > Not sure how to best fix this, but might be good to grab the crtc->mutex
> > in the vblank code for stuff like this.
> 
> We're going to have the same problem with async modeset as well.

Async modeset is ok because userspace expects that the pipe will go
off/on, and the kernel will send out an event to signal when the pipe is
guaranteed to be on and can be started to be used. It's random modesets
afterwards I'm concerned about.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range.

A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

Signed-off-by: Dave Airlie 
---
 arch/x86/include/asm/io.h |  6 ++
 arch/x86/mm/pat.c | 13 +
 include/linux/io.h| 13 +
 3 files changed, 32 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad..6e18f66 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -351,4 +351,10 @@ extern void arch_phys_wc_del(int handle);
 #define arch_phys_wc_add arch_phys_wc_add
 #endif

+#ifdef CONFIG_PAT
+extern int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t 
size);
+extern void arch_io_free_memtype_wc(resource_size_t start, resource_size_t 
size);
+#define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
+#endif
+
 #endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 170cc4f..49d1b75 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -730,6 +730,19 @@ void io_free_memtype(resource_size_t start, 
resource_size_t end)
free_memtype(start, end);
 }

+int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
+   return io_reserve_memtype(start, start + size, &type);
+}
+EXPORT_SYMBOL(arch_io_reserve_memtype_wc);
+
+void arch_io_free_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   io_free_memtype(start, start + size);
+}
+EXPORT_SYMBOL(arch_io_free_memtype_wc);
+
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
 {
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419..963ab71 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -141,4 +141,17 @@ enum {
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
 void memunmap(void *addr);

+#ifndef arch_io_reserve_memtype_wc
+static inline int arch_io_reserve_memtype_wc(resource_size_t base,
+resource_size_t size)
+{
+   return 0;
+}
+
+static inline void arch_io_free_memtype_wc(resource_size_t base,
+  resource_size_t size)
+{
+}
+#endif
+
 #endif /* _LINUX_IO_H */
-- 
2.5.5

[PATCH 2/2] drm/drivers: add support for using the arch wc mapping API.

This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.

Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
 drivers/gpu/drm/ast/ast_ttm.c  | 6 ++
 drivers/gpu/drm/cirrus/cirrus_ttm.c| 7 +++
 drivers/gpu/drm/mgag200/mgag200_ttm.c  | 7 +++
 drivers/gpu/drm/nouveau/nouveau_ttm.c  | 8 
 drivers/gpu/drm/radeon/radeon_object.c | 5 +
 6 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index aa074fa..f3efb1c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -754,6 +754,10 @@ static const char *amdgpu_vram_names[] = {

 int amdgpu_bo_init(struct amdgpu_device *adev)
 {
+   /* reserve PAT memory space to WC for VRAM */
+   arch_io_reserve_memtype_wc(adev->mc.aper_base,
+  adev->mc.aper_size);
+
/* Add an MTRR for the VRAM */
adev->mc.vram_mtrr = arch_phys_wc_add(adev->mc.aper_base,
  adev->mc.aper_size);
@@ -769,6 +773,7 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
 {
amdgpu_ttm_fini(adev);
arch_phys_wc_del(adev->mc.vram_mtrr);
+   arch_io_free_memtype_wc(adev->mc.aper_base, adev->mc.aper_size);
 }

 int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 608df4c..0743e65 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -267,6 +267,8 @@ int ast_mm_init(struct ast_private *ast)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));

@@ -275,11 +277,15 @@ int ast_mm_init(struct ast_private *ast)

 void ast_mm_fini(struct ast_private *ast)
 {
+   struct drm_device *dev = ast->dev;
+
ttm_bo_device_release(&ast->ttm.bdev);

ast_ttm_global_release(ast);

arch_phys_wc_del(ast->fb_mtrr);
+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
 }

 void ast_ttm_placement(struct ast_bo *bo, int domain)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bb2438d..5e7e63c 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -267,6 +267,9 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
+
cirrus->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
   pci_resource_len(dev->pdev, 0));

@@ -276,6 +279,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)

 void cirrus_mm_fini(struct cirrus_device *cirrus)
 {
+   struct drm_device *dev = cirrus->dev;
+
if (!cirrus->mm_inited)
return;

@@ -285,6 +290,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus)

arch_phys_wc_del(cirrus->fb_mtrr);
cirrus->fb_mtrr = 0;
+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
 }

 void cirrus_ttm_placement(struct cirrus_bo *bo, int domain)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 919b35f..dcf7d11 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -266,6 +266,9 @@ int mgag200_mm_init(struct mga_device *mdev)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
+
mdev->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
 pci_resource_len(dev->pdev, 0));

@@ -274,10 +277,14 @@ int mgag200_mm_init(struct mga_device *mdev)

 void mgag200_mm_fini(struct mga_device *mdev)
 {
+   struct drm_device *dev = mdev->dev;
+
ttm_bo_device_release(&mdev->ttm.bdev);

mgag200_ttm_global_release(mdev);

+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
arch_phys_wc_del(mdev->fb_mtrr);
mdev->fb_mtrr = 0;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1825dbc..a6dbe82 10

x86 PAT memtype regression fix (resend)

On 24 October 2016 at 16:03, Dave Airlie  wrote:
> I messed up one of the mailing lists last time (copied ancient
> address from another script).
>

Oops ignore both of those sets, forgot a git add, will repost once it
finish rebuild/boot cycle.

Dave.

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call



On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
>> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
>>  (sorry, I lost your original mail)
>> DRM bridges indeed don't create encoders. That task is left to the 
>> display
>> driver. The reason is the same as above: bridges can be chained 
>> (including
>> with an internal encoder that is not modelled as a bridge, and that's a 
>> case
>> we have today), while the KMS model exposes a single encoder to 
>> userspace.
>> Exposing DRM encoder objects as part of the KMS UABI was probably a 
>> mistake.
>> Better solutions would have been to expose no encoder at all or all 
>> encoders
>> in the chain. We are however stuck with this model as we can't break the 
>> UABI.
>> For that reason a DRM encoder object doesn't represent an encoder but a 
>> chain
>> of encoders. As a DRM bridge models a single encoder, the DRM encoder 
>> object
>> must be created at a higher level, in the display driver.
>>
>> I wonder why you created 'bridge's instead of simply adding links to
>> the encoders? (that's what ASoC did: the audio CODECs are linked)
>> This way, in simple cases (most cases), there would have been
>>  crtc -> (encoder -> connector)
>> instead of
>>  crtc -> (bridge + encoder) -> (bridge + connector)
>> without any changes in the actual (encoder + connector)s.
>
> Looking at drm_bridge_disable() and drm_bridge_enable(), the control
> model appears to be:
>
>   crtc -> encoder -> connector
>  `-> bridge
>`-> bridge
>`-> bridge
>
> Bridges are always attached to an encoder, and there can be multiple
> bridges attached to one encoder.  Bridges can't be attached to the
> connector.
>
> So, in the case of TDA998x, we end up with the TDA998x providing a
> connector, because it has connector functionality, and providing a
> bridge.  The encoder is left to the KMS driver, which adds additional
> complexity (100+ lines) to each and every KMS driver, requiring the
> KMS driver to have much more knowledge of what's attached to the
> "CRTC", so it can create these encoders itself.  I still think this
> is a backwards step - maybe one step forwards, two backwards.

The majority of KMS drivers do end up creating their own encoders (i.e,
encoders are exclusive to the HW represented by the KMS driver, not an
external chip/IP that can be used by other KMS drivers).

The additional complexity is more for KMS drivers like armada-drm,
where the encoder HW isn't provided by the main display HW altogether.

 From the initial commits that added drm_bridge, it was mainly created
to piggy-back onto an existing drm_encoder. Later, some infrastructure
was added to create independent bridge drivers that could attach to
a KMS driver. What was completely missed out when implementing 
drm_bridge was the case where the KMS driver doesn't have a drm_encoder
at all. I feel it should be fixable with additional helpers, though.
If not, I think we still aren't too late to come up with some other
way of representing encoder chains, since there still aren't too many
bridge drivers and no presence of it in user space.

>
> Even if we were to provide helpers to create a dummy encoder to
> work around the DRM bridge model short-comings, much of the 100+
> lines is to do with working out whether or not we need to create an
> encoder, and parsing the information we need to create that in a way
> that existing DT doesn't break.
>
> Then there's the fact that the bridge approach breaks non-DT at the
> moment, because DRM bridge fundamentally requires DT.  This makes
> DRM bridge useless for architectures which aren't DT aware, such as
> x86.  So, converting drivers to be a DRM bridge effectively denies
> their use on other architectures.  See drm_bridge.c, and look for
> the references to bridge_list, noting that there are two: one which
> adds to the bridge list, and one under #ifdef CONFIG_OF which looks
> up a DT reference to a bridge.

Maybe for the non-DT case, we could add a field in drm_bridge that is
populated by dev->platform_data which tells the KMS driver which
encoder it needs to bind to.

Could you point me to what the dev->platform_data retrieved by
armada_drm_probe from a board file looks like? I couldn't find
anything when I grep-ed "armada-drm"/"armada-510-drm"

I do agree that it's a step backward that we now have to search for
a corresponding bridge, which we didn't have to do when the chip
was represented as an encoder.

>
> There's another issue with TDA998x - we now have audio support in
> TDA998x, and converting TDA998x to be a DRM bridge introduces some
> fundamental (and as yet unsolved) races between the ASoC code and
> the attachment of the DRM bridge to the DRM encoder, and the detachment
> when the DRM bridge/connector gets clea

x86 PAT memtype regression fixes

This is the working set, I messed up a git add on CONFIG_PAT vs
CONFIG_X86_PAT. This set of changes fixes a regression since
the change to the pfn_insert_mixed code to use the memtype tracking
code.

All the GPU drivers using TTM need to insert the VRAM mapping
into the memtype table so don't get UC mappings for lots of things.

Dave.

x86 PAT memtype regression fixes (with extra cc's)

As per Ingo's request I've cc'ed a bunch more x86/PAT people.

Dave.

[PATCH 2/2] drm/drivers: add support for using the arch wc mapping API.

This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.

Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
 drivers/gpu/drm/ast/ast_ttm.c  | 6 ++
 drivers/gpu/drm/cirrus/cirrus_ttm.c| 7 +++
 drivers/gpu/drm/mgag200/mgag200_ttm.c  | 7 +++
 drivers/gpu/drm/nouveau/nouveau_ttm.c  | 8 
 drivers/gpu/drm/radeon/radeon_object.c | 5 +
 6 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index aa074fa..f3efb1c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -754,6 +754,10 @@ static const char *amdgpu_vram_names[] = {

 int amdgpu_bo_init(struct amdgpu_device *adev)
 {
+   /* reserve PAT memory space to WC for VRAM */
+   arch_io_reserve_memtype_wc(adev->mc.aper_base,
+  adev->mc.aper_size);
+
/* Add an MTRR for the VRAM */
adev->mc.vram_mtrr = arch_phys_wc_add(adev->mc.aper_base,
  adev->mc.aper_size);
@@ -769,6 +773,7 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
 {
amdgpu_ttm_fini(adev);
arch_phys_wc_del(adev->mc.vram_mtrr);
+   arch_io_free_memtype_wc(adev->mc.aper_base, adev->mc.aper_size);
 }

 int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 608df4c..0743e65 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -267,6 +267,8 @@ int ast_mm_init(struct ast_private *ast)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
pci_resource_len(dev->pdev, 0));

@@ -275,11 +277,15 @@ int ast_mm_init(struct ast_private *ast)

 void ast_mm_fini(struct ast_private *ast)
 {
+   struct drm_device *dev = ast->dev;
+
ttm_bo_device_release(&ast->ttm.bdev);

ast_ttm_global_release(ast);

arch_phys_wc_del(ast->fb_mtrr);
+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
 }

 void ast_ttm_placement(struct ast_bo *bo, int domain)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bb2438d..5e7e63c 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -267,6 +267,9 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
+
cirrus->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
   pci_resource_len(dev->pdev, 0));

@@ -276,6 +279,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)

 void cirrus_mm_fini(struct cirrus_device *cirrus)
 {
+   struct drm_device *dev = cirrus->dev;
+
if (!cirrus->mm_inited)
return;

@@ -285,6 +290,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus)

arch_phys_wc_del(cirrus->fb_mtrr);
cirrus->fb_mtrr = 0;
+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
 }

 void cirrus_ttm_placement(struct cirrus_bo *bo, int domain)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 919b35f..dcf7d11 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -266,6 +266,9 @@ int mgag200_mm_init(struct mga_device *mdev)
return ret;
}

+   arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
+  pci_resource_len(dev->pdev, 0));
+
mdev->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
 pci_resource_len(dev->pdev, 0));

@@ -274,10 +277,14 @@ int mgag200_mm_init(struct mga_device *mdev)

 void mgag200_mm_fini(struct mga_device *mdev)
 {
+   struct drm_device *dev = mdev->dev;
+
ttm_bo_device_release(&mdev->ttm.bdev);

mgag200_ttm_global_release(mdev);

+   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
+   pci_resource_len(dev->pdev, 0));
arch_phys_wc_del(mdev->fb_mtrr);
mdev->fb_mtrr = 0;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1825dbc..a6dbe82 10

[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

On Sun, Oct 23, 2016 at 11:12:31PM -0700, Manasi Navare wrote:
> On Mon, Oct 24, 2016 at 08:00:10AM +0200, Daniel Vetter wrote:
> > On Sat, Oct 22, 2016 at 05:46:30PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > > On Sat, Oct 22, 2016 at 04:01:14PM +0200, Daniel Vetter wrote:
> > > > On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> > > > > On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> > > > > > This function provides a way for the driver to redo a
> > > > > > modeset on the current mode and retry the link training
> > > > > > at a lower link rate/lane count/bpp. This will get called
> > > > > > incase the link training fails during the current modeset.
> > > > > > 
> > > > > > Cc: dri-devel at lists.freedesktop.org
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Daniel Vetter 
> > > > > > Cc: Ville Syrjala 
> > > > > > Signed-off-by: Manasi Navare 
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > > > > > +
> > > > > >  include/drm/drm_atomic_helper.h |  1 +
> > > > > >  2 files changed, 59 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > index f936276..0c1614e 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > > > > > drm_connector *connector,
> > > > > >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> > > > > >  
> > > > > >  /**
> > > > > > + * drm_atomic_helper_connector_modeset - Force a modeset on a 
> > > > > > connector
> > > > > > + * @connector: DRM connector
> > > > > > + *
> > > > > > + * Provides a way to redo a modeset with the current mode so that 
> > > > > > it can
> > > > > > + * drop the bpp, link rate/lane count and retry the link training.
> > > > > > + *
> > > > > > + * Returns:
> > > > > > + * Returns 0 on success, negative errno numbers on failure.
> > > > > > + */
> > > > > > +int
> > > > > > +drm_atomic_helper_connector_modeset(struct drm_connector 
> > > > > > *connector)
> > > > > > +{
> > > > > > +   struct drm_device *dev = connector->dev;
> > > > > > +   struct drm_modeset_acquire_ctx ctx;
> > > > > > +   struct drm_atomic_state *state;
> > > > > > +   struct drm_connector_state *connector_state;
> > > > > > +   struct drm_crtc_state *crtc_state;
> > > > > > +   int ret = 0;
> > > > > > +
> > > > > > +   drm_modeset_acquire_init(&ctx, 0);
> > > > > > +   state = drm_atomic_state_alloc(dev);
> > > > > > +   if (!state) {
> > > > > > +   ret = -ENOMEM;
> > > > > > +   goto fail;
> > > > > > +   }
> > > > > > +   state->acquire_ctx = &ctx;
> > > > > > +retry:
> > > > > > +   ret = 0;
> > > > > > +   connector_state = drm_atomic_get_connector_state(state, 
> > > > > > connector);
> > > > > > +   if (IS_ERR(connector_state)) {
> > > > > > +   ret = PTR_ERR(connector_state);
> > > > > > +   goto fail;
> > > > > > +   }
> > > > > > +   if (!connector_state->crtc)
> > > > > > +   goto fail;
> > > > > > +
> > > > > > +   crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > +   
> > > > > > connector_state->crtc);
> > > > > > +   crtc_state->connectors_changed = true;
> > > > > 
> > > > > This line here only works if the driver uses the helpers for checking 
> > > > > and
> > > > > commit, and when it doesn't overwrite connectors_changed. I think the
> > > > > kerneldoc should mention this.
> > > > > 
> > > > > The other issue: You cannot call this from modeset code itself 
> > > > > because of
> > > > > recursion. I think this also must be mentioned.
> 
> I will add this to the kernel doc.
> In our case, we call this in a work func that will get scheduled after
> the current modeset is completed.
> 
> > > > 
> > > > And if this indeed does a modeset then we have again the same issue as
> > > > with upfront link training when the pipe is supposed to be on: Userspace
> > > > can observe the kernel playing tricks because the vblank support will be
> > > > temporarily disabled.
> > > > 
> > > > Not sure how to best fix this, but might be good to grab the crtc->mutex
> > > > in the vblank code for stuff like this.
> > > 
> > > We're going to have the same problem with async modeset as well.
> > 
> > Async modeset is ok because userspace expects that the pipe will go
> > off/on, and the kernel will send out an event to signal when the pipe is
> > guaranteed to be on and can be started to be used. It's random modesets
> > afterwards I'm concerned about.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> These wont be random modesets, this will occur only in case of link training
> failure in which case if the mode has not changed/pruned, it will attempt
> modeset at lower link rate.

"Cat ate the cabl

x86 PAT memtype regression fix (resend)

I messed up one of the mailing lists last time (copied ancient
address from another script).

Dave.

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT
Cc: Toshi Kani 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Andy Lutomirski 
Cc: Denys Vlasenko 
Cc: Brian Gerst 
Cc: x86 at kernel.org
Cc: mcgrof at suse.com
Cc: Dan Williams 
Signed-off-by: Dave Airlie 
---
 arch/x86/include/asm/io.h |  6 ++
 arch/x86/mm/pat.c | 13 +
 include/linux/io.h| 13 +
 3 files changed, 32 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad..d34bd37 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -351,4 +351,10 @@ extern void arch_phys_wc_del(int handle);
 #define arch_phys_wc_add arch_phys_wc_add
 #endif

+#ifdef CONFIG_X86_PAT
+extern int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t 
size);
+extern void arch_io_free_memtype_wc(resource_size_t start, resource_size_t 
size);
+#define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
+#endif
+
 #endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 170cc4f..49d1b75 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -730,6 +730,19 @@ void io_free_memtype(resource_size_t start, 
resource_size_t end)
free_memtype(start, end);
 }

+int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
+   return io_reserve_memtype(start, start + size, &type);
+}
+EXPORT_SYMBOL(arch_io_reserve_memtype_wc);
+
+void arch_io_free_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   io_free_memtype(start, start + size);
+}
+EXPORT_SYMBOL(arch_io_free_memtype_wc);
+
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
 {
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419..963ab71 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -141,4 +141,17 @@ enum {
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
 void memunmap(void *addr);

+#ifndef arch_io_reserve_memtype_wc
+static inline int arch_io_reserve_memtype_wc(resource_size_t base,
+resource_size_t size)
+{
+   return 0;
+}
+
+static inline void arch_io_free_memtype_wc(resource_size_t base,
+  resource_size_t size)
+{
+}
+#endif
+
 #endif /* _LINUX_IO_H */
-- 
2.5.5

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT
Signed-off-by: Dave Airlie 
---
 arch/x86/include/asm/io.h |  6 ++
 arch/x86/mm/pat.c | 13 +
 include/linux/io.h| 13 +
 3 files changed, 32 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad..d34bd37 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -351,4 +351,10 @@ extern void arch_phys_wc_del(int handle);
 #define arch_phys_wc_add arch_phys_wc_add
 #endif

+#ifdef CONFIG_X86_PAT
+extern int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t 
size);
+extern void arch_io_free_memtype_wc(resource_size_t start, resource_size_t 
size);
+#define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
+#endif
+
 #endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 170cc4f..49d1b75 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -730,6 +730,19 @@ void io_free_memtype(resource_size_t start, 
resource_size_t end)
free_memtype(start, end);
 }

+int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
+   return io_reserve_memtype(start, start + size, &type);
+}
+EXPORT_SYMBOL(arch_io_reserve_memtype_wc);
+
+void arch_io_free_memtype_wc(resource_size_t start, resource_size_t size)
+{
+   io_free_memtype(start, start + size);
+}
+EXPORT_SYMBOL(arch_io_free_memtype_wc);
+
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
 {
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419..963ab71 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -141,4 +141,17 @@ enum {
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
 void memunmap(void *addr);

+#ifndef arch_io_reserve_memtype_wc
+static inline int arch_io_reserve_memtype_wc(resource_size_t base,
+resource_size_t size)
+{
+   return 0;
+}
+
+static inline void arch_io_free_memtype_wc(resource_size_t base,
+  resource_size_t size)
+{
+}
+#endif
+
 #endif /* _LINUX_IO_H */
-- 
2.5.5

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

On Mon, Oct 24, 2016 at 11:58:00AM +0530, Archit Taneja wrote:
> On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
> > > > > > > On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> > >   (sorry, I lost your original mail)
> > > > > > > DRM bridges indeed don't create encoders. That task is left to 
> > > > > > > the display
> > > > > > > driver. The reason is the same as above: bridges can be chained 
> > > > > > > (including
> > > > > > > with an internal encoder that is not modelled as a bridge, and 
> > > > > > > that's a case
> > > > > > > we have today), while the KMS model exposes a single encoder to 
> > > > > > > userspace.
> > > > > > > Exposing DRM encoder objects as part of the KMS UABI was probably 
> > > > > > > a mistake.
> > > > > > > Better solutions would have been to expose no encoder at all or 
> > > > > > > all encoders
> > > > > > > in the chain. We are however stuck with this model as we can't 
> > > > > > > break the UABI.
> > > > > > > For that reason a DRM encoder object doesn't represent an encoder 
> > > > > > > but a chain
> > > > > > > of encoders. As a DRM bridge models a single encoder, the DRM 
> > > > > > > encoder object
> > > > > > > must be created at a higher level, in the display driver.
> > > 
> > > I wonder why you created 'bridge's instead of simply adding links to
> > > the encoders? (that's what ASoC did: the audio CODECs are linked)
> > > This way, in simple cases (most cases), there would have been
> > >   crtc -> (encoder -> connector)
> > > instead of
> > >   crtc -> (bridge + encoder) -> (bridge + connector)
> > > without any changes in the actual (encoder + connector)s.
> > 
> > Looking at drm_bridge_disable() and drm_bridge_enable(), the control
> > model appears to be:
> > 
> > crtc -> encoder -> connector
> >  `-> bridge
> >  `-> bridge
> >  `-> bridge
> > 
> > Bridges are always attached to an encoder, and there can be multiple
> > bridges attached to one encoder.  Bridges can't be attached to the
> > connector.

In helpers connectors are no-op objects. We _never_ call any connector
callbacks when doing a modeset. Connectors are only used to probe output
state, and as the userspace-visisble endpoint representation. Hence the
real graph is

crtc -> encoder [ -> bridge [ -> bridge [...]]] -> connector

with the last bridge owning the connector. And that last bridge probably
needs to store a pointer to its connector(s).

> > So, in the case of TDA998x, we end up with the TDA998x providing a
> > connector, because it has connector functionality, and providing a
> > bridge.  The encoder is left to the KMS driver, which adds additional
> > complexity (100+ lines) to each and every KMS driver, requiring the
> > KMS driver to have much more knowledge of what's attached to the
> > "CRTC", so it can create these encoders itself.  I still think this
> > is a backwards step - maybe one step forwards, two backwards.

We've stubbed out everything that's in an encoder, you definitely don't
need hundreds of lines to write one any more. If there's still a callback
left around drm_encoder which has not yet suitable default handling, then
that's a bug.

Note: Only applies to atomic though, I'm not going to bother with old
legacy crtc helpers. I guess armada needs to switch to atomic, otherwise
encoders are indeed a bit a pain.

> The majority of KMS drivers do end up creating their own encoders (i.e,
> encoders are exclusive to the HW represented by the KMS driver, not an
> external chip/IP that can be used by other KMS drivers).
> 
> The additional complexity is more for KMS drivers like armada-drm,
> where the encoder HW isn't provided by the main display HW altogether.
> 
> From the initial commits that added drm_bridge, it was mainly created
> to piggy-back onto an existing drm_encoder. Later, some infrastructure
> was added to create independent bridge drivers that could attach to
> a KMS driver. What was completely missed out when implementing drm_bridge
> was the case where the KMS driver doesn't have a drm_encoder
> at all. I feel it should be fixable with additional helpers, though.
> If not, I think we still aren't too late to come up with some other
> way of representing encoder chains, since there still aren't too many
> bridge drivers and no presence of it in user space.

Imo encoders should be that part which is baked into your core ip. If
there's nothing, then you're perfectly fine with a no-op encoder. Maybe we
could do a helper for creating those, if the few lines are copypasted too
often. Then all the external IP should be bridges (and chained). And with
chains either you need another bridge, or you're the last bridge, and then
you're supposed to register the connector as the final endpoint.

> > Even if we were to provide helpers to create a dummy encoder to
> > work around the DRM bridge model short-comin

[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

On Mon, Oct 24, 2016 at 9:00 AM, Manasi Navare
 wrote:
>> I guess we just need to do some additional work on top to make sure the
>> vblank ioctl can't see invalid state. Which would then again make upfront
>> link trainig possible ...
>
> Could you share some more details on what work would need to be done
> for vblank? Then I can investigate it a little bit more tomor during the day.

So the trouble is that drm_irq.c is still from the old pre-kms days.
Which means it deals in int pipe instead of struct drm_crtc *, among
other things. But we can't simply switch over because some old drivers
(pre-kms ones) still depend upon that old code. Hence we need:

1. Duplicate most of the code in drm_irq.c into a new
drm_crtc_vblank.c, which is only used for kms drivers. And in the
ioctl code have a DRIVER_MODESET check and either call the new kms
version (in drm_crtc_vblank.c) or the old one (still in drm_irq.c).

2. Convert the int pipe into a drm_crtc pointer in the new kms code.
For prettiness we could (try) to do that as much as possible.

3. Grab the drm_crtc->mutex in the ioctl code to block these races.

-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PULL] topic/drm-misc

Hi Dave,

First -misc pull for 4.10:
- drm_format rework from Laurent
- reservation patches from Chris that missed 4.9. 
- aspect ratio support in infoframe helpers and drm mode/edid code
  (Shashank Sharma)
- rotation rework from Ville (first parts at least)
- another attempt at the CRC debugfs interface from Tomeu
- piles and piles of misc patches all over

I'll send you another drm-intel pull too, and I'd like to backmerge the
lot right afterwards. And if you base drm-next on -rc2 I get that for
free, too (which would be great to make sure git doesn't again screw
things up when the cherry-pick conflicts get out of hand).

Also I've been hacking on my scripts, and assuming nothing goes sideways
the next pull request for -misc will be from the new, separate repo.

Cheers, Daniel


The following changes since commit a5bd451b6e6ece69be07a425381c4f3438eadba0:

  drm/crtc: constify drm_crtc_index parameter (2016-10-10 17:28:58 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-10-24

for you to fetch changes up to 8a5bbf327aa16025c78491266a6425807c7fbee0:

  drm: Use u64 for intermediate dotclock calculations (2016-10-21 20:23:16 
+0200)


Arnd Bergmann (2):
  drm: avoid uninitialized timestamp use in wait_vblank
  i915: don't call drm_atomic_state_put on invalid pointer

Brian Starkey (1):
  drm: atomic: Clarify documentation around drm_atomic_crtc_needs_modeset

Chris Wilson (13):
  drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before 
wait
  drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu 
before wait
  drm/nouveau: Remove call to reservation_object_test_signaled_rcu before 
wait
  drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before 
wait
  dma-buf: Introduce fence_get_rcu_safe()
  dma-buf: Restart reservation_object_get_fences_rcu() after writes
  dma-buf: Restart reservation_object_wait_timeout_rcu() after writes
  dma-buf: Restart reservation_object_test_signaled_rcu() after writes
  drm: Add reference counting to drm_atomic_state
  drm/edid: Rename local variable block to edid
  drm/edid: Use block local to refer to the block
  drm/i915: Handle early failure during intel_get_load_detect_pipe
  drm: Use u64 for intermediate dotclock calculations

Dan Carpenter (1):
  drm/savage: dereferencing an error pointer

Dmitry Vyukov (1):
  drivers/gpu/vga: allocate vga_arb_write() buffer on stack

Gustavo Padovan (2):
  drm/fence: release fence reference when canceling event
  dma-buf/sync_file: hold reference to fence when creating sync_file

Jani Nikula (1):
  drm: fix sparse warnings on undeclared symbols in crc debugfs

Jiang Biao (2):
  drm/gma500: remove useless comment
  drm/gma500: add comments for new parameters

Laurent Pinchart (13):
  drm: Centralize format information
  drm: Implement the drm_format_*() helpers as drm_format_info() wrappers
  drm: Use drm_format_info() in DRM core code
  drm: WARN when calling drm_format_info() for an unsupported format
  drm: hdlcd: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
  drm: tilcdc: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
  drm: cirrus: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
  drm: gma500: Replace drm_fb_get_bpp_depth() with drm_format_info()
  drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
  drm: radeon: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()
  drm: vmwgfx: Replace drm_fb_get_bpp_depth() with drm_format_info()
  drm/arm: mali-dp: Replace drm_fb_get_bpp_depth() with 
drm_format_plane_cpp()
  drm: Don't export the drm_fb_get_bpp_depth() function

Maarten Lankhorst (1):
  drm/crtc: constify drm_crtc_mask parameter

Peter Griffin (1):
  drm/virtio: kconfig: Fixup white space.

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

Shyam Saini (1):
  gpu: drm: gma500: Use vma_pages()

Stefan Agner (2):
  drm/fb-helper: reject any changes to the fbdev
  drm/fb_cma_helper: do not free fbdev if there is none

Stephen Boyd (1):
  gpu: Remove depends on RESET_CONTROLLER when not a provider

Tomeu Vizoso (1):
  drm: Add API for capturing frame CRCs

Ville SyrjÃ¤lÃ¤ (8):
  drm: Add drm_rotation_90_or_270()
  drm/atomic: Reject attempts to use multiple rotation angles at once
  drm: Add support for optional per-plane rotation property
  drm/arm: Use per-plane rotation property
  drm/atmel-hlcdc: Use per-plane rotation property
  drm/omap: Set rotation property initial value to BIT(DRM_ROTATE_0) insted 
of 0
  drm/omap: Use per-pl

[PULL] drm-intel-next

Hi Dave,

drm-intel-next-2016-10-24:
- first slice of the gvt device model (Zhenyu et al)
- compression support for gpu error states (Chris)
- sunset clause on gpu errors resulting in dmesg noise telling users
  how to report them
- .rodata diet from Tvrtko
- switch over lots of macros to only take dev_priv (Tvrtko)
- underrun suppression for dp link training (Ville)
- lspcon (hmdi 2.0 on skl/bxt) support from Shashank Sharma, polish
  from Jani
- gen9 wm fixes from Paulo&Lyude
- updated ddi programming for kbl (Rodrigo)
- respect alternate aux/ddc pins (from vbt) for all ddi ports (Ville)
drm-intel-next-2016-10-10:
- dsi/backlight fixes (Jani&Shawn)
- a few reset improvements (Ben, Chris, Imre)
- refactor port tracking for audio support (Dhinakaran)
- a pile of gen9 wm fixes from Paulo
- drop skl pre-production w/a (Jani)
- refactor forcewake and shadow reg filters into tables, and unify the
  funcs/macros using them across platforms (Tvrtko)
- fix DP detection to not require an edid (Ville)
- register shadow VGA port (for testing), from Ville

NOTE: There's a big conflict between this tree an the rotation stuff from
Ville in drm-misc. One conflict git spots and it's easy to resolve, the
other results in compile fail and needs some s/dev/dev_priv/ in a few
places to fix up. linux-next just reported&fixed them up, but I've been
soaking the resolutions in drm-intel-nightly a bit too.

And as mentioned I'd like to backmerge drm-misc+rc2 to unblock merging a
few patches.

And the other bit I've totally forgotten: As soon as you have all the
merges I'll pull in the s/fence/dma_fence/ patch from Chris into drm-misc.

Cheers, Daniel


The following changes since commit 69405d3da98b48633b78a49403e4f9cdb7c6a0f5:

  Merge tag 'topic/drm-misc-2016-10-11' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-10-12 06:07:38 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-10-24

for you to fetch changes up to 9558e74c26d2d63b9395f4d4153faa05f9de84f8:

  drm/i915: Update DRIVER_DATE to 20161024 (2016-10-24 08:25:36 +0200)


- first slice of the gvt device model (Zhenyu et al)
- compression support for gpu error states (Chris)
- sunset clause on gpu errors resulting in dmesg noise telling users
  how to report them
- .rodata diet from Tvrtko
- switch over lots of macros to only take dev_priv (Tvrtko)
- underrun suppression for dp link training (Ville)
- lspcon (hmdi 2.0 on skl/bxt) support from Shashank Sharma, polish
  from Jani
- gen9 wm fixes from Paulo&Lyude
- updated ddi programming for kbl (Rodrigo)
- respect alternate aux/ddc pins (from vbt) for all ddi ports (Ville)


Akash Goel (1):
  drm/i915: Allocate intel_engine_cs structure only for the enabled engines

Anusha Srivatsa (1):
  drm/i915/guc: Sanitory checks for platform that dont have GuC

Arkadiusz Hiler (1):
  drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

Ben Widawsky (2):
  drm/i915: Cleanup instdone collection
  drm/i915: Try to print INSTDONE bits for all slice/subslice

Chris Wilson (54):
  drm/i915: Restore current RPS state after reset
  drm/i915: Only shrink the unbound objects during freeze
  drm/i915/execlists: Reset RING registers upon resume
  drm/i915: Just clear the mmiodebug before a register access
  drm/i915: Unalias obj->phys_handle and obj->userptr
  drm/i915: Use correct index for backtracking HUNG semaphores
  drm/i915: Share the computation of ring size for RING_CTL register
  drm/i915/execlists: Reinitialise context image after GPU hang
  drm/i915/execlists: Move clearing submission count from reset to init
  drm/i915: Disable irqs across GPU reset
  drm/i915: Double check hangcheck.seqno after reset
  drm/i915: Show bounds of active request in the ring on GPU hang
  drm/i915: Show RING registers through debugfs
  drm/i915: Show waiters in i915_hangcheck_info
  drm/i915: Distinguish last emitted request from last submitted request
  drm/i915: Force relocations via cpu if we run out of idle aperture
  drm/i915: Reset the breadcrumbs IRQ more carefully
  drm/i915/guc: Unwind GuC workqueue reservation if request construction 
fails
  drm/i915: Remove self-harming shrink_all on get_pages_gtt fail
  drm/i915: Allow compaction upto SWIOTLB max segment size
  drm/i915: Convert open-coded use of vma_pages()
  drm/i915: Move common code out of i915_gpu_error.c
  drm/i915: Allow disabling error capture
  drm/i915: Stop the machine whilst capturing the GPU crash dump
  drm/i915: Always use the GTT for error capture
  drm/i915: Consolidate error object printing
  drm/i915: Compress GPU objects in error state
  drm/i915: Use fence_write

[Bug 95017] [drm:radeon_ib_ring_tests] ERROR radeon: failed testing IB on GFX ring (-35).

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

--- Comment #18 from erhard_f at mailbox.org ---
> FWIW, the value of the radeon.agpmode parameter shouldn't matter if you 
> disable
> DRI (which BTW means no GPU hardware acceleration can be used at all).

Yep. And I was astonished to see the desktop running faster actually. ;)

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

radeon_connector_unregister NULL ptr deref

2016-10-24 Thread Borislav Petkov

Hi guys,

I'm getting a NULL ptr deref splat when hibernating my box with
4.9-rc1+. All I got so far is an ugly camera shot from the splat which
I'm typing in by hand.

Any ideas or already a fix?

The callstack looks like this:

unable to handle kernel NULL pointer dereference at 00...0890 (I think it is 
890)
IP: radeon_connector_unregister+0xc/0x40
...

? drm_connector_unregister.part
drm_connector_unregister_all
drm_modeset_unregister_all
drm_dev_unregister
drm_put_dev
radeon_pci_shutdown
pci_device_shutdown
device_shutdown
kernel_power_off
power_down
hibernate
...

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

radeon_connector_unregister NULL ptr deref

2016-10-24 Thread Michel Dänzer

On 24/10/16 04:34 PM, Borislav Petkov wrote:
> Hi guys,
> 
> I'm getting a NULL ptr deref splat when hibernating my box with
> 4.9-rc1+. All I got so far is an ugly camera shot from the splat which
> I'm typing in by hand.
> 
> Any ideas or already a fix?
> 
> The callstack looks like this:
> 
> unable to handle kernel NULL pointer dereference at 00...0890 (I think it is 
> 890)
> IP: radeon_connector_unregister+0xc/0x40
> ...
> 
> ? drm_connector_unregister.part
> drm_connector_unregister_all
> drm_modeset_unregister_all
> drm_dev_unregister
> drm_put_dev
> radeon_pci_shutdown
> pci_device_shutdown
> device_shutdown
> kernel_power_off
> power_down
> hibernate
> ...

Should be fixed in -rc2, specifically these commits:

https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9305ee6fe52035f63d70d023235b792ba22107f0


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

--- Comment #9 from Ernst SjÃ¶strand  ---
Is this fixed somewhere now also?
Related to https://bugs.freedesktop.org/show_bug.cgi?id=98200 I guess?

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

How to implement a EGL or DRM display in VA-API driver

2016-10-24 Thread Randy Li

Hello:
   I am going to implement a EGL and DRM display for Rockchip VA-API 
driver. We do have a EGL implementation in Rockchip VA-API driver, but 
it is implemented in the standard way, we did that as a X11 display.
   I didn't see the usage of struct VADriverVTableEGL in gstreamer, and 
I have no idea about where should I implement something functions like 
eglExportDRMImageMESA().
   The DRM seems more complex, the reason I want to use the DRM is that, 
GPU would not work with the 4K video rendering, so the DRM means that 
directly output the video into video controller in our platform. But 
still have no idea what kind of thing I should implement in the VA-API 
driver. It seems that the VA-API base library would open a DRM instance 
for the driver, but leaving those configure for connector, encoder, 
planes to VA-API driver?
   Could you guys give me same sample code or example of those kind of 
display in VA-API or the documents would help(I would not image there is 
a VA-API documents)

-- 
Randy Li
The third produce department

[PATCH] drm/radeon/pm: autoswitch power state when in balanced mode

2016-10-24 Thread Michel Dänzer

On 23/10/16 08:05 AM, Lucas Stach wrote:
> The current default of always using the performance power state leads
> to increased power consumption of mobile devices, which have a dedicated
> battery power state. Switch between the performance and battery power
> state automatically, dpending on the current AC power status, when the
> user asked for the balanced power state.
> 
> The user can still override this logic by asking for the performance
> or battery power state explicitly.
> 
> Signed-off-by: Lucas Stach 
> ---
> This saves about 1.2W on my Richland based laptop, whithout me having
> to remember to ask for the battery state or have userspace set up in
> a way to do this.
> ---
>  drivers/gpu/drm/radeon/radeon_pm.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 4b65425..326ad06 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -47,6 +47,7 @@ static bool radeon_pm_in_vbl(struct radeon_device *rdev);
>  static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool 
> finish);
>  static void radeon_pm_update_profile(struct radeon_device *rdev);
>  static void radeon_pm_set_clocks(struct radeon_device *rdev);
> +static void radeon_pm_compute_clocks_dpm(struct radeon_device *rdev);
>  
>  int radeon_pm_get_type_index(struct radeon_device *rdev,
>enum radeon_pm_state_type ps_type,
> @@ -79,6 +80,8 @@ void radeon_pm_acpi_event_handler(struct radeon_device 
> *rdev)
>   radeon_dpm_enable_bapm(rdev, 
> rdev->pm.dpm.ac_power);
>   }
>   mutex_unlock(&rdev->pm.mutex);
> + /* allow new DPM state to be picked */
> + radeon_pm_compute_clocks_dpm(rdev);
>   } else if (rdev->pm.pm_method == PM_METHOD_PROFILE) {
>   if (rdev->pm.profile == PM_PROFILE_AUTO) {
>   mutex_lock(&rdev->pm.mutex);
> @@ -882,7 +885,8 @@ static struct radeon_ps 
> *radeon_dpm_pick_power_state(struct radeon_device *rdev,
>   dpm_state = POWER_STATE_TYPE_INTERNAL_3DPERF;
>   /* balanced states don't exist at the moment */
>   if (dpm_state == POWER_STATE_TYPE_BALANCED)
> - dpm_state = POWER_STATE_TYPE_PERFORMANCE;
> + dpm_state = rdev->pm.dpm.ac_power ?
> + POWER_STATE_TYPE_PERFORMANCE : POWER_STATE_TYPE_BATTERY;
>  
>  restart_search:
>   /* Pick the best power state based on current conditions */
> 

I've been using this patch for a while on my Kaveri laptops and haven't
noticed any issues with it. I haven't compared the power consumption in
detail though.

Tested-by: Michel DÃ¤nzer 


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/95fe196d/attachment.sig>

[PULL] drm-intel-next

On Mon, Oct 24, 2016 at 9:25 AM, Daniel Vetter  
wrote:
> Hi Dave,
>
> drm-intel-next-2016-10-24:
> - first slice of the gvt device model (Zhenyu et al)
> - compression support for gpu error states (Chris)
> - sunset clause on gpu errors resulting in dmesg noise telling users
>   how to report them
> - .rodata diet from Tvrtko
> - switch over lots of macros to only take dev_priv (Tvrtko)
> - underrun suppression for dp link training (Ville)
> - lspcon (hmdi 2.0 on skl/bxt) support from Shashank Sharma, polish
>   from Jani
> - gen9 wm fixes from Paulo&Lyude
> - updated ddi programming for kbl (Rodrigo)
> - respect alternate aux/ddc pins (from vbt) for all ddi ports (Ville)
> drm-intel-next-2016-10-10:
> - dsi/backlight fixes (Jani&Shawn)
> - a few reset improvements (Ben, Chris, Imre)
> - refactor port tracking for audio support (Dhinakaran)
> - a pile of gen9 wm fixes from Paulo
> - drop skl pre-production w/a (Jani)
> - refactor forcewake and shadow reg filters into tables, and unify the
>   funcs/macros using them across platforms (Tvrtko)
> - fix DP detection to not require an edid (Ville)
> - register shadow VGA port (for testing), from Ville
>
> NOTE: There's a big conflict between this tree an the rotation stuff from
> Ville in drm-misc. One conflict git spots and it's easy to resolve, the
> other results in compile fail and needs some s/dev/dev_priv/ in a few
> places to fix up. linux-next just reported&fixed them up, but I've been
> soaking the resolutions in drm-intel-nightly a bit too.
>
> And as mentioned I'd like to backmerge drm-misc+rc2 to unblock merging a
> few patches.
>
> And the other bit I've totally forgotten: As soon as you have all the
> merges I'll pull in the s/fence/dma_fence/ patch from Chris into drm-misc.

One more: This pull contains the intial bits of the gvt device model
(essentially paravirt for intel gpus for kvm&xen). We've decided to
run this as a subproject with pull requests from Zhenyu to Jani& me
for now for a few reasons:
- it's a big codebase, separate team and lots (probably most) of
interactions out i915/drm (kvm/xen, qemu in userspace and all that).
Seems to make sense to run it separately
- there's also differences in CI&testing overall. I think running gvt
as an integrated part of drm-intel with the commit model would have
caused fun with accidentally pushing broken patches.
- and personally I'm also interesting in figuring out whether the
committer model also works when mixed with submaintainers, in case we
ever need that for scalability in areas.

Some hiccups, (there was an almost immediate 2nd pull with pile of
bugfixes), but we're working them out. I expect all smooth sailing by
the time the 4.10 merge windo opens.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

radeon_connector_unregister NULL ptr deref

2016-10-24 Thread Borislav Petkov

On Mon, Oct 24, 2016 at 04:46:30PM +0900, Michel DÃ¤nzer wrote:
> Should be fixed in -rc2, specifically these commits:
> 
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9305ee6fe52035f63d70d023235b792ba22107f0

Thanks but just tried rc2. Exactly the same splat :-(

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

[PATCH v2 2/2] drm/nouveau: mark symbols static where possible

2016-10-24 Thread Baoyou Xie

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous 
prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous 
prototype for 'nvbios_fan_entry' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous 
prototype for 'gt215_clk_info' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous 
prototype for 'gt215_link_train_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous 
prototype for 'gt215_link_train' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous 
prototype for 'gt215_link_train_init' [-Wmissing-prototypes]


In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nouveau_display.c   | 2 +-
 drivers/gpu/drm/nouveau/nv10_fence.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c   | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 8 
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c  | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c   | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c   | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c  | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c  | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c   | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c  | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c   | 8 
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c| 4 ++--
 17 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index afbf557..b60ee21 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -92,7 +92,7 @@ calc(int blanks, int blanke, int total, int line)
return line;
 }

-int
+static int
 nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime)
 {
diff --git a/drivers/gpu/drm/nouveau/nv10_fence.c 
b/drivers/gpu/drm/nouveau/nv10_fence.c
index 4e3de34..619f79d 100644
--- a/drivers/gpu/drm/nouveau/nv10_fence.c
+++ b/drivers/gpu/drm/nouveau/nv10_fence.c
@@ -66,7 +66,7 @@ nv10_fence_context_del(struct nouveau_channel *chan)
nouveau_fence_context_free(&fctx->base);
 }

-int
+static int
 nv10_fence_context_new(struct nouveau_channel *chan)
 {
struct nv10_fence_chan *fctx;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index 79a8f71..513ee6b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -326,7 +326,7 @@ nvkm_udevice = {
.sclass = nvkm_udevice_child_get,
 };

-int
+static int
 nvkm_udevice_new(const struct nvkm_oclass *oclass, void *data, u32 size,
 struct nvkm_object **pobject)
 {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index dd2953b..26990d4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -153,7 +153,7 @@ nv50_disp_chan_uevent = {
.fini = nv50_disp_chan_uevent_fini,
 };

-int
+static int
 nv50_disp_chan_rd32(struct nvkm_object *object, u64 addr, u32 *data)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
@@ -163,7 +163,7 @@ nv50_disp_chan_rd32(struct nvkm_object *object, u64 addr, 
u32 *data)
return 0;
 }

-int
+static int
 nv50_disp_chan_wr32(struct nvkm_object *object, u64 addr, u32 data)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
@@ -173,7 +173,7 @@ nv50_disp_chan_wr32(struct nvkm_object *object, u64 addr, 
u32 data)
return 0;
 }

-int
+static int
 nv50_disp_chan_ntfy(struct nvkm_object *object, u32 type,
struct nvkm_event **pevent)
 {
@@ -189,7 +189,7 @@ nv50_disp_chan_ntfy(struct nvkm_object *object, u32 type,
return -EINVAL;
 }

-int
+static int
 nv50_disp_chan_map(struct nvkm_object *object, u64 *addr, u32 *size)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
index 2f9cecd..6424b39 10

[PATCH v2 1/2] drm/nouveau: add missing header dependencies

2016-10-24 Thread Baoyou Xie

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous 
prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous 
prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous 
prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous 
prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes]


In fact, these functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h
drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h
drivers/gpu/drm/nouveau/dispnv04/disp.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/dispnv04/overlay.c   | 2 +-
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 1 +
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c   | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c   | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c  | 1 +
 6 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index ec444ea..a79514d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -33,7 +33,7 @@
 #include "nouveau_connector.h"
 #include "nouveau_display.h"
 #include "nvreg.h"
-
+#include "disp.h"

 struct nouveau_plane {
struct drm_plane base;
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index 34ecd4a..058ff46 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -20,6 +20,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 #include 
+#include 

 /**
  * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
index 1e13278..c8bb919 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
@@ -106,6 +106,7 @@
 #define CP_SEEK_2  0x00c800ff

 #include "ctxnv40.h"
+#include "nv50.h"

 #include 

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
index b9f1ffd..4dcd874 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
@@ -23,6 +23,7 @@
  *  Ben Skeggs
  */
 #include "priv.h"
+#include "ram.h"

 struct ramxlat {
int id;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
index 2690033..eca8a44 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
@@ -23,6 +23,7 @@
  * Roy Spliet 
  */
 #include "priv.h"
+#include "ram.h"

 struct ramxlat {
int id;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
index d2bac1d..443c031 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include "priv.h"

 static const u8 tags[] = {
DCB_GPIO_VID0, DCB_GPIO_VID1, DCB_GPIO_VID2, DCB_GPIO_VID3,
-- 
2.7.4

[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

2016-10-24 Thread Manasi Navare

On Mon, Oct 24, 2016 at 08:33:10AM +0200, Daniel Vetter wrote:
> On Sun, Oct 23, 2016 at 11:12:31PM -0700, Manasi Navare wrote:
> > On Mon, Oct 24, 2016 at 08:00:10AM +0200, Daniel Vetter wrote:
> > > On Sat, Oct 22, 2016 at 05:46:30PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > > > On Sat, Oct 22, 2016 at 04:01:14PM +0200, Daniel Vetter wrote:
> > > > > On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> > > > > > On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> > > > > > > This function provides a way for the driver to redo a
> > > > > > > modeset on the current mode and retry the link training
> > > > > > > at a lower link rate/lane count/bpp. This will get called
> > > > > > > incase the link training fails during the current modeset.
> > > > > > > 
> > > > > > > Cc: dri-devel at lists.freedesktop.org
> > > > > > > Cc: Jani Nikula 
> > > > > > > Cc: Daniel Vetter 
> > > > > > > Cc: Ville Syrjala 
> > > > > > > Signed-off-by: Manasi Navare 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > > > > > > +
> > > > > > >  include/drm/drm_atomic_helper.h |  1 +
> > > > > > >  2 files changed, 59 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > index f936276..0c1614e 100644
> > > > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > @@ -2895,6 +2895,64 @@ int 
> > > > > > > drm_atomic_helper_connector_dpms(struct drm_connector *connector,
> > > > > > >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> > > > > > >  
> > > > > > >  /**
> > > > > > > + * drm_atomic_helper_connector_modeset - Force a modeset on a 
> > > > > > > connector
> > > > > > > + * @connector: DRM connector
> > > > > > > + *
> > > > > > > + * Provides a way to redo a modeset with the current mode so 
> > > > > > > that it can
> > > > > > > + * drop the bpp, link rate/lane count and retry the link 
> > > > > > > training.
> > > > > > > + *
> > > > > > > + * Returns:
> > > > > > > + * Returns 0 on success, negative errno numbers on failure.
> > > > > > > + */
> > > > > > > +int
> > > > > > > +drm_atomic_helper_connector_modeset(struct drm_connector 
> > > > > > > *connector)
> > > > > > > +{
> > > > > > > + struct drm_device *dev = connector->dev;
> > > > > > > + struct drm_modeset_acquire_ctx ctx;
> > > > > > > + struct drm_atomic_state *state;
> > > > > > > + struct drm_connector_state *connector_state;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > > + int ret = 0;
> > > > > > > +
> > > > > > > + drm_modeset_acquire_init(&ctx, 0);
> > > > > > > + state = drm_atomic_state_alloc(dev);
> > > > > > > + if (!state) {
> > > > > > > + ret = -ENOMEM;
> > > > > > > + goto fail;
> > > > > > > + }
> > > > > > > + state->acquire_ctx = &ctx;
> > > > > > > +retry:
> > > > > > > + ret = 0;
> > > > > > > + connector_state = drm_atomic_get_connector_state(state, 
> > > > > > > connector);
> > > > > > > + if (IS_ERR(connector_state)) {
> > > > > > > + ret = PTR_ERR(connector_state);
> > > > > > > + goto fail;
> > > > > > > + }
> > > > > > > + if (!connector_state->crtc)
> > > > > > > + goto fail;
> > > > > > > +
> > > > > > > + crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > > > > > + 
> > > > > > > connector_state->crtc);
> > > > > > > + crtc_state->connectors_changed = true;
> > > > > > 
> > > > > > This line here only works if the driver uses the helpers for 
> > > > > > checking and
> > > > > > commit, and when it doesn't overwrite connectors_changed. I think 
> > > > > > the
> > > > > > kerneldoc should mention this.
> > > > > > 
> > > > > > The other issue: You cannot call this from modeset code itself 
> > > > > > because of
> > > > > > recursion. I think this also must be mentioned.
> > 
> > I will add this to the kernel doc.
> > In our case, we call this in a work func that will get scheduled after
> > the current modeset is completed.
> > 
> > > > > 
> > > > > And if this indeed does a modeset then we have again the same issue as
> > > > > with upfront link training when the pipe is supposed to be on: 
> > > > > Userspace
> > > > > can observe the kernel playing tricks because the vblank support will 
> > > > > be
> > > > > temporarily disabled.
> > > > > 
> > > > > Not sure how to best fix this, but might be good to grab the 
> > > > > crtc->mutex
> > > > > in the vblank code for stuff like this.
> > > > 
> > > > We're going to have the same problem with async modeset as well.
> > > 
> > > Async modeset is ok because userspace expects that the pipe will go
> > > off/on, and the kernel will send out an event to signal when the pipe is
> > > guaranteed to be on and can be started to be used. It's random modesets
> > > afterwards I'm concerned about.
> > > -Daniel
> > > --

x86 PAT memtype regression fix (resend)

2016-10-24 Thread Ingo Molnar

* Dave Airlie  wrote:

> On 24 October 2016 at 16:03, Dave Airlie  wrote:
> > I messed up one of the mailing lists last time (copied ancient
> > address from another script).
> >
> 
> Oops ignore both of those sets, forgot a git add, will repost once it
> finish rebuild/boot cycle.

Could you please also Cc: the following x86/PAT experts to the resent series:

 Cc: Toshi Kani 
 Cc: Borislav Petkov 
 Cc: H. Peter Anvin 
 Cc: Andy Lutomirski 
 Cc: Denys Vlasenko 
 Cc: Brian Gerst 

Thanks!

Ingo

[Nouveau] [PATCH 01/17] drm/nouveau/core: add missing header dependencies

2016-10-24 Thread Baoyou Xie

On 23 October 2016 at 01:32, Karol Herbst  wrote:

> I think it would be better to squash those commits:
> 1. for the includes
> 2. for static declerations
>
> OK, I have resent new patch that squash those commits.


> 2016-10-22 11:41 GMT+02:00 Baoyou Xie :
> > We get 2 warnings when building kernel with W=1:
> > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous
> prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
> > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous
> prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
> >
> > In fact, these functions are declared in
> > drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h.
> > So this patch adds missing header dependencies.
> >
> > Signed-off-by: Baoyou Xie 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> > index 34ecd4a..058ff46 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> > @@ -20,6 +20,7 @@
> >   * DEALINGS IN THE SOFTWARE.
> >   */
> >  #include 
> > +#include 
> >
> >  /**
> >   * nvkm_firmware_get - load firmware from the official nvidia/chip/
> directory
> > --
> > 2.7.4
> >
> > ___
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/c56ef8f4/attachment-0001.html>

[PATCH] drm/amdgpu: update kernel-doc for some functions

2016-10-24 Thread Edward O'Callaghan

Reviewed-by: Edward O'Callaghan 

On 10/24/2016 05:31 AM, Grazvydas Ignotas wrote:
> The names were wrong.
> 
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/gpu/drm/amd/scheduler/sched_fence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/scheduler/sched_fence.c 
> b/drivers/gpu/drm/amd/scheduler/sched_fence.c
> index 6b63bea..3653b5a 100644
> --- a/drivers/gpu/drm/amd/scheduler/sched_fence.c
> +++ b/drivers/gpu/drm/amd/scheduler/sched_fence.c
> @@ -103,7 +103,7 @@ static void amd_sched_fence_free(struct rcu_head *rcu)
>  }
>  
>  /**
> - * amd_sched_fence_release - callback that fence can be freed
> + * amd_sched_fence_release_scheduled - callback that fence can be freed
>   *
>   * @fence: fence
>   *
> @@ -118,7 +118,7 @@ static void amd_sched_fence_release_scheduled(struct 
> fence *f)
>  }
>  
>  /**
> - * amd_sched_fence_release_scheduled - drop extra reference
> + * amd_sched_fence_release_finished - drop extra reference
>   *
>   * @f: fence
>   *
> 

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

[PATCH 1/4] MAINTAINERS: Add "B:" for URI where to file bugs

On Thu, Oct 20, 2016 at 03:22:12PM +0300, Jani Nikula wrote:
> Different subsystems and drivers have different preferences for where to
> file bugs and what information to include. Add "B:" entry for specifying
> the URI for the bug tracker directly, a web page for detailed info on
> filing bugs, or a mailto: URI.
> 
> Cc: Daniel Vetter 
> Cc: Joe Perches 
> Cc: Andrew Morton 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Dust settled since the last time, maybe we can make URI work?

fwiw I want this, I think documenting bugzilla and irc channels (for
subsystems and drivers using them) will help a lot to make
(sub)communities of the kernel more approachable. On the entire series:

Very-much-Wanted-by: Daniel Vetter 

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 89112a65b831..4a47ec00a09d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -74,6 +74,8 @@ Descriptions of section entries:
>  These reviewers should be CCed on patches.
>   L: Mailing list that is relevant to this area
>   W: Web-page with status/info
> + B: URI for where to file bugs. A web-page with detailed bug
> +filing info, a direct bug tracker link, or a mailto: URI.
>   Q: Patchwork web based patch tracking system site
>   T: SCM tree type and location.
>  Type is one of: git, hg, quilt, stgit, topgit
> -- 
> 2.1.4
> 

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

[PATCH v2] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).

Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- only allocate dma memory for revision 1

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 86 +++-
 1 file changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 87cfde9..92771c6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -21,11 +21,14 @@
 #include 
 #include 
 #include 
+#include 

 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"

-#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
+#define TILCDC_VBLANK_SAFETY_THRESHOLD_US  1000
+#define TILCDC_REV1_PALETTE_SIZE   32
+#define TILCDC_REV1_PALETTE_FIRST_ENTRY0x4000

 struct tilcdc_crtc {
struct drm_crtc base;
@@ -53,6 +56,10 @@ struct tilcdc_crtc {

int sync_lost_count;
bool frame_intact;
+
+   dma_addr_t palette_dma_handle;
+   void *palette_base;
+   struct completion palette_loaded;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -100,6 +107,55 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
tilcdc_crtc->curr_fb = fb;
 }

+/*
+ * The driver currently only supports the RGB565 format for revision 1. For
+ * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
+ * the framebuffer are still considered palette. The first 16-bit entry must
+ * be 0x4000 while all other entries must be zeroed.
+ */
+static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
+{
+   u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
+   struct tilcdc_crtc *tilcdc_crtc;
+   struct drm_device *dev;
+   u16 *first_entry;
+
+   dev = crtc->dev;
+   tilcdc_crtc = to_tilcdc_crtc(crtc);
+   first_entry = tilcdc_crtc->palette_base;
+
+   *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
+
+   dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
+   dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
+   raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+
+   /* Tell the LCDC where the palette is located. */
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
+tilcdc_crtc->palette_dma_handle);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
+(u32)tilcdc_crtc->palette_dma_handle
+   + TILCDC_REV1_PALETTE_SIZE - 1);
+
+   /* Load it. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
+LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+  LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
+
+   /* Enable the LCDC and wait for palette to be loaded. */
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+   wait_for_completion(&tilcdc_crtc->palette_loaded);
+
+   /* Restore the registers. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
+   tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
+}
+
 static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -154,6 +210,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   struct tilcdc_drm_private *priv = dev->dev_private;

WARN_ON(!drm_modeset_is_locked(&crtc->mutex));

@@ -164,6 +221,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)

reset(crtc);

+   if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
+   tilcdc_crtc_load_palette(crtc);
+
tilcdc_crtc_enable_irqs(dev);

tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
@@ -245,6 +305,12 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
of_node_put(crtc->port);
drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
+
+   if (priv->rev == 1) {
+   dma_free_coherent(crtc->dev->dev, TILCDC_REV1_PALETTE_SIZE,
+ tilcdc_crtc->palette_base,
+ tilcdc_crtc->palette_dma_handle);
+   }
 }

 int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
@@ -804,6 +870,14 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
__fun

[PATCH] drm: tilcdc: implement palette loading for rev1

2016-10-21 19:14 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 82 
> +++-
>  1 file changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 87cfde9..cc94cbb 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -21,11 +21,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "tilcdc_drv.h"
>  #include "tilcdc_regs.h"
>
> -#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
> +#define TILCDC_VBLANK_SAFETY_THRESHOLD_US  1000
> +#define TILCDC_REV1_PALETTE_SIZE   32
> +#define TILCDC_REV1_PALETTE_FIRST_ENTRY0x4000
>
>  struct tilcdc_crtc {
> struct drm_crtc base;
> @@ -53,6 +56,10 @@ struct tilcdc_crtc {
>
> int sync_lost_count;
> bool frame_intact;
> +
> +   dma_addr_t palette_dma_handle;
> +   void *palette_base;
> +   struct completion palette_loaded;
>  };
>  #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
>
> @@ -100,6 +107,55 @@ static void set_scanout(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb)
> tilcdc_crtc->curr_fb = fb;
>  }
>
> +/*
> + * The driver currently only supports the RGB565 format for revision 1. For
> + * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
> + * the framebuffer are still considered palette. The first 16-bit entry must
> + * be 0x4000 while all other entries must be zeroed.
> + */
> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
> +{
> +   u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
> +   struct tilcdc_crtc *tilcdc_crtc;
> +   struct drm_device *dev;
> +   u16 *first_entry;
> +
> +   dev = crtc->dev;
> +   tilcdc_crtc = to_tilcdc_crtc(crtc);
> +   first_entry = tilcdc_crtc->palette_base;
> +
> +   *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
> +
> +   dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
> +   dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
> +   raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
> +
> +   /* Tell the LCDC where the palette is located. */
> +   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
> +tilcdc_crtc->palette_dma_handle);
> +   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
> +(u32)tilcdc_crtc->palette_dma_handle
> +   + TILCDC_REV1_PALETTE_SIZE - 1);
> +
> +   /* Load it. */
> +   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> +LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
> +   tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
> +  LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
> +
> +   /* Enable the LCDC and wait for palette to be loaded. */
> +   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
> +   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> +   wait_for_completion(&tilcdc_crtc->palette_loaded);
> +
> +   /* Restore the registers. */
> +   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
> +   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
> +   tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
> +}
> +
>  static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
>  {
> struct tilcdc_drm_private *priv = dev->dev_private;
> @@ -154,6 +210,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>  {
> struct drm_device *dev = crtc->dev;
> struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> +   struct tilcdc_drm_private *priv = dev->dev_private;
>
> WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
>
> @@ -164,6 +221,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>
> reset(crtc);
>
> +   if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
> +   tilcdc_crtc_load_palette(crtc);
> +
> tilcdc_crtc_enable_irqs(dev);
>
> tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
> @@ -245,6 +305,10 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
> of_node_put(crtc->port);
> drm_crtc_cleanup(crtc);
> drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
> +
> +   dma_free_coherent(crtc->dev->dev, TILCDC_REV1_PALETTE_SIZE,
> + tilcdc_crtc->palette_base,
> + tilcdc_crtc->palette_dma_handle);
>  }
>
>  int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
> @@ -804,

[PATCH] drm: tilcdc: implement palette loading for rev1

2016-10-21 19:14 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
>
> Signed-off-by: Bartosz Golaszewski 
> ---

Superseded by v2

Thanks,
Bartosz

[Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

2016-10-24 Thread Maarten Lankhorst

Op 21-10-16 om 16:17 schreef Ville SyrjÃ¤lÃ¤:
> On Fri, Oct 21, 2016 at 05:05:16PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
>> On Wed, Oct 19, 2016 at 03:55:36PM +0200, Maarten Lankhorst wrote:
>>> The only user was i915, which is now gone.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>> cc: dri-devel missing
> Also
> Reviewed-by: Ville SyrjÃ¤lÃ¤ 
Indeed, I'll ask for a ack from a drm maintainer.
>>> ---
>>>  drivers/gpu/drm/drm_edid.c | 26 --
>>>  include/drm/drm_edid.h |  1 -
>>>  2 files changed, 27 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 95de47ba1e77..fc81e0eb6abf 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -3578,32 +3578,6 @@ int drm_av_sync_delay(struct drm_connector 
>>> *connector,
>>>  EXPORT_SYMBOL(drm_av_sync_delay);
>>>  
>>>  /**
>>> - * drm_select_eld - select one ELD from multiple HDMI/DP sinks
>>> - * @encoder: the encoder just changed display mode
>>> - *
>>> - * It's possible for one encoder to be associated with multiple HDMI/DP 
>>> sinks.
>>> - * The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
>>> - *
>>> - * Return: The connector associated with the first HDMI/DP sink that has 
>>> ELD
>>> - * attached to it.
>>> - */
>>> -struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
>>> -{
>>> -   struct drm_connector *connector;
>>> -   struct drm_device *dev = encoder->dev;
>>> -
>>> -   WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>>> -   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>>> -
>>> -   drm_for_each_connector(connector, dev)
>>> -   if (connector->encoder == encoder && connector->eld[0])
>>> -   return connector;
>>> -
>>> -   return NULL;
>>> -}
>>> -EXPORT_SYMBOL(drm_select_eld);
>>> -
>>> -/**
>>>   * drm_detect_hdmi_monitor - detect whether monitor is HDMI
>>>   * @edid: monitor EDID information
>>>   *
>>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>>> index c3a7d440bc11..38eabf65f19d 100644
>>> --- a/include/drm/drm_edid.h
>>> +++ b/include/drm/drm_edid.h
>>> @@ -330,7 +330,6 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
>>> **sads);
>>>  int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
>>>  int drm_av_sync_delay(struct drm_connector *connector,
>>>   const struct drm_display_mode *mode);
>>> -struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
>>>  
>>>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
>>>  int drm_load_edid_firmware(struct drm_connector *connector);
>>> -- 
>>> 2.7.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> -- 
>> Ville SyrjÃ¤lÃ¤
>> Intel OTC
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

--- Comment #5 from Branko  ---
When I do $ git bisect good i have "12 steps" and i don't see anything that can
cause this bug.

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

[PATCH] drm/amdgpu: fix fence slab teardown

Interesting catch, patch is Reviewed-by: Christian KÃ¶nig 
.

Am 24.10.2016 um 04:34 schrieb zhoucm1:
> Acked-by: Chunming Zhou 
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> To free fences, call_rcu() is used, which calls amdgpu_fence_free()
>> after a grace period. During teardown, there is no guarantee all
>> callbacks have finished, so amdgpu_fence_slab may be destroyed before
>> all fences have been freed. If we are lucky, this results in some slab
>> warnings, if not, we get a crash in one of rcu threads because callback
>> is called after amdgpu has already been unloaded.
>>
>> Fix it with a rcu_barrier().
>>
>> Fixes: b44135351a3a ("drm/amdgpu: RCU protected amdgpu_fence_release")
>> Signed-off-by: Grazvydas Ignotas 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> index 3a2e42f..77b34ec 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
>> @@ -68,6 +68,7 @@ int amdgpu_fence_slab_init(void)
>> void amdgpu_fence_slab_fini(void)
>>   {
>> +rcu_barrier();
>>   kmem_cache_destroy(amdgpu_fence_slab);
>>   }
>>   /*
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: fix sched fence slab teardown

Reviewed-by: Christian KÃ¶nig 

Am 24.10.2016 um 04:34 schrieb zhoucm1:
> Acked-by: Chunming Zhou 
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
>> after a grace period. During teardown, there is no guarantee all
>> callbacks have finished, so sched_fence_slab may be destroyed before
>> all fences have been freed. If we are lucky, this results in some slab
>> warnings, if not, we get a crash in one of rcu threads because callback
>> is called after amdgpu has already been unloaded.
>>
>> Fix it with a rcu_barrier().
>>
>> Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected 
>> amd_sched_fence_release")
>> Signed-off-by: Grazvydas Ignotas 
>> ---
>>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> index 963a24d..910b8d5 100644
>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> @@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
>>   {
>>   if (sched->thread)
>>   kthread_stop(sched->thread);
>> +rcu_barrier();
>>   if (atomic_dec_and_test(&sched_fence_slab_ref))
>>   kmem_cache_destroy(sched_fence_slab);
>>   }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: fix a vm_flush fence leak

Am 24.10.2016 um 04:32 schrieb zhoucm1:
>
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> Looks like .last_flush reference is left at teardown.
>> Leak reported by CONFIG_SLUB_DEBUG.
>>
>> Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
>> Signed-off-by: Grazvydas Ignotas 
> Reviewed-by: Chunming Zhou 

Reviewed-by: Christian KÃ¶nig .

>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index ded57dd..d6c2839 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1774,5 +1774,6 @@ void amdgpu_vm_manager_fini(struct 
>> amdgpu_device *adev)
>>   fence_put(adev->vm_manager.ids[i].first);
>> amdgpu_sync_free(&adev->vm_manager.ids[i].active);
>>   fence_put(id->flushed_updates);
>> +fence_put(id->last_flush);
>>   }
>>   }
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v3] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).

Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- only allocate dma memory for revision 1

v2 -> v3:
- use devres managed API for dma memory allocation

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 81 +++-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 87cfde9..bc77b73 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -21,11 +21,15 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"

-#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
+#define TILCDC_VBLANK_SAFETY_THRESHOLD_US  1000
+#define TILCDC_REV1_PALETTE_SIZE   32
+#define TILCDC_REV1_PALETTE_FIRST_ENTRY0x4000

 struct tilcdc_crtc {
struct drm_crtc base;
@@ -53,6 +57,10 @@ struct tilcdc_crtc {

int sync_lost_count;
bool frame_intact;
+
+   dma_addr_t palette_dma_handle;
+   void *palette_base;
+   struct completion palette_loaded;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -100,6 +108,55 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
tilcdc_crtc->curr_fb = fb;
 }

+/*
+ * The driver currently only supports the RGB565 format for revision 1. For
+ * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
+ * the framebuffer are still considered palette. The first 16-bit entry must
+ * be 0x4000 while all other entries must be zeroed.
+ */
+static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
+{
+   u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
+   struct tilcdc_crtc *tilcdc_crtc;
+   struct drm_device *dev;
+   u16 *first_entry;
+
+   dev = crtc->dev;
+   tilcdc_crtc = to_tilcdc_crtc(crtc);
+   first_entry = tilcdc_crtc->palette_base;
+
+   *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
+
+   dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
+   dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
+   raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+
+   /* Tell the LCDC where the palette is located. */
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
+tilcdc_crtc->palette_dma_handle);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
+(u32)tilcdc_crtc->palette_dma_handle
+   + TILCDC_REV1_PALETTE_SIZE - 1);
+
+   /* Load it. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
+LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+  LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
+
+   /* Enable the LCDC and wait for palette to be loaded. */
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+   wait_for_completion(&tilcdc_crtc->palette_loaded);
+
+   /* Restore the registers. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
+   tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
+}
+
 static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -154,6 +211,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   struct tilcdc_drm_private *priv = dev->dev_private;

WARN_ON(!drm_modeset_is_locked(&crtc->mutex));

@@ -164,6 +222,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)

reset(crtc);

+   if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
+   tilcdc_crtc_load_palette(crtc);
+
tilcdc_crtc_enable_irqs(dev);

tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
@@ -804,6 +865,14 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
__func__, stat);

+   if (priv->rev == 1) {
+   if (stat & LCDC_PL_LOAD_DONE) {
+   complete(&tilcdc_crtc->palette_loaded);
+   tilcdc_clear(dev,
+LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+   }
+   }
+
/* For revision 2 only */
if (priv->rev == 2) {
if (stat & LCDC_FRAME_DONE) {
@@ -845,6

[PATCH] drm/amdgpu: release parent fence reference

Am 24.10.2016 um 04:25 schrieb zhoucm1:
>
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> It's done in amd_sched_hw_job_reset(), but not in normal job processing.
>> Leak reported by CONFIG_SLUB_DEBUG.
>>
>> Signed-off-by: Grazvydas Ignotas 
>> ---
>>   CONFIG_SLUB_DEBUG reports more leaks related to ioctls,
>>   but I was unable to track them down...
>>
>>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> index 910b8d5..cfb686e 100644
>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> @@ -522,6 +522,8 @@ static void amd_sched_process_job(struct fence 
>> *f, struct fence_cb *cb)
>> trace_amd_sched_process_job(s_fence);
>>   fence_put(&s_fence->finished);
>> +fence_put(s_fence->parent);
> If I remember correctly, parent was put in sched fence release.

Yes, exactly. It's only released in amd_sched_hw_job_reset() because we 
want to assign a new parent fence.

So this is a clear NAK.

Regards,
Christian.

>
> Regards,
> David Zhou
>> +s_fence->parent = NULL;
>>   wake_up_interruptible(&sched->wake_up_worker);
>>   }
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v2] drm: tilcdc: implement palette loading for rev1

2016-10-24 10:43 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - only allocate dma memory for revision 1
>

Superseded by v3.

Sorry for the noise, but I only noticed that a resource managed
version of dma_alloc_coherent() exists after having sent out v2. This
simplifies the code a bit.

Thanks,
Bartosz

[PATCH] drm/amdgpu: update kernel-doc for some functions

Reviewed-by: Christian KÃ¶nig .

Am 24.10.2016 um 00:29 schrieb Edward O'Callaghan:
> Reviewed-by: Edward O'Callaghan 
>
> On 10/24/2016 05:31 AM, Grazvydas Ignotas wrote:
>> The names were wrong.
>>
>> Signed-off-by: Grazvydas Ignotas 
>> ---
>>   drivers/gpu/drm/amd/scheduler/sched_fence.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/sched_fence.c 
>> b/drivers/gpu/drm/amd/scheduler/sched_fence.c
>> index 6b63bea..3653b5a 100644
>> --- a/drivers/gpu/drm/amd/scheduler/sched_fence.c
>> +++ b/drivers/gpu/drm/amd/scheduler/sched_fence.c
>> @@ -103,7 +103,7 @@ static void amd_sched_fence_free(struct rcu_head *rcu)
>>   }
>>   
>>   /**
>> - * amd_sched_fence_release - callback that fence can be freed
>> + * amd_sched_fence_release_scheduled - callback that fence can be freed
>>*
>>* @fence: fence
>>*
>> @@ -118,7 +118,7 @@ static void amd_sched_fence_release_scheduled(struct 
>> fence *f)
>>   }
>>   
>>   /**
>> - * amd_sched_fence_release_scheduled - drop extra reference
>> + * amd_sched_fence_release_finished - drop extra reference
>>*
>>* @f: fence
>>*
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/e0b103a8/attachment.html>

[PATCH 2/2] drm/drivers: add support for using the arch wc mapping API.

Am 24.10.2016 um 08:31 schrieb Dave Airlie:
> This fixes a regression in all these drivers since the cache
> mode tracking was fixed for mixed mappings. It uses the new
> arch API to add the VRAM range to the PAT mapping tracking
> tables.
>
> Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
> Signed-off-by: Dave Airlie 

Reviewed-by: Christian KÃ¶nig .

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
>   drivers/gpu/drm/ast/ast_ttm.c  | 6 ++
>   drivers/gpu/drm/cirrus/cirrus_ttm.c| 7 +++
>   drivers/gpu/drm/mgag200/mgag200_ttm.c  | 7 +++
>   drivers/gpu/drm/nouveau/nouveau_ttm.c  | 8 
>   drivers/gpu/drm/radeon/radeon_object.c | 5 +
>   6 files changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index aa074fa..f3efb1c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -754,6 +754,10 @@ static const char *amdgpu_vram_names[] = {
>   
>   int amdgpu_bo_init(struct amdgpu_device *adev)
>   {
> + /* reserve PAT memory space to WC for VRAM */
> + arch_io_reserve_memtype_wc(adev->mc.aper_base,
> +adev->mc.aper_size);
> +
>   /* Add an MTRR for the VRAM */
>   adev->mc.vram_mtrr = arch_phys_wc_add(adev->mc.aper_base,
> adev->mc.aper_size);
> @@ -769,6 +773,7 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
>   {
>   amdgpu_ttm_fini(adev);
>   arch_phys_wc_del(adev->mc.vram_mtrr);
> + arch_io_free_memtype_wc(adev->mc.aper_base, adev->mc.aper_size);
>   }
>   
>   int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
> diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
> index 608df4c..0743e65 100644
> --- a/drivers/gpu/drm/ast/ast_ttm.c
> +++ b/drivers/gpu/drm/ast/ast_ttm.c
> @@ -267,6 +267,8 @@ int ast_mm_init(struct ast_private *ast)
>   return ret;
>   }
>   
> + arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
> +pci_resource_len(dev->pdev, 0));
>   ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
>   pci_resource_len(dev->pdev, 0));
>   
> @@ -275,11 +277,15 @@ int ast_mm_init(struct ast_private *ast)
>   
>   void ast_mm_fini(struct ast_private *ast)
>   {
> + struct drm_device *dev = ast->dev;
> +
>   ttm_bo_device_release(&ast->ttm.bdev);
>   
>   ast_ttm_global_release(ast);
>   
>   arch_phys_wc_del(ast->fb_mtrr);
> + arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
> + pci_resource_len(dev->pdev, 0));
>   }
>   
>   void ast_ttm_placement(struct ast_bo *bo, int domain)
> diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
> b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> index bb2438d..5e7e63c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
> @@ -267,6 +267,9 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
>   return ret;
>   }
>   
> + arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
> +pci_resource_len(dev->pdev, 0));
> +
>   cirrus->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
>  pci_resource_len(dev->pdev, 0));
>   
> @@ -276,6 +279,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
>   
>   void cirrus_mm_fini(struct cirrus_device *cirrus)
>   {
> + struct drm_device *dev = cirrus->dev;
> +
>   if (!cirrus->mm_inited)
>   return;
>   
> @@ -285,6 +290,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus)
>   
>   arch_phys_wc_del(cirrus->fb_mtrr);
>   cirrus->fb_mtrr = 0;
> + arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
> + pci_resource_len(dev->pdev, 0));
>   }
>   
>   void cirrus_ttm_placement(struct cirrus_bo *bo, int domain)
> diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
> b/drivers/gpu/drm/mgag200/mgag200_ttm.c
> index 919b35f..dcf7d11 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
> @@ -266,6 +266,9 @@ int mgag200_mm_init(struct mga_device *mdev)
>   return ret;
>   }
>   
> + arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
> +pci_resource_len(dev->pdev, 0));
> +
>   mdev->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
>pci_resource_len(dev->pdev, 0));
>   
> @@ -274,10 +277,14 @@ int mgag200_mm_init(struct mga_device *mdev)
>   
>   void mgag200_mm_fini(struct mga_device *mdev)
>   {
> + struct drm_device *dev = mdev->dev;
> +
>   ttm_bo_device_release(&mdev->ttm.bdev);
>   
>   mgag200_ttm_global_release(mdev);
>   
> + arch_io

[PATCH v2] drm: tilcdc: implement palette loading for rev1

2016-10-24 Thread Jyri Sarha

On 10/24/16 11:43, Bartosz Golaszewski wrote:
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
> 
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - only allocate dma memory for revision 1
> 
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 86 
> +++-
>  1 file changed, 85 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 87cfde9..92771c6 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -21,11 +21,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "tilcdc_drv.h"
>  #include "tilcdc_regs.h"
>  
> -#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
> +#define TILCDC_VBLANK_SAFETY_THRESHOLD_US1000
> +#define TILCDC_REV1_PALETTE_SIZE 32
> +#define TILCDC_REV1_PALETTE_FIRST_ENTRY  0x4000
>  
>  struct tilcdc_crtc {
>   struct drm_crtc base;
> @@ -53,6 +56,10 @@ struct tilcdc_crtc {
>  
>   int sync_lost_count;
>   bool frame_intact;
> +
> + dma_addr_t palette_dma_handle;
> + void *palette_base;
> + struct completion palette_loaded;
>  };
>  #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
>  
> @@ -100,6 +107,55 @@ static void set_scanout(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb)
>   tilcdc_crtc->curr_fb = fb;
>  }
>  
> +/*
> + * The driver currently only supports the RGB565 format for revision 1. For
> + * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
> + * the framebuffer are still considered palette. The first 16-bit entry must
> + * be 0x4000 while all other entries must be zeroed.
> + */
> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
> +{
> + u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
> + struct tilcdc_crtc *tilcdc_crtc;
> + struct drm_device *dev;
> + u16 *first_entry;
> +
> + dev = crtc->dev;
> + tilcdc_crtc = to_tilcdc_crtc(crtc);
> + first_entry = tilcdc_crtc->palette_base;
> +
> + *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
> +
> + dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
> + dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
> + raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
> +
> + /* Tell the LCDC where the palette is located. */
> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
> +  tilcdc_crtc->palette_dma_handle);
> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
> +  (u32)tilcdc_crtc->palette_dma_handle
> + + TILCDC_REV1_PALETTE_SIZE - 1);
> +
> + /* Load it. */
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> +  LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
> +LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
> +
> + /* Enable the LCDC and wait for palette to be loaded. */
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> + wait_for_completion(&tilcdc_crtc->palette_loaded);
> +
> + /* Restore the registers. */
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
> + tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
> +}
> +
>  static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
>  {
>   struct tilcdc_drm_private *priv = dev->dev_private;
> @@ -154,6 +210,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct tilcdc_drm_private *priv = dev->dev_private;
>  
>   WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
>  
> @@ -164,6 +221,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>  
>   reset(crtc);
>  
> + if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
> + tilcdc_crtc_load_palette(crtc);
> +
>   tilcdc_crtc_enable_irqs(dev);
>  
>   tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
> @@ -245,6 +305,12 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
>   of_node_put(crtc->port);
>   drm_crtc_cleanup(crtc);
>   drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
> +
> + if (priv->rev == 1) {
> + dma_free_coherent(crtc->dev->dev, TILCDC_REV1_PALETTE_SIZE,
> +   tilcdc_crtc->palette_base,
> +   tilcdc_crtc->palette_dma_handle);
> + }
>  }
>  
>  int tilcdc_crtc_update_fb(

[Bug 98390] server down

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

Jani Nikula  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

[Bug 98405] No signal on HDMI output after upgrade to kernel 4.8.3-1

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

Bug ID: 98405
   Summary: No signal on HDMI output after upgrade to kernel
4.8.3-1
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: petr.m at seznam.cz

Signal on HDMI output disappear during boot on my computer(mb ASUS AT3IONT-I,
Opensuse Tumbleweed minimal server) after upgrade kernel to 4.8.3-1-default
(64bit).
I can see message "loading initial ramdisk ..." after then blinking cursor in
the corner for a few seconds and after that the screen goes to black and
monitor gives me message "no signal".

I blacklisted nouveau kernel module for getting video signal.
It's enough for me.

https://bugzilla.suse.com/show_bug.cgi?id=1006420

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

[Bug 98358] Build failure in GNOME Continuous

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

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

--- Comment #1 from Marek OlÅ¡Ã¡k  ---
Should be fixed with:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=c2a602d21a4dd7da9d3226a70cb83ab85ceb446a

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

Re: 答复: [PATCH] drm/amdgpu: fix fence slab teardown

2016-10-24 Thread Grazvydas Ignotas

On Mon, Oct 24, 2016 at 6:35 AM, Qu, Jim  wrote:
> I did observed the issue when replace kernel module use DKMS, and it maybe 
> get error at reboot, got calltrace:
>
> [ 3529.525360] 
> =
> [ 3529.525361] BUG amd_sched_fence (Tainted: GB  OE    ): 
> Objects remaining in amd_sched_fence on kmem_cache_close()
> [ 3529.525361] 
> -
> [ 3529.525361]
> [ 3529.525361] INFO: Slab 0xea94b200 objects=25 used=2 
> fp=0x8800252c9180 flags=0x1f4080
> [ 3529.525362] CPU: 0 PID: 18523 Comm: reboot Tainted: GB  OE  
>    3.10.0-512.el7.x86_64 #1
> [ 3529.525362] Hardware name: ASUS All Series/Z87-PLUS, BIOS 1802 01/28/2014
> [ 3529.525363]  ea94b200 b3b19dcf 880160827b50 
> 81685e8c
> [ 3529.525363]  880160827c28 811d9e34 8820 
> 880160827c38
> [ 3529.525364]  880160827be8 656a624f818de5f0 616d657220737463 
> 6e6920676e696e69
> [ 3529.525364] Call Trace:
> [ 3529.525365]  [] dump_stack+0x19/0x1b
> [ 3529.525366]  [] slab_err+0xb4/0xe0
> [ 3529.525367]  [] ? vprintk_default+0x29/0x40
> [ 3529.525368]  [] ? printk+0x5e/0x75
> [ 3529.525369]  [] ? __kmalloc+0x1f3/0x240
> [ 3529.525370]  [] ? kmem_cache_close+0x12b/0x2f0
> [ 3529.525370]  [] kmem_cache_close+0x14c/0x2f0
> [ 3529.525371]  [] __kmem_cache_shutdown+0x14/0x80
> [ 3529.525372]  [] kmem_cache_destroy+0x44/0xf0
> [ 3529.525387]  [] amd_sched_fini+0x3c/0x40 [amdgpu]
> [ 3529.525395]  [] amdgpu_fence_driver_fini+0x7a/0x110 
> [amdgpu]
> [ 3529.525403]  [] amdgpu_device_fini+0x3d/0x1f0 [amdgpu]
> [ 3529.525411]  [] amdgpu_driver_unload_kms+0x43/0x80 
> [amdgpu]
> [ 3529.525416]  [] drm_dev_unregister+0x29/0xb0 [drm]
> [ 3529.525422]  [] drm_put_dev+0x23/0x70 [drm]
> [ 3529.525429]  [] amdgpu_pci_shutdown+0x1d/0x20 [amdgpu]
> [ 3529.525430]  [] pci_device_shutdown+0x36/0x70
> [ 3529.525431]  [] device_shutdown+0xc8/0x180
> [ 3529.525432]  [] kernel_restart_prepare+0x36/0x40
> [ 3529.525433]  [] kernel_restart+0x12/0x60
> [ 3529.525433]  [] SYSC_reboot+0x229/0x260
> [ 3529.525435]  [] ? __do_page_fault+0x171/0x450
> [ 3529.525436]  [] SyS_reboot+0xe/0x10
> [ 3529.525437]  [] system_call_fastpath+0x16/0x1b
> [ 3529.525438] INFO: Object 0x8800252c8a00 @offset=2560
> [ 3529.525438] INFO: Object 0x8800252c9540 @offset=5440
>
>
> Do these series patches fix this issue?

Yes, but only partially - there are still some leaked objects left.
When SLUB_DEBUG is set, you can also set CONFIG_SLUB_DEBUG_ON or add
"slub_debug" to kernel command line to see the leak backtraces.

GraÅ¾vydas

[PATCH 1/3] drm/amdgpu: change function declarations and add missing header dependencies

Am 22.10.2016 um 10:48 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c:38:6: warning: no previous 
> prototype for 'amdgpu_atombios_crtc_overscan_setup' [-Wmissing-prototypes]
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c:661:6: warning: no previous prototype 
> for 'dce_v8_0_disable_dce' [-Wmissing-prototypes]
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:40:5: warning: no previous prototype 
> for 'amdgpu_gfx_scratch_get' [-Wmissing-prototypes]
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:62:6: warning: no previous prototype 
> for 'amdgpu_gfx_scratch_free' [-Wmissing-prototypes]
> 
>
> In fact, these functions are declared in
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.h
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.h
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.h
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.h
> drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h.
> So this patch adds missing header dependencies.
>
> By the way, this patch changes declaration of amdgpu_gfx_parse_disable_cu()
> to subject to its implement, and clean three function declarations
> in pp_acpi.h up.
>
> Signed-off-by: Baoyou Xie 

Patch #2 and #3 of this series is Reviewed-by: Christian KÃ¶nig 
.

The powerplay part is developed by a different team inside AMD, so it 
would be nice to split that change in a different patch and CC 
Rex.Zhu at amd.com on it.

This is only nice to have, so feel free to add an Acked-by: Christian 
KÃ¶nig  on the current version of the patch as 
well.

BTW: Any objections to add Rex into MAINTAINERS for the powerplay 
component? The rather extensive TO list on this trivial patch shows that 
we clearly need to better delegate responsibilities, otherwise people 
will sooner or later start to CC half AMD on fixing a typo :)

Regards,
Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c   | 1 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h   | 3 ++-
>   drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 1 +
>   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 1 +
>   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 1 +
>   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 1 +
>   drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 1 +
>   drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h   | 9 +++--
>   8 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index a074edd..01a42b6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -24,6 +24,7 @@
>*/
>   #include 
>   #include "amdgpu.h"
> +#include "amdgpu_gfx.h"
>   
>   /*
>* GPU scratch registers helpers function.
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> index 51321e1..abd9432 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> @@ -27,6 +27,7 @@
>   int amdgpu_gfx_scratch_get(struct amdgpu_device *adev, uint32_t *reg);
>   void amdgpu_gfx_scratch_free(struct amdgpu_device *adev, uint32_t reg);
>   
> -unsigned amdgpu_gfx_parse_disable_cu(unsigned *mask, unsigned max_se, 
> unsigned max_sh);
> +void amdgpu_gfx_parse_disable_cu(unsigned int *mask, unsigned int max_se,
> + unsigned int max_sh);
>   
>   #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> index f7d236f..8c9bc75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> @@ -31,6 +31,7 @@
>   #include "atom.h"
>   #include "atom-bits.h"
>   #include "atombios_encoders.h"
> +#include "atombios_crtc.h"
>   #include "amdgpu_atombios.h"
>   #include "amdgpu_pll.h"
>   #include "amdgpu_connectors.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 4108c68..443b35f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -31,6 +31,7 @@
>   #include "atombios_encoders.h"
>   #include "amdgpu_pll.h"
>   #include "amdgpu_connectors.h"
> +#include "dce_v10_0.h"
>   
>   #include "dce/dce_10_0_d.h"
>   #include "dce/dce_10_0_sh_mask.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index f264b8f..d58638c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -31,6 +31,7 @@
>   #include "atombios_encoders.h"
>   #include "amdgpu_pll.h"
>   #include "amdgpu_connectors.h"
> +#include "dce_v11_0.h"
>   
>   #include "dce/dce_11_0_d.h"
>   #include "dce/dce_11_0_sh_mask.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 5966166..dd5838c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -31,6 +31,7 @@
>   #include "at

[PATCH] drm/amdgpu: release parent fence reference

2016-10-24 Thread Grazvydas Ignotas

On Mon, Oct 24, 2016 at 12:13 PM, Christian KÃ¶nig
 wrote:
> Am 24.10.2016 um 04:25 schrieb zhoucm1:
>>
>>
>>
>> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>>>
>>> It's done in amd_sched_hw_job_reset(), but not in normal job processing.
>>> Leak reported by CONFIG_SLUB_DEBUG.
>>>
>>> Signed-off-by: Grazvydas Ignotas 
>>> ---
>>>   CONFIG_SLUB_DEBUG reports more leaks related to ioctls,
>>>   but I was unable to track them down...
>>>
>>>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> index 910b8d5..cfb686e 100644
>>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> @@ -522,6 +522,8 @@ static void amd_sched_process_job(struct fence *f,
>>> struct fence_cb *cb)
>>> trace_amd_sched_process_job(s_fence);
>>>   fence_put(&s_fence->finished);
>>> +fence_put(s_fence->parent);
>>
>> If I remember correctly, parent was put in sched fence release.
>
>
> Yes, exactly. It's only released in amd_sched_hw_job_reset() because we want
> to assign a new parent fence.

Well then it doesn't work, SLUB_DEBUG detects leaks on teardown, and
with my patch they're gone.
Perhaps the problem is that when new parent fence is assigned, the old
one is not put? I won't be able to check until the weekend, so if
anybody else can do it, please go ahead.

GraÅ¾vydas

[PATCH] drm/radeon/pm: autoswitch power state when in balanced mode

Am 23.10.2016 um 01:05 schrieb Lucas Stach:
> The current default of always using the performance power state leads
> to increased power consumption of mobile devices, which have a dedicated
> battery power state. Switch between the performance and battery power
> state automatically, dpending on the current AC power status, when the
> user asked for the balanced power state.
>
> The user can still override this logic by asking for the performance
> or battery power state explicitly.
>
> Signed-off-by: Lucas Stach 

Nice addition, the only thing I can of hand see is that you probably 
want to remove the "balanced states don't exist at the moment" comment 
when you actually implement them (or abuse them).

Apart from that I'm not so deep into the PM stuff, so patch is only 
Acked-by: Christian KÃ¶nig .

Regards,
Christian.

> ---
> This saves about 1.2W on my Richland based laptop, whithout me having
> to remember to ask for the battery state or have userspace set up in
> a way to do this.
> ---
>   drivers/gpu/drm/radeon/radeon_pm.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 4b65425..326ad06 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -47,6 +47,7 @@ static bool radeon_pm_in_vbl(struct radeon_device *rdev);
>   static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool 
> finish);
>   static void radeon_pm_update_profile(struct radeon_device *rdev);
>   static void radeon_pm_set_clocks(struct radeon_device *rdev);
> +static void radeon_pm_compute_clocks_dpm(struct radeon_device *rdev);
>   
>   int radeon_pm_get_type_index(struct radeon_device *rdev,
>enum radeon_pm_state_type ps_type,
> @@ -79,6 +80,8 @@ void radeon_pm_acpi_event_handler(struct radeon_device 
> *rdev)
>   radeon_dpm_enable_bapm(rdev, 
> rdev->pm.dpm.ac_power);
>   }
>   mutex_unlock(&rdev->pm.mutex);
> + /* allow new DPM state to be picked */
> + radeon_pm_compute_clocks_dpm(rdev);
>   } else if (rdev->pm.pm_method == PM_METHOD_PROFILE) {
>   if (rdev->pm.profile == PM_PROFILE_AUTO) {
>   mutex_lock(&rdev->pm.mutex);
> @@ -882,7 +885,8 @@ static struct radeon_ps 
> *radeon_dpm_pick_power_state(struct radeon_device *rdev,
>   dpm_state = POWER_STATE_TYPE_INTERNAL_3DPERF;
>   /* balanced states don't exist at the moment */
>   if (dpm_state == POWER_STATE_TYPE_BALANCED)
> - dpm_state = POWER_STATE_TYPE_PERFORMANCE;
> + dpm_state = rdev->pm.dpm.ac_power ?
> + POWER_STATE_TYPE_PERFORMANCE : POWER_STATE_TYPE_BATTERY;
>   
>   restart_search:
>   /* Pick the best power state based on current conditions */

[PATCH v2] drm: tilcdc: implement palette loading for rev1

2016-10-24 11:25 GMT+02:00 Jyri Sarha :
> On 10/24/16 11:43, Bartosz Golaszewski wrote:
>> Revision 1 of the IP doesn't work if we don't load the palette (even
>> if it's not used, which is the case for the RGB565 format).
>>
>> Add a function called from tilcdc_crtc_enable() which performs all
>> required actions if we're dealing with a rev1 chip.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>> v1 -> v2:
>> - only allocate dma memory for revision 1
>>
>
>
> Is it enough to load the palette only once? What if lcdc is powered down
> by power management in the middle?
>
> I think you should reinit the completion struct at least in
> tilcdc_pm_resume(), if not in tilcdc_crtc_disable().
>
> Cheers,
> Jyri
>

Hi Jyri,

I ran the following test:

- tilcdc_crtc_enable() was called on device init
- ran modetest -M tilcdc -s 26:800x600 at RG16 and quit
- waited for the screen to go blank
- tilcdc_crtc_disable() was called
- ran modetest again
- tilcdc_crtc_enable() was called again, this time without calling
tilcdc_crtc_load_palette()
- color bar still correctly displayed

Seems like it's only needed once.

Thanks,
Bartosz

[PATCH] drm: mali-dp: Don't set DRM_PLANE_COMMIT_ACTIVE_ONLY

2016-10-24 Thread Brian Starkey

We need to explicitly disable our planes, so don't set the flag which
would otherwise skip the plane disable when the CRTC is disabled.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_drv.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 9ed938e..f7bb763 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -102,8 +102,7 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 */
malidp_mw_atomic_commit(drm, state);

-   drm_atomic_helper_commit_planes(drm, state,
-   DRM_PLANE_COMMIT_ACTIVE_ONLY);
+   drm_atomic_helper_commit_planes(drm, state, 0);

malidp_atomic_commit_hw_done(state);

-- 
1.7.9.5

[PATCH] drm: mali-dp: Don't set DRM_PLANE_COMMIT_ACTIVE_ONLY

2016-10-24 Thread liviu.du...@arm.com

On Mon, Oct 24, 2016 at 10:52:28AM +0100, Brian Starkey wrote:
> We need to explicitly disable our planes, so don't set the flag which
> would otherwise skip the plane disable when the CRTC is disabled.
> 
> Signed-off-by: Brian Starkey 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/malidp_drv.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9ed938e..f7bb763 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -102,8 +102,7 @@ static void malidp_atomic_commit_tail(struct 
> drm_atomic_state *state)
>*/
>   malidp_mw_atomic_commit(drm, state);
>  
> - drm_atomic_helper_commit_planes(drm, state,
> - DRM_PLANE_COMMIT_ACTIVE_ONLY);
> + drm_atomic_helper_commit_planes(drm, state, 0);
>  
>   malidp_atomic_commit_hw_done(state);
>  
> -- 
> 1.7.9.5
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
Â¯\_(ã)_/Â¯

[PATCH v2] drm: tilcdc: implement palette loading for rev1

2016-10-24 Thread Tomi Valkeinen

On 24/10/16 12:47, Bartosz Golaszewski wrote:
> 2016-10-24 11:25 GMT+02:00 Jyri Sarha :
>> On 10/24/16 11:43, Bartosz Golaszewski wrote:
>>> Revision 1 of the IP doesn't work if we don't load the palette (even
>>> if it's not used, which is the case for the RGB565 format).
>>>
>>> Add a function called from tilcdc_crtc_enable() which performs all
>>> required actions if we're dealing with a rev1 chip.
>>>
>>> Signed-off-by: Bartosz Golaszewski 
>>> ---
>>> v1 -> v2:
>>> - only allocate dma memory for revision 1
>>>
>>
>>
>> Is it enough to load the palette only once? What if lcdc is powered down
>> by power management in the middle?
>>
>> I think you should reinit the completion struct at least in
>> tilcdc_pm_resume(), if not in tilcdc_crtc_disable().
>>
>> Cheers,
>> Jyri
>>
> 
> Hi Jyri,
> 
> I ran the following test:
> 
> - tilcdc_crtc_enable() was called on device init
> - ran modetest -M tilcdc -s 26:800x600 at RG16 and quit
> - waited for the screen to go blank
> - tilcdc_crtc_disable() was called
> - ran modetest again
> - tilcdc_crtc_enable() was called again, this time without calling
> tilcdc_crtc_load_palette()
> - color bar still correctly displayed
> 
> Seems like it's only needed once.

If the power management does its job properly, the IP will get reset
when the IP is suspended. I'm quite sure it won't retain any palettes.

 Tomi

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

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

Hi Ville,

On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
>
> The global mode_config.rotation_property is going away, switch over to
> per-plane rotation_property.


I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm rejects reflect-x and reflect-y rotation prop
values. Is this expected?

I needed to make this modification to get reflect-x/y working too:

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a747bb1..9fcc2c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



Otherwise, the patches look fine to me.

Thanks,
Archit

>
> v2: Drop the BIT()
>
> Cc: Rob Clark 
> Cc: Jilai Wang 
> Cc: Archit Taneja 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> Reviewed-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 951c002b05df..2653ad893ebc 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
> drm_device *dev,
>   !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
>   return;
>
> - if (!dev->mode_config.rotation_property)
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev,
> - DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
> -
> - if (dev->mode_config.rotation_property)
> - drm_object_attach_property(&plane->base,
> - dev->mode_config.rotation_property,
> - DRM_ROTATE_0);
> + drm_plane_create_rotation_property(plane,
> +DRM_ROTATE_0,
> +DRM_ROTATE_0 |
> +DRM_REFLECT_X |
> +DRM_REFLECT_Y);
>  }
>
>  /* helper to install properties which are common to planes and crtcs */
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 98352] [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank

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

--- Comment #2 from Ville Syrjala  ---
The problem on this machine seems to be that the clock is about .6% off,
whereas the test will accept a deviation up to .5%.

I also have a VLV machine with DSI that suffers from a similar problem. I think
for internal panels the best solution might be for the kernel to fix up the
reported clock for the fixed mode. Not sure what we'd do about the EDID though,
assuming the the panel has one and the difference in the clocks would be large
enough to be visible in the EDID timings. And of course not all modes coming
from the EDID even have actual detailed timing descriptors.

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

[PATCH 1/2] drm/msm: add missing header dependencies

2016-10-24 Thread Arnd Bergmann

On Saturday, October 22, 2016 5:17:45 PM CEST Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/msm/msm_debugfs.c:141:5: warning: no previous prototype for 
> 'msm_debugfs_init' [-Wmissing-prototypes]
> drivers/gpu/drm/msm/msm_debugfs.c:158:6: warning: no previous prototype for 
> 'msm_debugfs_cleanup' [-Wmissing-prototypes]
> 
> In fact, these functions are declared in
> drivers/gpu/drm/msm/msm_debugfs.h.
> So this patch adds missing header dependencies.
> 
> Signed-off-by: Baoyou Xie 
> 

Both patches

Reviewed-by: Arnd Bergmann 

Strangely, something caused the second mail to show up as a reply to the
first. No idea how that happened, but you may want to check the procedure
you used for sending the mails.

Arnd

[PATCH] drm/i2c/tda998x: mark symbol static where possible

2016-10-24 Thread Arnd Bergmann

On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for 
> 'tda998x_audio_digital_mute' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks this function with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> 

Reviewed-by: Arnd Bergmann

[Bug 98352] [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank

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

--- Comment #3 from Chris Wilson  ---
Yeah, I'm just sending a patch to detect the "clock error" and teach BAT to
skip this test (adding another test to kms_setmode to actually complain about
the mismatch). Since userspace is using the dotclock to calculate the MscRate
(oh, the merriment with dynamic refresh) we should think of someway to remove
the discrepancy between the modeline and actual hardware value. At the very
basic level, could we fixup the mode as reported via GetCrtc?

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

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

2016-10-24 Thread Ville Syrjälä

On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
> Hi Ville,
> 
> On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
> > From: Ville SyrjÃ¤lÃ¤ 
> >
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_property.
> 
> 
> I was trying to test this on msm/drm using modetest. The 180 rotation
> works fine, but drm rejects reflect-x and reflect-y rotation prop
> values. Is this expected?
> 
> I needed to make this modification to get reflect-x/y working too:
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a747bb1..9fcc2c9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property ||
>  property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> + if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))

That makes no sense. You _must_ to pass one and only one rotation angle.
In *addition* you can pass any number of the reflection flags.

>   return -EINVAL;
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
> 
> 
> 
> Otherwise, the patches look fine to me.
> 
> Thanks,
> Archit
> 
> >
> > v2: Drop the BIT()
> >
> > Cc: Rob Clark 
> > Cc: Jilai Wang 
> > Cc: Archit Taneja 
> > Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> > Reviewed-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> > b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > index 951c002b05df..2653ad893ebc 100644
> > --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > @@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
> > drm_device *dev,
> > !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
> > return;
> >
> > -   if (!dev->mode_config.rotation_property)
> > -   dev->mode_config.rotation_property =
> > -   drm_mode_create_rotation_property(dev,
> > -   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
> > -
> > -   if (dev->mode_config.rotation_property)
> > -   drm_object_attach_property(&plane->base,
> > -   dev->mode_config.rotation_property,
> > -   DRM_ROTATE_0);
> > +   drm_plane_create_rotation_property(plane,
> > +  DRM_ROTATE_0,
> > +  DRM_ROTATE_0 |
> > +  DRM_REFLECT_X |
> > +  DRM_REFLECT_Y);
> >  }
> >
> >  /* helper to install properties which are common to planes and crtcs */
> >
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH] drm/arm: mark symbols static where possible

2016-10-24 Thread Arnd Bergmann

On Saturday, October 22, 2016 5:13:01 PM CEST Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/arm/malidp_planes.c:49:25: warning: no previous prototype for 
> 'malidp_duplicate_plane_state' [-Wmissing-prototypes]
> drivers/gpu/drm/arm/malidp_planes.c:66:6: warning: no previous prototype for 
> 'malidp_destroy_plane_state' [-Wmissing-prototypes]
> 
> In fact, both functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> So this patch marks these functions with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> ---
...
> @@ -63,7 +64,7 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
> drm_plane *plane)
>   return &state->base;
>  }
>  
> -void malidp_destroy_plane_state(struct drm_plane *plane,
> +static void malidp_destroy_plane_state(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
>   struct malidp_plane_state *m_state = to_malidp_plane_state(state);
> 

The change looks correct, but I notice that the two lines of the
declaration are no longer aligned.

The file follows the normal style of aligning the argument list
in the second line to line up with the opening '(', so please keep
it that way.

Arnd

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property



On 10/24/2016 03:45 PM, Ville SyrjÃ¤lÃ¤ wrote:
> On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
>> Hi Ville,
>>
>> On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
>>> From: Ville SyrjÃ¤lÃ¤ 
>>>
>>> The global mode_config.rotation_property is going away, switch over to
>>> per-plane rotation_property.
>>
>>
>> I was trying to test this on msm/drm using modetest. The 180 rotation
>> works fine, but drm rejects reflect-x and reflect-y rotation prop
>> values. Is this expected?
>>
>> I needed to make this modification to get reflect-x/y working too:
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index a747bb1..9fcc2c9 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane 
>> *plane,
>>  state->src_h = val;
>>  } else if (property == config->rotation_property ||
>> property == plane->rotation_property) {
>> -if (!is_power_of_2(val & DRM_ROTATE_MASK))
>> +if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
>
> That makes no sense. You _must_ to pass one and only one rotation angle.
> In *addition* you can pass any number of the reflection flags.

Okay. Does the rotation property also include reflection flags, though?

When I dump plane properties using modetest, I get:

31 rotation:
  flags: bitmask
  values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
  value: 1

If I use modetest to set 0x10 or 0x20, it returns an error. I wanted to
know if this is expected behavior or not?

Thanks,
Archit

>
>>  return -EINVAL;
>>  state->rotation = val;
>>  } else if (property == plane->zpos_property) {
>>
>>
>>
>> Otherwise, the patches look fine to me.
>>
>> Thanks,
>> Archit
>>
>>>
>>> v2: Drop the BIT()
>>>
>>> Cc: Rob Clark 
>>> Cc: Jilai Wang 
>>> Cc: Archit Taneja 
>>> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
>>> Reviewed-by: Rob Clark 
>>> ---
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
>>>  1 file changed, 5 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
>>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>>> index 951c002b05df..2653ad893ebc 100644
>>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
>>> @@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
>>> drm_device *dev,
>>> !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
>>> return;
>>>
>>> -   if (!dev->mode_config.rotation_property)
>>> -   dev->mode_config.rotation_property =
>>> -   drm_mode_create_rotation_property(dev,
>>> -   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
>>> -
>>> -   if (dev->mode_config.rotation_property)
>>> -   drm_object_attach_property(&plane->base,
>>> -   dev->mode_config.rotation_property,
>>> -   DRM_ROTATE_0);
>>> +   drm_plane_create_rotation_property(plane,
>>> +  DRM_ROTATE_0,
>>> +  DRM_ROTATE_0 |
>>> +  DRM_REFLECT_X |
>>> +  DRM_REFLECT_Y);
>>>  }
>>>
>>>  /* helper to install properties which are common to planes and crtcs */
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

2016-10-24 Thread Ville Syrjälä

On Mon, Oct 24, 2016 at 03:52:09PM +0530, Archit Taneja wrote:
> 
> 
> On 10/24/2016 03:45 PM, Ville SyrjÃ¤lÃ¤ wrote:
> > On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
> >> Hi Ville,
> >>
> >> On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
> >>> From: Ville SyrjÃ¤lÃ¤ 
> >>>
> >>> The global mode_config.rotation_property is going away, switch over to
> >>> per-plane rotation_property.
> >>
> >>
> >> I was trying to test this on msm/drm using modetest. The 180 rotation
> >> works fine, but drm rejects reflect-x and reflect-y rotation prop
> >> values. Is this expected?
> >>
> >> I needed to make this modification to get reflect-x/y working too:
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index a747bb1..9fcc2c9 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >> *plane,
> >>state->src_h = val;
> >>} else if (property == config->rotation_property ||
> >>   property == plane->rotation_property) {
> >> -  if (!is_power_of_2(val & DRM_ROTATE_MASK))
> >> +  if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
> >
> > That makes no sense. You _must_ to pass one and only one rotation angle.
> > In *addition* you can pass any number of the reflection flags.
> 
> Okay. Does the rotation property also include reflection flags, though?

Yes.

> 
> When I dump plane properties using modetest, I get:
> 
> 31 rotation:
>   flags: bitmask
>   values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
>   value: 1
> 
> If I use modetest to set 0x10 or 0x20, it returns an error. I wanted to
> know if this is expected behavior or not?

It is. If you want 0 degree rotation with X reflection you have to pass
0x11.

> 
> Thanks,
> Archit
> 
> >
> >>return -EINVAL;
> >>state->rotation = val;
> >>} else if (property == plane->zpos_property) {
> >>
> >>
> >>
> >> Otherwise, the patches look fine to me.
> >>
> >> Thanks,
> >> Archit
> >>
> >>>
> >>> v2: Drop the BIT()
> >>>
> >>> Cc: Rob Clark 
> >>> Cc: Jilai Wang 
> >>> Cc: Archit Taneja 
> >>> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> >>> Reviewed-by: Rob Clark 
> >>> ---
> >>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
> >>>  1 file changed, 5 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> >>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >>> index 951c002b05df..2653ad893ebc 100644
> >>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >>> @@ -75,15 +75,11 @@ static void 
> >>> mdp5_plane_install_rotation_property(struct drm_device *dev,
> >>>   !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
> >>>   return;
> >>>
> >>> - if (!dev->mode_config.rotation_property)
> >>> - dev->mode_config.rotation_property =
> >>> - drm_mode_create_rotation_property(dev,
> >>> - DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
> >>> -
> >>> - if (dev->mode_config.rotation_property)
> >>> - drm_object_attach_property(&plane->base,
> >>> - dev->mode_config.rotation_property,
> >>> - DRM_ROTATE_0);
> >>> + drm_plane_create_rotation_property(plane,
> >>> +DRM_ROTATE_0,
> >>> +DRM_ROTATE_0 |
> >>> +DRM_REFLECT_X |
> >>> +DRM_REFLECT_Y);
> >>>  }
> >>>
> >>>  /* helper to install properties which are common to planes and crtcs */
> >>>
> >>
> >> --
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >> a Linux Foundation Collaborative Project
> >
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property



On 10/24/2016 03:55 PM, Ville SyrjÃ¤lÃ¤ wrote:
> On Mon, Oct 24, 2016 at 03:52:09PM +0530, Archit Taneja wrote:
>>
>>
>> On 10/24/2016 03:45 PM, Ville SyrjÃ¤lÃ¤ wrote:
>>> On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
 Hi Ville,

 On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
> From: Ville SyrjÃ¤lÃ¤ 
>
> The global mode_config.rotation_property is going away, switch over to
> per-plane rotation_property.


 I was trying to test this on msm/drm using modetest. The 180 rotation
 works fine, but drm rejects reflect-x and reflect-y rotation prop
 values. Is this expected?

 I needed to make this modification to get reflect-x/y working too:

 diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 index a747bb1..9fcc2c9 100644
 --- a/drivers/gpu/drm/drm_atomic.c
 +++ b/drivers/gpu/drm/drm_atomic.c
 @@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane 
 *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
 -  if (!is_power_of_2(val & DRM_ROTATE_MASK))
 +  if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
>>>
>>> That makes no sense. You _must_ to pass one and only one rotation angle.
>>> In *addition* you can pass any number of the reflection flags.
>>
>> Okay. Does the rotation property also include reflection flags, though?
>
> Yes.
>
>>
>> When I dump plane properties using modetest, I get:
>>
>> 31 rotation:
>>   flags: bitmask
>>   values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
>>   value: 1
>>
>> If I use modetest to set 0x10 or 0x20, it returns an error. I wanted to
>> know if this is expected behavior or not?
>
> It is. If you want 0 degree rotation with X reflection you have to pass
> 0x11.

Ah okay, didn't realize I had to put a 0 degree rotation along with the
reflect. Works fine with 0x11. Thanks for the clarification.

Archit

>
>>
>> Thanks,
>> Archit
>>
>>>
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



 Otherwise, the patches look fine to me.

 Thanks,
 Archit

>
> v2: Drop the BIT()
>
> Cc: Rob Clark 
> Cc: Jilai Wang 
> Cc: Archit Taneja 
> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
> Reviewed-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 951c002b05df..2653ad893ebc 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -75,15 +75,11 @@ static void 
> mdp5_plane_install_rotation_property(struct drm_device *dev,
>   !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
>   return;
>
> - if (!dev->mode_config.rotation_property)
> - dev->mode_config.rotation_property =
> - drm_mode_create_rotation_property(dev,
> - DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
> -
> - if (dev->mode_config.rotation_property)
> - drm_object_attach_property(&plane->base,
> - dev->mode_config.rotation_property,
> - DRM_ROTATE_0);
> + drm_plane_create_rotation_property(plane,
> +DRM_ROTATE_0,
> +DRM_ROTATE_0 |
> +DRM_REFLECT_X |
> +DRM_REFLECT_Y);
>  }
>
>  /* helper to install properties which are common to planes and crtcs */
>

 --
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 a Linux Foundation Collaborative Project
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

--- Comment #6 from Christian KÃ¶nig  ---
(In reply to Branko from comment #4)
> I have cloned mesa-git and i'm trying to do it, but i get only this output:
> 
> $ git bisect start mesa-12.0.1 mesa-11.2.2
> Previous HEAD position was 4cd5e5b... nouveau: update the Makefile.sources
> list
> Switched to branch 'master'
> Your branch is up-to-date with 'origin/master'.
> Bisecting: a merge base must be tested
> [4cd5e5b48e24a8b8ff7255022208d3e5fe6557d8] nouveau: update the
> Makefile.sources list

This is the expected result. Now you need to build and install Mesa and see if
the problem persists.

If you never build and installed Mesa before I suggest you just checkout
version 11.2.2 (e.g. run "git checkout mesa-11.2.2") and try that first.

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

[PATCH v4] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).

Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- only allocate dma memory for revision 1

v2 -> v3:
- use devres managed API for dma memory allocation

v3 -> v4:
- reinit the palette completion in tilcdc_crtc_disable()

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 88 +++-
 1 file changed, 87 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 87cfde9..5baf436 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -21,11 +21,15 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"

-#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
+#define TILCDC_VBLANK_SAFETY_THRESHOLD_US  1000
+#define TILCDC_REV1_PALETTE_SIZE   32
+#define TILCDC_REV1_PALETTE_FIRST_ENTRY0x4000

 struct tilcdc_crtc {
struct drm_crtc base;
@@ -53,6 +57,10 @@ struct tilcdc_crtc {

int sync_lost_count;
bool frame_intact;
+
+   dma_addr_t palette_dma_handle;
+   void *palette_base;
+   struct completion palette_loaded;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -100,6 +108,55 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
tilcdc_crtc->curr_fb = fb;
 }

+/*
+ * The driver currently only supports the RGB565 format for revision 1. For
+ * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
+ * the framebuffer are still considered palette. The first 16-bit entry must
+ * be 0x4000 while all other entries must be zeroed.
+ */
+static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
+{
+   u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
+   struct tilcdc_crtc *tilcdc_crtc;
+   struct drm_device *dev;
+   u16 *first_entry;
+
+   dev = crtc->dev;
+   tilcdc_crtc = to_tilcdc_crtc(crtc);
+   first_entry = tilcdc_crtc->palette_base;
+
+   *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
+
+   dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
+   dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
+   raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+
+   /* Tell the LCDC where the palette is located. */
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
+tilcdc_crtc->palette_dma_handle);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
+(u32)tilcdc_crtc->palette_dma_handle
+   + TILCDC_REV1_PALETTE_SIZE - 1);
+
+   /* Load it. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
+LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+  LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
+
+   /* Enable the LCDC and wait for palette to be loaded. */
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+   tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+   wait_for_completion(&tilcdc_crtc->palette_loaded);
+
+   /* Restore the registers. */
+   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
+   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
+   tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
+}
+
 static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -154,6 +211,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   struct tilcdc_drm_private *priv = dev->dev_private;

WARN_ON(!drm_modeset_is_locked(&crtc->mutex));

@@ -164,6 +222,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)

reset(crtc);

+   if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
+   tilcdc_crtc_load_palette(crtc);
+
tilcdc_crtc_enable_irqs(dev);

tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
@@ -202,6 +263,13 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
__func__);
}

+   /*
+* LCDC will not retain the palette when reset. Make sure it gets
+* reloaded on tilcdc_crtc_enable().
+*/
+   if (priv->rev == 1)
+   reinit_completion(&tilcdc_crtc->palette_loaded);
+
drm_crtc_vblank_off(crtc);

tilcdc_crtc_disable_irqs(dev);
@@ -804,6 +872,14 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev

[PATCH v3] drm: tilcdc: implement palette loading for rev1

2016-10-24 11:13 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - only allocate dma memory for revision 1
>
> v2 -> v3:
> - use devres managed API for dma memory allocation
>

Superseded by v4.

Bartosz

[PATCH libdrm 2/2] Silence runtime complaints on platform devices

2016-10-24 Thread Emil Velikov

On 21 October 2016 at 18:12, Eric Anholt  wrote:
> glxgears was spamming this 12 times at startup because of Mesa's
> probing of the DRM device code, which doesn't support platform
> devices.
>
Better option is to add support for platform devices. Can we get
anyone interested in that ?
If we drop (the annoying) printf people will just ignore/forget about
it, and things will fall through the cracks - similar to the 5+ pokes
(at various people) to add support.

On the cool side - it will allow you to use the DRI_PRIME/driconf's
device_id=libudev_path_id_tag to manage the devices on your system.

Thanks
Emil

[Bug 98410] Applications crash when exiting

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

Bug ID: 98410
Summary: Applications crash when exiting
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel at lists.freedesktop.org
Reporter: cismalescumlord at programmer.net

closing various applications leads to a crash. A couple of examples below. I
set DRI_PRIME=1 as that uses the Radeon card and not the Intel. My laptop runs
faster, cooler and quieter when I use this. Setting DRI_PRIME=0 does prevent
the crashes. Firefox, Thunderbird and PyCharm all run and close just fine with
DRI_PRIME=1.

kate
No docs r (or the only) opened right now --> disable menu
radeon: Failed to allocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:va: 0x80
radeon: Failed to allocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:va: 0x80
radeonsi: Failed to create a context.
No docs r (or the only) opened right now --> disable menu
We got some errors while running testparm "Load smb config files from
/etc/samba/smb.conf\nLoaded services file OK.\nWARNING: The 'netbios name' is
too long (max. 15 chars).\n\n"
0x1f61ce0 deleted without having been removed from the factory first. This
will leak standalone popupmenus and could lead to crashes.
KCrash: Application 'kate' crashing...

konsole
radeon: Failed to allocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:va: 0x80
radeon: Failed to allocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:alignment : 4096 bytes
radeon:domains : 4
radeon:va: 0x0080
radeon: Failed to deallocate virtual address for buffer:
radeon:size : 65536 bytes
radeon:va: 0x80
radeonsi: Failed to create a context.
KCrash: Application 'konsole' crashing...

This works fine with Kernel 4.7

$ kate
No docs r (or the only) opened right now --> disable menu
No docs r (or the only) opened right now --> disable menu
We got some errors while running testparm "Load smb config files from
/etc/samba/smb.conf\nLoaded services file OK.\nWARNING: The 'netbios name' is
too long (max. 15 chars).\n\n"
0x1515460 deleted without having been removed from the factory first. This will
leak standalone popupmenus and could lead to crashes.

$ uname -a
Linux andromeda-ascendant 4.7.6-1-default #1 SMP PREEMPT Fri Sep 30 12:22:14
UTC 2016 (fb37fcc) x86_64 x86_64 x86_64 GNU/Linux

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

[PATCH v2] drm/edid: Only print the bad edid when aborting

2016-10-24 Thread Chris Wilson

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

v2: Print the whole EDID, marking up the bad/zero blocks. This requires
recording the whole of the raw edid, then a second pass to reduce it to
the valid extensions.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_edid.c | 78 --
 1 file changed, 55 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77..2789eb0b9162 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1260,6 +1260,34 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }

+static void connector_bad_edid(struct drm_connector *connector,
+  u8 *edid, int num_blocks)
+{
+   int i;
+
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   dev_warn(connector->dev->dev,
+"%s: EDID is invalid:\n",
+connector->name);
+   for (i = 0; i < num_blocks; i++) {
+   u8 *block = edid + i * EDID_LENGTH;
+   char prefix[20];
+
+   if (drm_edid_is_zero(block, EDID_LENGTH))
+   sprintf(prefix, "\t[%02x] ZERO ", i);
+   else if (!drm_edid_block_valid(block, i, false, NULL))
+   sprintf(prefix, "\t[%02x] BAD  ", i);
+   else
+   sprintf(prefix, "\t[%02x] GOOD ", i);
+
+   print_hex_dump(KERN_WARNING,
+  prefix, DUMP_PREFIX_NONE, 16, 1,
+  block, EDID_LENGTH, false);
+   }
+}
+
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
@@ -1283,7 +1311,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
-   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);

if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1292,7 +1319,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
for (i = 0; i < 4; i++) {
if (get_edid_block(data, edid, 0, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(edid, 0, print_bad_edid,
+   if (drm_edid_block_valid(edid, 0, false,
 &connector->edid_corrupt))
break;
if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
@@ -1304,54 +1331,59 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
goto carp;

/* if there's no extensions, we're done */
-   if (edid[0x7e] == 0)
+   valid_extensions = edid[0x7e];
+   if (valid_extensions == 0)
return (struct edid *)edid;

-   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
+   new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
goto out;
edid = new;

for (j = 1; j <= edid[0x7e]; j++) {
-   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
+   u8 *block = edid + j * EDID_LENGTH;

for (i = 0; i < 4; i++) {
if (get_edid_block(data, block, j, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block, j,
-print_bad_edid, NULL)) {
-   valid_extensions++;
+   if (drm_edid_block_valid(block, j, false, NULL)) {
+   valid_extensions--;
break;
}
}
-
-   if (i == 4 && print_bad_edid) {
-   dev_warn(connector->dev->dev,
-"%s: Ignoring invalid EDID block %d.\n",
-connector->name, j);
-
-   connector->bad_edid_counter++;
-   }
}

if (valid_extensions != edid[0x7e]) {
+   u8 *base;
+
+   connector_bad_edid(connector, edid, edid[0x7e] + 1);
+
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
edid[0x7e] = valid_extensions;
-   new = krealloc(edid, (vali

[PATCH v2] drm/edid: Only print the bad edid when aborting

2016-10-24 Thread Chris Wilson

On Mon, Oct 24, 2016 at 12:33:41PM +0100, Chris Wilson wrote:
>   for (j = 1; j <= edid[0x7e]; j++) {
> - u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
> + u8 *block = edid + j * EDID_LENGTH;
>  
>   for (i = 0; i < 4; i++) {
>   if (get_edid_block(data, block, j, EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block, j,
> -  print_bad_edid, NULL)) {
> - valid_extensions++;
> + if (drm_edid_block_valid(block, j, false, NULL)) {
> + valid_extensions--;

Inverted.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v3] drm/edid: Only print the bad edid when aborting

2016-10-24 Thread Chris Wilson

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

v2: Print the whole EDID, marking up the bad/zero blocks. This requires
recording the whole of the raw edid, then a second pass to reduce it to
the valid extensions.
v3: Fix invalid/valid extension fumble.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson 
Cc: Ville SyrjÃ¤lÃ¤ 
---
 drivers/gpu/drm/drm_edid.c | 79 --
 1 file changed, 56 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77..9506933b41cd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1260,6 +1260,34 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }

+static void connector_bad_edid(struct drm_connector *connector,
+  u8 *edid, int num_blocks)
+{
+   int i;
+
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   dev_warn(connector->dev->dev,
+"%s: EDID is invalid:\n",
+connector->name);
+   for (i = 0; i < num_blocks; i++) {
+   u8 *block = edid + i * EDID_LENGTH;
+   char prefix[20];
+
+   if (drm_edid_is_zero(block, EDID_LENGTH))
+   sprintf(prefix, "\t[%02x] ZERO ", i);
+   else if (!drm_edid_block_valid(block, i, false, NULL))
+   sprintf(prefix, "\t[%02x] BAD  ", i);
+   else
+   sprintf(prefix, "\t[%02x] GOOD ", i);
+
+   print_hex_dump(KERN_WARNING,
+  prefix, DUMP_PREFIX_NONE, 16, 1,
+  block, EDID_LENGTH, false);
+   }
+}
+
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
@@ -1283,7 +1311,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
-   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);

if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1292,7 +1319,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
for (i = 0; i < 4; i++) {
if (get_edid_block(data, edid, 0, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(edid, 0, print_bad_edid,
+   if (drm_edid_block_valid(edid, 0, false,
 &connector->edid_corrupt))
break;
if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
@@ -1304,54 +1331,60 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
goto carp;

/* if there's no extensions, we're done */
-   if (edid[0x7e] == 0)
+   valid_extensions = edid[0x7e];
+   if (valid_extensions == 0)
return (struct edid *)edid;

-   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
+   new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
goto out;
edid = new;

for (j = 1; j <= edid[0x7e]; j++) {
-   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
+   u8 *block = edid + j * EDID_LENGTH;

for (i = 0; i < 4; i++) {
if (get_edid_block(data, block, j, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block, j,
-print_bad_edid, NULL)) {
-   valid_extensions++;
+   if (drm_edid_block_valid(block, j, false, NULL))
break;
-   }
}

-   if (i == 4 && print_bad_edid) {
-   dev_warn(connector->dev->dev,
-"%s: Ignoring invalid EDID block %d.\n",
-connector->name, j);
-
-   connector->bad_edid_counter++;
-   }
+   if (i == 4)
+   valid_extensions--;
}

if (valid_extensions != edid[0x7e]) {
+   u8 *base;
+
+   connector_bad_edid(connector, edid, edid[0x7e] + 1);
+
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

--- Comment #10 from Johannes Hirte  ---
(In reply to Ernst SjÃ¶strand from comment #9)
> Is this fixed somewhere now also?

still happens with 4.9-rc2 as well as 4.10-wip

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

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

2016-10-24 Thread Philipp Zabel

Am Freitag, den 21.10.2016, 16:49 +0800 schrieb Ying Liu:
> On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel  
> wrote:
> > Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
> >> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel  
> >> wrote:
> >> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
> >> >> >> Does the clip thing potentially change the user's request by force?
> >> >> >> For example, the user request an unreasonable big resolution.
> >> >> >
> >> >> > The user is allowed to ask for destination coordinates extending 
> >> >> > outside
> >> >> > the crtc dimensions. This will chop off the parts that aren't visible,
> >> >> > and it will chop off the corresponding areas of the source as well.
> >> >>
> >> >> How about returning -EINVAL in this case which stands for
> >> >> an atomic check failure?
> >> >
> >> > Say the user requests to display a 640x480+0,0 source framebuffer at
> >> > destination offset -320,0 on a 320x240 screen, unscaled. The expectation
> >> > would be to see the upper right quarter of the framebuffer on the
> >> > screen, at least if the hardware was actually able to position overlays
> >> > partially offscreen.
> >> > If we can also fulfill that expectation by clipping the source rectangle
> >> > to 320,240+320,0 and changing the destination rectangle to 320x240+0,0,
> >> > why should -EINVAL be returned?
> >>
> >> Well, IIUC, there are two kinds of clipping.
> >> 1) Clipping a rectangle from a fb according to src_x/y and src_w/h.
> >> 2) Clipping done by drm_plane_helper_check_state(), which potentially
> >> changes src/dst->x1/2 and src/dst->y1/2(in other words, src_x/y,
> >> src_w/h and crtc_x/y/w/h, though not directly).
> >>
> >> 1) is fine, no problem.
> >> I doubt 2) is wrong as the users' original request could be changed.
> >> That's why I mentioned returning -EINVAL.
> >>
> >> Moreover, before and after applying the patch, I think the
> >> ->atomic_check behavior consistency is broken. For example,
> >> negative crtc_x or crtc_y for overlay are changed from unacceptable
> >> to potentially acceptable just because 2) may change their equivalent
> >> dst_>x/y1.
> >
> > I fail to see what's wrong with 2) as long as we can keep the observable
> > behaviour exactly the same as if the user request was unchanged.
> 
> It seems the behavior could change - negative crtc_x or crtc_y for
> overlay make ->atomic_check return -EINVAL before(overlay hw state
> machine has nothing changed), and potentially successful after(overlay
> hw state machine changes).

That in itself doesn't seem so bad. One thing we can't do though is
'position' at any negative crtc_x/y due to the fact that when clipping
the src.x1/y1 still must be even for chroma subsampled pixel formats and
the x1 still must result in scanline start addresses aligned to 8-byte
boundaries. So for 32-bit framebuffer depth negative x offsets must be
even, and for 16-bit framebuffer depth only negative x offsets that are
a multiple of 4 are possible.

regards
Philipp

[PATCH 0/6] Rebase of David Herrmann drm connector link to backlight device

Hi David,

I am currently investigating:
https://bugs.freedesktop.org/show_bug.cgi?id=96572

Martin Peres suggested that your patches:
https://lists.freedesktop.org/archives/dri-devel/2014-September/thread.html#67984
could solve the xf86-video-modesetting backlight issues.

I have rebased your patches and I am working on an IGT
test for the functionality. With my i915 implementation
and the small included bug-fix, I can update the drm BACKLIGHT
property and the value is updated in the backlight class device.
However, if I set the brigness value through the sysfs file of
the backlight class device the drm BRIGHTNESS property does not
update which would be confusing to users.

My understanding is that DRM properties are cached and, by design,
do not have the capability to read the status from the driver.

What do we want to do about this?

Marta

David Herrmann (4):
  backlight: use static initializers
  backlight: use spin-lock to protect device list
  backlight: add kernel-internal backlight API
  drm: link connectors to backlight devices

Marta Lofstedt (2):
  i915: Use drm backlight
  drm: drm_backlight use the connect value to set brightness property

 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_backlight.c | 387 
 drivers/gpu/drm/drm_connector.c |  11 +
 drivers/gpu/drm/drm_crtc.c  |   6 +
 drivers/gpu/drm/drm_drv.c   |   8 +
 drivers/gpu/drm/drm_sysfs.c |  54 +
 drivers/gpu/drm/i915/intel_panel.c  |   5 +
 drivers/video/backlight/backlight.c |  91 +++--
 include/drm/drm_backlight.h |  44 
 include/drm/drm_connector.h |   3 +
 include/drm/drm_crtc.h  |   5 +
 include/linux/backlight.h   |  17 ++
 13 files changed, 621 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_backlight.c
 create mode 100644 include/drm/drm_backlight.h

-- 
2.9.3

[PATCH 1/6] backlight: use static initializers

From: David Herrmann 

Use static initializers instead of setting up global variables during
runtime. This reduces code size and execution time.

Signed-off-by: David Herrmann 
---
 drivers/video/backlight/backlight.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 288318a..37f6173 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -21,9 +21,9 @@
 #include 
 #endif

-static struct list_head backlight_dev_list;
-static struct mutex backlight_dev_list_mutex;
-static struct blocking_notifier_head backlight_notifier;
+static LIST_HEAD(backlight_dev_list);
+static DEFINE_MUTEX(backlight_dev_list_mutex);
+static BLOCKING_NOTIFIER_HEAD(backlight_notifier);

 static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
@@ -591,9 +591,6 @@ static int __init backlight_class_init(void)

backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
-   INIT_LIST_HEAD(&backlight_dev_list);
-   mutex_init(&backlight_dev_list_mutex);
-   BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);

return 0;
 }
-- 
2.9.3

[PATCH 2/6] backlight: use spin-lock to protect device list

From: David Herrmann 

There is really no reason to use a mutex to protect a simple list. Convert
the list-lock to a simple spinlock instead.

The spin-locks prepare for a backlight_find() helper, which should
preferably be usable from atomic context. A mutex would prevent that, so
use an irq-save spinlock instead.

Signed-off-by: David Herrmann 
---
 drivers/video/backlight/backlight.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 37f6173..716c091 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -16,13 +16,14 @@
 #include 
 #include 
 #include 
+#include 

 #ifdef CONFIG_PMAC_BACKLIGHT
 #include 
 #endif

 static LIST_HEAD(backlight_dev_list);
-static DEFINE_MUTEX(backlight_dev_list_mutex);
+static DEFINE_SPINLOCK(backlight_dev_list_lock);
 static BLOCKING_NOTIFIER_HEAD(backlight_notifier);

 static const char *const backlight_types[] = {
@@ -378,9 +379,9 @@ struct backlight_device *backlight_device_register(const 
char *name,
mutex_unlock(&pmac_backlight_mutex);
 #endif

-   mutex_lock(&backlight_dev_list_mutex);
+   spin_lock_irq(&backlight_dev_list_lock);
list_add(&new_bd->entry, &backlight_dev_list);
-   mutex_unlock(&backlight_dev_list_mutex);
+   spin_unlock_irq(&backlight_dev_list_lock);

blocking_notifier_call_chain(&backlight_notifier,
 BACKLIGHT_REGISTERED, new_bd);
@@ -393,15 +394,16 @@ struct backlight_device 
*backlight_device_get_by_type(enum backlight_type type)
 {
bool found = false;
struct backlight_device *bd;
+   unsigned long flags;

-   mutex_lock(&backlight_dev_list_mutex);
+   spin_lock_irqsave(&backlight_dev_list_lock, flags);
list_for_each_entry(bd, &backlight_dev_list, entry) {
if (bd->props.type == type) {
found = true;
break;
}
}
-   mutex_unlock(&backlight_dev_list_mutex);
+   spin_unlock_irqrestore(&backlight_dev_list_lock, flags);

return found ? bd : NULL;
 }
@@ -418,9 +420,9 @@ void backlight_device_unregister(struct backlight_device 
*bd)
if (!bd)
return;

-   mutex_lock(&backlight_dev_list_mutex);
+   spin_lock_irq(&backlight_dev_list_lock);
list_del(&bd->entry);
-   mutex_unlock(&backlight_dev_list_mutex);
+   spin_unlock_irq(&backlight_dev_list_lock);

 #ifdef CONFIG_PMAC_BACKLIGHT
mutex_lock(&pmac_backlight_mutex);
-- 
2.9.3

[PATCH 3/6] backlight: add kernel-internal backlight API

From: David Herrmann 

So far backlights have only been controlled via sysfs. However, sysfs is
not a proper user-space API for runtime modifications, and never was
intended to provide such. The DRM drivers are now prepared to provide
such a backlight link so user-space can control backlight via DRM
connector properties. This allows us to employ the same access-management
we use for mode-setting.

This patch adds few kernel-internal backlight helpers so we can modify
backlights from within DRM.

Signed-off-by: David Herrmann 
---
 drivers/video/backlight/backlight.c | 65 +
 include/linux/backlight.h   | 16 +
 2 files changed, 81 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 716c091..c7b335c 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -489,6 +489,71 @@ int backlight_unregister_notifier(struct notifier_block 
*nb)
 EXPORT_SYMBOL(backlight_unregister_notifier);

 /**
+ * backlight_device_lookup - find a backlight device
+ * @name: sysname of the backlight device
+ *
+ * @return Reference to the backlight device, NULL if not found.
+ *
+ * This searches through all registered backlight devices for a device with the
+ * given device name. In case none is found, NULL is returned, otherwise a
+ * new reference to the backlight device is returned. You must drop this
+ * reference via backlight_device_unref() once done.
+ * Note that the devices might get unregistered at any time. You need to lock
+ * around this lookup and inside of your backlight-notifier if you need to know
+ * when a device gets unregistered.
+ *
+ * This function can be safely called from IRQ context.
+ */
+struct backlight_device *backlight_device_lookup(const char *name)
+{
+   struct backlight_device *bd;
+   unsigned long flags;
+   const char *t;
+
+   spin_lock_irqsave(&backlight_dev_list_lock, flags);
+
+   list_for_each_entry(bd, &backlight_dev_list, entry) {
+   t = dev_name(&bd->dev);
+   if (t && !strcmp(t, name))
+   goto out;
+   }
+
+   bd = NULL;
+
+out:
+   spin_unlock_irqrestore(&backlight_dev_list_lock, flags);
+   backlight_device_ref(bd);
+   return bd;
+}
+EXPORT_SYMBOL_GPL(backlight_device_lookup);
+
+/**
+ * backlight_set_brightness - set brightness on a backlight device
+ * @bd: backlight device to operate on
+ * @value: brightness value to set on the device
+ * @reason: backlight-change reason to use for notifications
+ *
+ * This is the in-kernel API equivalent of writing into the 'brightness' sysfs
+ * file. It calls into the underlying backlight driver to change the brightness
+ * value. The value is clamped according to device bounds.
+ * A uevent notification is sent with the reason set to @reason.
+ */
+void backlight_set_brightness(struct backlight_device *bd, unsigned int value,
+ enum backlight_update_reason reason)
+{
+   mutex_lock(&bd->ops_lock);
+   if (bd->ops) {
+   value = clamp(value, 0U, (unsigned)bd->props.max_brightness);
+   pr_debug("set brightness to %u\n", value);
+   bd->props.brightness = value;
+   backlight_update_status(bd);
+   }
+   mutex_unlock(&bd->ops_lock);
+   backlight_generate_event(bd, reason);
+}
+EXPORT_SYMBOL_GPL(backlight_set_brightness);
+
+/**
  * devm_backlight_device_register - resource managed 
backlight_device_register()
  * @dev: the device to register
  * @name: the name of the device
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f2fd61..895c4661 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -146,6 +146,22 @@ extern int backlight_unregister_notifier(struct 
notifier_block *nb);
 extern struct backlight_device *backlight_device_get_by_type(enum 
backlight_type type);
 extern int backlight_device_set_brightness(struct backlight_device *bd, 
unsigned long brightness);

+struct backlight_device *backlight_device_lookup(const char *name);
+void backlight_set_brightness(struct backlight_device *bd, unsigned int value,
+ enum backlight_update_reason reason);
+
+static inline void backlight_device_ref(struct backlight_device *bd)
+{
+   if (bd)
+   get_device(&bd->dev);
+}
+
+static inline void backlight_device_unref(struct backlight_device *bd)
+{
+   if (bd)
+   put_device(&bd->dev);
+}
+
 #define to_backlight_device(obj) container_of(obj, struct backlight_device, 
dev)

 static inline void * bl_get_data(struct backlight_device *bl_dev)
-- 
2.9.3

[PATCH 4/6] drm: link connectors to backlight devices

From: David Herrmann 

Backlight devices have always been managed independently of display
controllers. They're often controlled via different hardware interfaces
and their relationship to display-controllers varies vastly between
different boards. However, display brightness is obviously a property of
a display, and thus of a DRM connector. Therefore, it'd be really
appreciated if user-space APIs would highlight this relationship.

The main runtime users of backlight interfaces are user-space compositors.
But currently they have to jump through hoops to find the correct
backlight device for a given connector. Furthermore, they need root
privileges to write to sysfs. sysfs has never been designed as run-time
non-root API. It does not provide file-contexts, run-time management or
any kind of API control. There is no way to control access to sysfs via
different links (in that case: mounts). Char-devs provide all this!

So far, backlight APIs have been fairly trivial, so adding char-devs to
backlights is rather heavy-weight. Therefore, this patch introduces a new
API interface to modify backlight brightness via DRM: A "BRIGHTNESS"
property on DRM connectors.

Instead of adding backlight hardware support to DRM, we rely on the
backlight-class and simply add a new API. Each DRM Connector can
optionally be linked to a backlight class device. Modifying the connector
property will have the same effect as writing into the "brightness" sysfs
file of the linked backlight class device. However, we now can manage
access to backlight devices via the same interface as access to
mode-setting on the underlying display. Furthermore, the connection
between displays and their backlight devices are visible in user-space.

Obviously, matching backlights to displays cannot be solved magically
with this link. Therefore, we also add a user-space attribute to DRM
connectors called 'backlight'. If a DRM driver is incapable of matching
existing backlights to a connector, or if a given board has just crappy
backlight drivers, udev can write the name of a backlight-device into this
attribute and the connector-property will be re-linked to this backlight
device. The udev hwdb can be easily employed to track such quirks and
fixups for different board+GPU combinations.
Note that the name written into the 'backlight' attribute is saved on the
connector, so in case the real backlight device is probed after the DRM
card, the backlight will still get properly attached once probed.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_backlight.c | 387 
 drivers/gpu/drm/drm_connector.c |  11 +
 drivers/gpu/drm/drm_crtc.c  |   6 +
 drivers/gpu/drm/drm_drv.c   |   8 +
 drivers/gpu/drm/drm_sysfs.c |  54 +
 drivers/video/backlight/backlight.c |   3 +
 include/drm/drm_backlight.h |  44 
 include/drm/drm_connector.h |   3 +
 include/drm/drm_crtc.h  |   5 +
 include/linux/backlight.h   |   1 +
 12 files changed, 524 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_backlight.c
 create mode 100644 include/drm/drm_backlight.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 483059a..1ce6a1c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select BACKLIGHT_CLASS_DEVICE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 74579d2..f016847 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -15,7 +15,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
-   drm_plane.o drm_color_mgmt.o
+   drm_plane.o drm_color_mgmt.o drm_backlight.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_backlight.c b/drivers/gpu/drm/drm_backlight.c
new file mode 100644
index 000..92d231a
--- /dev/null
+++ b/drivers/gpu/drm/drm_backlight.c
@@ -0,0 +1,387 @@
+/*
+ * DRM Backlight Helpers
+ * Copyright (c) 2014 David Herrmann
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: Backlight Devices
+ *
+ * Backlight devices have always been managed as a separate subsystem,
+ * independent of DRM. They are usually controlled via separate hardware
+ * interfaces than the display controller, so the split works out fin

[PATCH 6/6] drm: drm_backlight use the connect value to set brightness property

The brightness property was set with the incoming value
instead of the calculated value.

Signed-off-by: Marta Lofstedt 
---
 drivers/gpu/drm/drm_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_backlight.c b/drivers/gpu/drm/drm_backlight.c
index 92d231a..e73ec8e 100644
--- a/drivers/gpu/drm/drm_backlight.c
+++ b/drivers/gpu/drm/drm_backlight.c
@@ -132,7 +132,7 @@ static void __drm_backlight_real_changed(struct 
drm_backlight *b, uint64_t v)
set = div_u64(v << 16, max);

drm_object_property_set_value(&b->connector->base,
- config->brightness_property, v);
+ config->brightness_property, set);
 }

 /* caller must hold @drm_backlight_lock */
-- 
2.9.3

[PATCH 5/6] i915: Use drm backlight

Use the drm backlight class.

Signed-off-by: Marta Lofstedt 
---
 drivers/gpu/drm/i915/intel_panel.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index be4b4d5..0765b4c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include "intel_drv.h"
+#include 

 #define CRC_PMIC_PWM_PERIOD_NS 21333

@@ -1720,6 +1721,10 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector, enum pipe pipe)

panel->backlight.present = true;

+   /* This connector has backlight attached */
+   if (!drm_backlight_alloc(connector))
+   drm_backlight_set_name(connector->backlight, "intel_backlight");
+
DRM_DEBUG_KMS("Connector %s backlight initialized, %s, brightness 
%u/%u\n",
  connector->name,
  panel->backlight.enabled ? "enabled" : "disabled",
-- 
2.9.3

[Bug 178421] [regression] Radeon Oops on shutdown

2016-10-24 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=178421

--- Comment #3 from Jouni MettÃ¤lÃ¤  ---
Created attachment 242511
  --> https://bugzilla.kernel.org/attachment.cgi?id=242511&action=edit
recent picture of panic

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm: convert DT component matching to component_match_add_release()

2016-10-24 Thread Jyri Sarha

On 10/19/16 13:28, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
> 
> Signed-off-by: Russell King 

Acked-by: Jyri Sarha 
Reviewed-by: Jyri Sarha 

However, the patch description is a bit brief. It took me this mail
thread to fully understand why simple comparison of pointer values may
cause problems if the of_node ref count goes to zero.

BR,
Jyri

> ---
> Can we please get this patch from May merged into the drm-misc or
> whatever trees so that we don't end up with conflicts?  I've no idea
> who looks after drm-misc, as they have _still_ failed to add
> themselves to MAINTAINERS.
> 
>  drivers/gpu/drm/arm/hdlcd_drv.c |  3 ++-
>  drivers/gpu/drm/arm/malidp_drv.c|  4 +++-
>  drivers/gpu/drm/armada/armada_drv.c |  2 +-
>  drivers/gpu/drm/drm_of.c| 28 
> +++--
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  5 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  7 ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  4 +++-
>  drivers/gpu/drm/msm/msm_drv.c   | 12 ++-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  6 --
>  drivers/gpu/drm/sti/sti_drv.c   |  5 +++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  3 ++-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c|  4 +++-
>  include/drm/drm_of.h| 12 +++
>  13 files changed, 73 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index fb6a418ce6be..6477d1a65266 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>   return -EAGAIN;
>   }
>  
> - component_match_add(&pdev->dev, &match, compare_dev, port);
> + drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> + of_node_put(port);
>  
>   return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>  match);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358b8f15..9f4739452a25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device 
> *pdev)
>   return -EAGAIN;
>   }
>  
> - component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
> + drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
> +port);
> + of_node_put(port);
>   return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>  match);
>  }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 1e0e68f608e4..94e46da9a758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>   continue;
>   }
>  
> - component_match_add(dev, match, compare_of, remote);
> + drm_of_component_match_add(dev, match, compare_of, remote);
>   of_node_put(remote);
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index bc98bb94264d..47848ed8ca48 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -6,6 +6,11 @@
>  #include 
>  #include 
>  
> +static void drm_release_of(struct device *dev, void *data)
> +{
> + of_node_put(data);
> +}
> +
>  /**
>   * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>   * @dev: DRM device
> @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>  
>  /**
> + * drm_of_component_match_add - Add a component helper OF node match rule
> + * @master: master device
> + * @matchptr: component match pointer
> + * @compare: compare function used for matching component
> + * @node: of_node
> + */
> +void drm_of_component_match_add(struct device *master,
> + struct component_match **matchptr,
> + int (*compare)(struct device *, void *),
> + struct device_node *node)
> +{
> + of_node_get(node);
> + component_match_add_release(master, matchptr, drm_release_of,
> + compare, node);
> +}
> +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
> +
> +/**
>   * drm_of_component_probe - Generic probe function for a component based 
> master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>   continue;

[Bug 178421] [regression] Radeon Oops on shutdown

2016-10-24 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=178421

--- Comment #4 from Jouni MettÃ¤lÃ¤  ---
I still get oops on 4.9-rc2. Picture is attached. It looks different than
already fixed bug, for me at least.

Kevin, you have probably different bug. Reboot doesn't work for me. What is
last known good kernel for you?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

2016-10-24 Thread Brian Starkey

Hi Russell,

On Sat, Oct 22, 2016 at 02:40:22PM +0100, Russell King - ARM Linux wrote:
>On Wed, Oct 19, 2016 at 10:46:48AM +0100, Brian Starkey wrote:
>> Hi Jyri,
>>
>> I believe this will break mali-dp and hdlcd, unless something changed
>> while I wasn't looking. Please see this previous thread where I did
>> the same thing and then had to have it reverted: [1]
>>
>> Before removing this, we need to refactor (at least) mali-dp and hdlcd
>> to move drm_dev_register() to the end of their ->bind() callback.
>>
>> That could be done without moving drm_dev_unregister() to the start
>> of ->unbind() if you really want to nuke the drm_connector_register()
>> call, but to maintain symmetry (and introduce correctness) I was
>> putting it off until I had a chance to remove drm_vblank_cleanup()
>> from drm_dev_unregister() (because [2]).
>
>So what is the status of this - when is it going to happen?  Without
>this happening, I can't de-midlayer armada-drm, and I can't apply
>these TDA998x patches.
>
>As armada-drm stands at the moment, it can cope with the TDA998x
>driver having the drm_connector_register(), or with it eliminated.
>When armada-drm is de-midlayered without changing TDA998x, the
>drm_connector_register() call in TDA998x produces a warning:
>
>WARNING: CPU: 0 PID: 13 at lib/kobject.c:244 kobject_add_internal+0xfc/0x2d8
>kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
>
>I suspect that you will end up with the same problem when you move
>the drm_dev_register() call after component_bind_all() - and I think
>the answer is... you shouldn't have de-midlayered until TDA998x had
>been updated to cope with de-midlayering, iow having had the
>drm_connector_register() call removed.
>

Well technically neither hdlcd or mali-dp ever had a midlayer, but yes
it would have been nice to have never introduced this problem in the
first place, I agree.

>Given that, I don't think we can avoid breaking mali-dp and hdlcd,
>except by combining the change into a single patch, changing all three
>drivers simultaneously (and any other driver which uses TDA998x which
>has also been de-midlayered.)
>

There is a way - we can explicitly register the connectors in hdlcd
and mali-dp (drm_connector_register_all used to be exposed for that
job, afaik to work around the kind of issue we face here).

But, that would introduce some extra churn, so probably a single patch
for all three works just fine.

I couldn't spot any other drivers I think will be affected. tilcdc
isn't de-midlayered.

>So, what I would like to see is a single patch against Linus' 4.8.0
>commit fixing mali-dp, hdlcd and any other driver, together with
>removing drm_connector_register() from TDA998x.  This is so the patch
>can be shared between all interested parties without forcing everyone
>to 4.9-rc1.  Looking at the diff between 4.8 and 4.9-rc1 for
>drivers/gpu/drm/arm, that shouldn't result in any merge conflicts -
>and if you want to follow on from that with 4.9-rc1 development, you
>can always merge 4.9-rc1 on top of that commit.
>
>I'm happy to take such a patch and publish it via my git tree as part
>of the TDA998x development if that helps - but either way we need it
>shared between all parties.

OK, I will follow up to this email with that patch. I note that it
will conflict with the series you sent out yesterday (23rd October).

Hopefully that's an agreeable solution for you, and everyone else.

Thanks,
-Brian

>
>-- 
>RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
>according to speedtest.net.
>

[PATCH] drm/i2c/tda998x: mark symbol static where possible

On Mon, Oct 24, 2016 at 12:14:14PM +0200, Arnd Bergmann wrote:
> On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> > We get 1 warning when building kernel with W=1:
> > drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype 
> > for 'tda998x_audio_digital_mute' [-Wmissing-prototypes]
> > 
> > In fact, this function is only used in the file in which it is
> > declared and don't need a declaration, but can be made static.
> > So this patch marks this function with 'static'.
> > 
> > Signed-off-by: Baoyou Xie 
> > 
> 
> Reviewed-by: Arnd Bergmann 

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

2016-10-24 Thread Brian Starkey

Connectors shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.

As such, remove the calls to drm_connector_register() and
drm_connector_unregister() from tda998x, as these are now handled by
drm_dev_(un)register() itself.

To work with this change, the mali-dp and hdlcd bind and unbind
sequences have to be reordered, to ensure that the componentised
encoder/connector is bound before drm_dev_register() registers all
connectors. Similarly, the device must be unregistered before the
component is unbound.

Altogether, this allows other drivers using tda998x to be
de-midlayered, and to have less racy initialisation of their components.

Splitting this commit into three (one per driver) isn't possible without
intermediate breakage, so it is all squashed together here.

Suggested-by: Russell King 
Signed-off-by: Brian Starkey 
Reviewed-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/hdlcd_drv.c   |   19 +++
 drivers/gpu/drm/arm/malidp_drv.c  |   18 +++---
 drivers/gpu/drm/i2c/tda998x_drv.c |8 
 3 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index d83b46a..85aec8b 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -337,14 +337,10 @@ static int hdlcd_drm_bind(struct device *dev)
if (ret)
goto err_free;

-   ret = drm_dev_register(drm, 0);
-   if (ret)
-   goto err_unload;
-
ret = component_bind_all(dev, drm);
if (ret) {
DRM_ERROR("Failed to bind all components\n");
-   goto err_unregister;
+   goto err_unload;
}

ret = pm_runtime_set_active(dev);
@@ -371,8 +367,17 @@ static int hdlcd_drm_bind(struct device *dev)
goto err_fbdev;
}

+   ret = drm_dev_register(drm, 0);
+   if (ret)
+   goto err_register;
+
return 0;

+err_register:
+   if (hdlcd->fbdev) {
+   drm_fbdev_cma_fini(hdlcd->fbdev);
+   hdlcd->fbdev = NULL;
+   }
 err_fbdev:
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
@@ -381,8 +386,6 @@ err_vblank:
pm_runtime_disable(drm->dev);
 err_pm_active:
component_unbind_all(dev, drm);
-err_unregister:
-   drm_dev_unregister(drm);
 err_unload:
drm_irq_uninstall(drm);
of_reserved_mem_device_release(drm->dev);
@@ -398,6 +401,7 @@ static void hdlcd_drm_unbind(struct device *dev)
struct drm_device *drm = dev_get_drvdata(dev);
struct hdlcd_drm_private *hdlcd = drm->dev_private;

+   drm_dev_unregister(drm);
if (hdlcd->fbdev) {
drm_fbdev_cma_fini(hdlcd->fbdev);
hdlcd->fbdev = NULL;
@@ -411,7 +415,6 @@ static void hdlcd_drm_unbind(struct device *dev)
pm_runtime_disable(drm->dev);
of_reserved_mem_device_release(drm->dev);
drm_mode_config_cleanup(drm);
-   drm_dev_unregister(drm);
drm_dev_unref(drm);
drm->dev_private = NULL;
dev_set_drvdata(dev, NULL);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82171d2..79bfc13 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -354,10 +354,6 @@ static int malidp_bind(struct device *dev)
if (ret < 0)
goto init_fail;

-   ret = drm_dev_register(drm, 0);
-   if (ret)
-   goto register_fail;
-
/* Set the CRTC's port so that the encoder component can find it */
ep = of_graph_get_next_endpoint(dev->of_node, NULL);
if (!ep) {
@@ -394,8 +390,18 @@ static int malidp_bind(struct device *dev)
}

drm_kms_helper_poll_init(drm);
+
+   ret = drm_dev_register(drm, 0);
+   if (ret)
+   goto register_fail;
+
return 0;

+register_fail:
+   if (malidp->fbdev) {
+   drm_fbdev_cma_fini(malidp->fbdev);
+   malidp->fbdev = NULL;
+   }
 fbdev_fail:
drm_vblank_cleanup(drm);
 vblank_fail:
@@ -407,8 +413,6 @@ bind_fail:
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
 port_fail:
-   drm_dev_unregister(drm);
-register_fail:
malidp_de_planes_destroy(drm);
drm_mode_config_cleanup(drm);
 init_fail:
@@ -431,6 +435,7 @@ static void malidp_unbind(struct device *dev)
struct malidp_drm *malidp = drm->dev_private;
struct malidp_hw_device *hwdev = malidp->dev;

+   drm_dev_unregister(drm);
if (malidp->fbdev) {
drm_fbdev_cma_fini(malidp->fbdev);
malidp->fbdev = NULL;
@@ -442,7 +447,6 @@ static void malidp_unbind(struct device *dev)
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-   drm_dev_unregister(drm);
malidp_de_planes_destro

[PATCH 1/2] drm/msm: add missing header dependencies