date:20160412

[PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

2016-04-12 Thread Stefan Agner

On 2016-04-11 18:38, Shawn Guo wrote:
> On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
>> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
>> mixes the bus clock with the display controllers pixel clock. Tests
>> have shown that the gates in CCM_CCGR3/9 registers do not control
>> the DCU pixel clock, but only the register access clock (bus clock).
>>
>> Fix this by defining the parent clock of VF610_CLK_DCUx to be the bus
>> clock (ipg_bus).
>>
>> Since the clock has not been used far, there are no further changes
>> needed.
>>
>> Signed-off-by: Stefan Agner 
> 
> Applied 1 and 2, with updating subject prefix to be 'clk: imx: vf610: '

Thanks Shawn. Applied 3~6 in my FSL DCU tree. I guess 7~9 should go
through your tree as well?

--
Stefan


>> ---
>>  drivers/clk/imx/clk-vf610.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
>> index 0a94d96..426fde2 100644
>> --- a/drivers/clk/imx/clk-vf610.c
>> +++ b/drivers/clk/imx/clk-vf610.c
>> @@ -321,11 +321,11 @@ static void __init vf610_clocks_init(struct 
>> device_node *ccm_node)
>>  clk[VF610_CLK_DCU0_SEL] = imx_clk_mux("dcu0_sel", CCM_CSCMR1, 28, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU0_EN] = imx_clk_gate("dcu0_en", "dcu0_sel", 
>> CCM_CSCDR3, 19);
>>  clk[VF610_CLK_DCU0_DIV] = imx_clk_divider("dcu0_div", "dcu0_en", 
>> CCM_CSCDR3, 16, 3);
>> -clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "dcu0_div", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "ipg_bus", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>>  clk[VF610_CLK_DCU1_SEL] = imx_clk_mux("dcu1_sel", CCM_CSCMR1, 29, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU1_EN] = imx_clk_gate("dcu1_en", "dcu1_sel", 
>> CCM_CSCDR3, 23);
>>  clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", 
>> CCM_CSCDR3, 20, 3);
>> -clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "ipg_bus", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>>
>>  clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, 
>> esai_sels, 4);
>>  clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", 
>> CCM_CSCDR2, 30);
>> --
>> 2.7.4
>>
>>

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from John Galt  ---
I noticed something interesting: mpv was getting a reported refresh rate of
60.0hz in weston which is incorrect, actual display refresh rate is 59.951hz
(if I don't force it to 60.0hz as a workaround). In X, it gets the correct
refresh rate.

I was about to override the reported refresh rate to 59.951hz for mpv and play
a video without stutters, and without changing monitor's refresh rate.

weston-presentation-shm is also consistent with no vblank skips during playback
this way (at least with mpv playback). I suspect other applications are also
getting an incorrect reported refresh rate.

-- 
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/20160412/93ac/attachment.html>

[Bug 71789] [r300g] Visuals not found in (default) depth = 24

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

erhard_f at mailbox.org changed:

   What|Removed |Added

Version|11.1|11.2

--- Comment #12 from erhard_f at mailbox.org ---
Still here on mesa 11.2 (Ubuntu MATE 16.04 daily). Tested on a PowerMac G5 7,3.

-- 
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/20160412/753c3495/attachment-0001.html>

[Bug 94908] Powerplay for Topaz/Iceland chip

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 94908
   Summary: Powerplay for Topaz/Iceland chip
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: tomas.wilhelmsson at gmail.com

Need powerplay for topaz/iceland, is this being worked on? =)

-- 
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/20160412/95a62b15/attachment.html>

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Daniel Vetter

On Tue, Apr 12, 2016 at 06:16:54PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:58:11PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > Add support for the new family of Display Processors from ARM Ltd.
> > > This commit adds basic support for Mali DP500, DP550 and DP650
> > > parts, with only the display engine being supported at the moment.
> > > 
> > > Cc: David Brown 
> > > Cc: Brian Starkey 
> > > 
> > > Signed-off-by: Liviu Dudau 
> > 
> > Ok, on 2nd look something puzzling: Where are the
> > drm_encoder/drm_connectors in this driver? Somehow I think just these
> > parts here won't light up a lot ...
> 
> The magic of component based drivers, heh :)
> 
> On my test system I'm using the NXP TDA19988 HDMI and the driver works
> out of box once the DT describes the proper port/endpoint dance. For
> models/qemu style environment I have a generic DRM encoder driver that I'm
> going to post for review that only reads display timings from DT and behaves
> as if it connected to a real monitor.

I didn't know that magic worked so well already. Seriously impressed, and
happy that it doesn't take anything in addition to make it all just work.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Daniel Vetter

On Tue, Apr 12, 2016 at 06:13:49PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:47:57PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > +static int malidp_enable_vblank(struct drm_device *drm, unsigned int 
> > > crtc)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static void malidp_disable_vblank(struct drm_device *drm, unsigned int 
> > > pipe)
> > > +{
> > > +}
> > 
> > Might be worth it to create a patch for drm_irq.c to make
> > enable/disable_vblank functions optional. Otoh does your chip really keep
> > on generating vblank irqs all the time, with no way to shut it up? That
> > would be terrible for power consumption ... Especially since you have no
> > hw counter either.
> 
> Initially I had code here that was turning off the vblank irq, then I've read
> the comment in drmP.h that the routine should be a no-op when hardware 
> counters
> are missing, hence this version. As for the display processor: it will 
> generate
> an interrupt for every finished scanout cycle, but it has support for variable
> vsync. Interrupt can be disabled, but I've read in the drmP.h that it is 
> required
> for timestamping support when one doesn't have hw counters.
> 
> I'm OK with fixing drm_irq.c to not require enable/disable_vblank but then the
> comments in drmP.h will also have to change?

Nah, you bring up a good point actually - you really can't disable vblank
if there's no hw counter. At least not right now. I think dummy functions
in drm_irq.c like drm_vblank_get/set_no_hw_counter to make this clear
would be nice. Or maybe just a comment here.

The other option would be to finally fake this using high-precision
timestamps, since a lot of mobile hw seems to have forgotten to add a
proper vblank counter. But that has issues (it can drift), and probably
better done separately.

> > > +static void malidp_de_plane_disable(struct drm_plane *plane,
> > > + struct drm_plane_state *state)
> > > +{
> > > + struct malidp_plane *mp = to_malidp_plane(plane);
> > > +
> > > + /* ToDo: figure out the attached framebuffer lifecycle */
> > 
> > You don't need to figure this out, atomic helpers will take care of the fb
> > for you.
> 
> It is more in line with un/pinning the framebuffer and making sure that the
> framebuffer has been scanned out before unref-ing it.

That should be taken care of by the vblank wait the helpers do for you.
Again happans all automatically (except you need to keep that in mind for
the async work).

> Thanks again for finding time to review the code.

No problem.

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

[PATCH] drm/ttm: Fix TTM BO accounting

2016-04-12 Thread Thomas Hellstrom

On 04/12/2016 06:39 PM, Felix Kuehling wrote:
> This is the implementation of ttm_round_pot:
>
> size_t ttm_round_pot(size_t size)
> {
> if ((size & (size - 1)) == 0)
> return size;
> else if (size > PAGE_SIZE)
> return PAGE_ALIGN(size);
> else {
> size_t tmp_size = 4;
>
> while (tmp_size < size)
> tmp_size <<= 1;
>
> return tmp_size;
> }
> return 0;
> }
>
> As you can see, for size > PAGE_SIZE it just returns PAGE_ALIGN(size).
> It does not actually round to a power of two in this case.
>
> Regards,
>   Felix

Ah yes. I should've refreshed my memory.

Reviewed-by: Thomas Hellstrom 




>
> On 16-04-12 12:21 PM, Thomas Hellstrom wrote:
>> On 04/12/2016 05:57 PM, Alex Deucher wrote:
>>> From: Felix Kuehling 
>>>
>>> TTM BO accounting is out of sync with how memory is really allocated
>>> in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
>>> estimated overhead with many small allocations.
>>>
>>> ttm_dma_tt_alloc_page_directory makes a single allocation for three
>>> arrays: pages, DMA and CPU addresses. It uses drm_calloc_large, which
>>> uses kmalloc internally for allocations smaller than PAGE_SIZE.
>>> ttm_round_pot should be a good approximation of its memory usage both
>>> above and below PAGE_SIZE.
>> I think for allocations larger than PAGE_SIZE,
>> ttm_round_pot() will overestimate. You should probably use the smaller
>> of the two.
>>
>> /Thomas
>>
>>
>>
>>> Signed-off-by: Felix Kuehling 
>>> Reviewed-by: Monk Liu 
>>> Reviewed-by: Christian KÃ¶nig 
>>> ---
>>>  drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index 4cbf265..870a87a 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -1215,7 +1215,7 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>>> size_t size = 0;
>>>  
>>> size += ttm_round_pot(struct_size);
>>> -   size += PAGE_ALIGN(npages * sizeof(void *));
>>> +   size += ttm_round_pot(npages * sizeof(void *));
>>> size += ttm_round_pot(sizeof(struct ttm_tt));
>>> return size;
>>>  }
>>> @@ -1229,8 +1229,7 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>>> size_t size = 0;
>>>  
>>> size += ttm_round_pot(struct_size);
>>> -   size += PAGE_ALIGN(npages * sizeof(void *));
>>> -   size += PAGE_ALIGN(npages * sizeof(dma_addr_t));
>>> +   size += ttm_round_pot(npages * (2*sizeof(void *) + sizeof(dma_addr_t)));
>>> size += ttm_round_pot(sizeof(struct ttm_dma_tt));
>>> return size;
>>>  }

[PATCH] drm/msm/mdp: Add support for more RGBX formats

2016-04-12 Thread Archit Taneja



On 04/12/2016 04:53 AM, Rob Herring wrote:
> Android needs XBGR format. Add all the missing 32-bpp formats
> without alpha for completeness.
>

Reviewed-by: Archit Taneja  

> Cc: Archit Taneja 
> Cc: Rob Clark 
> Signed-off-by: Rob Herring 
> ---
>   drivers/gpu/drm/msm/mdp/mdp_format.c | 6 ++
>   1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp_format.c 
> b/drivers/gpu/drm/msm/mdp/mdp_format.c
> index 1c2caff..b4a8aa4 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp_format.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp_format.c
> @@ -105,6 +105,12 @@ static const struct mdp_format formats[] = {
>   MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
>   FMT(XRGB, 8, 8, 8, 8,  1, 0, 2, 3,  false,  true,  4,  4,
>   MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
> + FMT(XBGR, 8, 8, 8, 8,  2, 0, 1, 3,  false,   true,  4,  4,
> + MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
> + FMT(RGBX, 8, 8, 8, 8,  3, 1, 0, 2,  false,   true,  4,  4,
> + MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
> + FMT(BGRX, 8, 8, 8, 8,  3, 2, 0, 1,  false,   true,  4,  4,
> + MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
>   FMT(RGB888,   0, 8, 8, 8,  1, 0, 2, 0,  false,  true,  3,  3,
>   MDP_PLANE_INTERLEAVED, CHROMA_FULL, false),
>   FMT(BGR888,   0, 8, 8, 8,  2, 0, 1, 0,  false,  true,  3,  3,
>

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

[PATCH] drm/ttm: Fix TTM BO accounting

2016-04-12 Thread Thomas Hellstrom

On 04/12/2016 05:57 PM, Alex Deucher wrote:
> From: Felix Kuehling 
>
> TTM BO accounting is out of sync with how memory is really allocated
> in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
> estimated overhead with many small allocations.
>
> ttm_dma_tt_alloc_page_directory makes a single allocation for three
> arrays: pages, DMA and CPU addresses. It uses drm_calloc_large, which
> uses kmalloc internally for allocations smaller than PAGE_SIZE.
> ttm_round_pot should be a good approximation of its memory usage both
> above and below PAGE_SIZE.

I think for allocations larger than PAGE_SIZE,
ttm_round_pot() will overestimate. You should probably use the smaller
of the two.

/Thomas



>
> Signed-off-by: Felix Kuehling 
> Reviewed-by: Monk Liu 
> Reviewed-by: Christian KÃ¶nig 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 4cbf265..870a87a 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1215,7 +1215,7 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>   size_t size = 0;
>  
>   size += ttm_round_pot(struct_size);
> - size += PAGE_ALIGN(npages * sizeof(void *));
> + size += ttm_round_pot(npages * sizeof(void *));
>   size += ttm_round_pot(sizeof(struct ttm_tt));
>   return size;
>  }
> @@ -1229,8 +1229,7 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>   size_t size = 0;
>  
>   size += ttm_round_pot(struct_size);
> - size += PAGE_ALIGN(npages * sizeof(void *));
> - size += PAGE_ALIGN(npages * sizeof(dma_addr_t));
> + size += ttm_round_pot(npages * (2*sizeof(void *) + sizeof(dma_addr_t)));
>   size += ttm_round_pot(sizeof(struct ttm_dma_tt));
>   return size;
>  }

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Liviu Dudau

On Tue, Apr 12, 2016 at 05:58:11PM +0200, Daniel Vetter wrote:
> On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display engine being supported at the moment.
> > 
> > Cc: David Brown 
> > Cc: Brian Starkey 
> > 
> > Signed-off-by: Liviu Dudau 
> 
> Ok, on 2nd look something puzzling: Where are the
> drm_encoder/drm_connectors in this driver? Somehow I think just these
> parts here won't light up a lot ...

The magic of component based drivers, heh :)

On my test system I'm using the NXP TDA19988 HDMI and the driver works
out of box once the DT describes the proper port/endpoint dance. For
models/qemu style environment I have a generic DRM encoder driver that I'm
going to post for review that only reads display timings from DT and behaves
as if it connected to a real monitor.

Best regards,
Liviu

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/arm/Kconfig |  15 +
> >  drivers/gpu/drm/arm/Makefile|   2 +
> >  drivers/gpu/drm/arm/malidp_crtc.c   | 276 +
> >  drivers/gpu/drm/arm/malidp_drv.c| 486 ++
> >  drivers/gpu/drm/arm/malidp_drv.h|  49 +++
> >  drivers/gpu/drm/arm/malidp_hw.c | 777 
> > 
> >  drivers/gpu/drm/arm/malidp_hw.h | 192 +
> >  drivers/gpu/drm/arm/malidp_planes.c | 342 
> >  drivers/gpu/drm/arm/malidp_regs.h   | 172 
> >  9 files changed, 2311 insertions(+)
> >  create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
> > 
> > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> > index eaed454..e5b5b6b 100644
> > --- a/drivers/gpu/drm/arm/Kconfig
> > +++ b/drivers/gpu/drm/arm/Kconfig
> > @@ -25,3 +25,18 @@ config DRM_HDLCD_SHOW_UNDERRUN
> >   Enable this option to show in red colour the pixels that the
> >   HDLCD device did not fetch from framebuffer due to underrun
> >   conditions.
> > +
> > +config DRM_MALI_DISPLAY
> > +   tristate "ARM Mali Display Processor"
> > +   depends on DRM && OF && (ARM || ARM64)
> > +   depends on COMMON_CLK
> > +   select DRM_ARM
> > +   select DRM_KMS_HELPER
> > +   select DRM_KMS_CMA_HELPER
> > +   select DRM_GEM_CMA_HELPER
> > +   select VIDEOMODE_HELPERS
> > +   help
> > + Choose this option if you want to compile the ARM Mali Display
> > + Processor driver. It supports all the variants of the hardware.
> > +
> > + If compiled as a module it will be called malidp.
> > diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> > index 89dcb7b..3e76e6c 100644
> > --- a/drivers/gpu/drm/arm/Makefile
> > +++ b/drivers/gpu/drm/arm/Makefile
> > @@ -1,2 +1,4 @@
> >  hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
> >  obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
> > +malidp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> > +obj-$(CONFIG_DRM_MALI_DISPLAY) += malidp.o
> > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> > b/drivers/gpu/drm/arm/malidp_crtc.c
> > new file mode 100644
> > index 000..aa49fd4
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > @@ -0,0 +1,276 @@
> > +/*
> > + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> > + * Author: Liviu Dudau 
> > + *
> > + * This program is free software and is provided to you under the terms of 
> > the
> > + * GNU General Public License version 2 as published by the Free Software
> > + * Foundation, and any use by you of this program is subject to the terms
> > + * of such GNU licence.
> > + *
> > + * ARM Mali DP500/DP550/DP650 driver (crtc operations)
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "malidp_drv.h"
> > +#include "malidp_hw.h"
> > +
> > +static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> > +  const struct drm_display_mode *mode,
> > +  struct drm_display_mode *adjusted_mode)
> > +{
> > +   struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> > +   struct malidp_hw_device *hwdev = malidp->dev;
> > +
> > +   /*
> > +* check that the hardware can drive the required clock rate,
> > +* but skip the check if the clock is meant to be disabled (req_rate = 
> > 0)
> > +*/
> > +   long rate, req_rate = mode->crtc_clock * 1000;
> > +
> > +   if (req_rate) {
> > +   rate = clk_round_rate(hwdev->mclk, req_rate);
> > +   if (rate < req_rate) {
> > +   DRM_DEBUG_DRIVER("mclk clock unable to

[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88

2016-04-12 Thread Daniel Vetter

On Tue, Apr 12, 2016 at 12:57:45PM +, Hwang, Dongseong wrote:
> Follow-up of the kernel patch: 
> https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
> 
> The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
> with OpenGL shaders, importing the two source planes through
> EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
> R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
> 
> CC: Peter FrÃ¼hberger 
> Cc: Rainer Hochecker 
> Cc: Benjamin Widawsky 
> CC: Chad Versace 
> Signed-off-by: Dongseong Hwang 
> ---
>  include/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index e741b09..ca2f488 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -34,6 +34,13 @@
>  /* color index */
>  #define DRM_FORMAT_C8fourcc_code('C', '8', ' ', ' ') /* 
> [7:0] C */
>  
> +/* 8 bpp Red */
> +#define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
> +
> +/* 16 bpp RG */
> +#define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
> +#define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> -- 
> 2.5.0
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

You need to resend without this footer, otherwise I can't merge the patch.
-Daniel

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

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

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Liviu Dudau

On Tue, Apr 12, 2016 at 05:47:57PM +0200, Daniel Vetter wrote:
> On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display engine being supported at the moment.
> > 
> > Cc: David Brown 
> > Cc: Brian Starkey 
> > 
> > Signed-off-by: Liviu Dudau 
> 
> Quickly scrolled through it with an eye towards atomic. Looks real pretty,
> I think we're getting closer to the ideal world where a new atomic driver
> is just hw specific code plus minimal amounts of glue.
> 
> Bunch of comments inline below.

Thanks for reviewing this!

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/arm/Kconfig |  15 +
> >  drivers/gpu/drm/arm/Makefile|   2 +
> >  drivers/gpu/drm/arm/malidp_crtc.c   | 276 +
> >  drivers/gpu/drm/arm/malidp_drv.c| 486 ++
> >  drivers/gpu/drm/arm/malidp_drv.h|  49 +++
> >  drivers/gpu/drm/arm/malidp_hw.c | 777 
> > 
> >  drivers/gpu/drm/arm/malidp_hw.h | 192 +
> >  drivers/gpu/drm/arm/malidp_planes.c | 342 
> >  drivers/gpu/drm/arm/malidp_regs.h   | 172 
> >  9 files changed, 2311 insertions(+)
> >  create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
> >  create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
> > 
> > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> > index eaed454..e5b5b6b 100644
> > --- a/drivers/gpu/drm/arm/Kconfig
> > +++ b/drivers/gpu/drm/arm/Kconfig
> > @@ -25,3 +25,18 @@ config DRM_HDLCD_SHOW_UNDERRUN
> >   Enable this option to show in red colour the pixels that the
> >   HDLCD device did not fetch from framebuffer due to underrun
> >   conditions.
> > +
> > +config DRM_MALI_DISPLAY
> > +   tristate "ARM Mali Display Processor"
> > +   depends on DRM && OF && (ARM || ARM64)
> > +   depends on COMMON_CLK
> > +   select DRM_ARM
> > +   select DRM_KMS_HELPER
> > +   select DRM_KMS_CMA_HELPER
> > +   select DRM_GEM_CMA_HELPER
> > +   select VIDEOMODE_HELPERS
> > +   help
> > + Choose this option if you want to compile the ARM Mali Display
> > + Processor driver. It supports all the variants of the hardware.
> > +
> > + If compiled as a module it will be called malidp.
> > diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> > index 89dcb7b..3e76e6c 100644
> > --- a/drivers/gpu/drm/arm/Makefile
> > +++ b/drivers/gpu/drm/arm/Makefile
> > @@ -1,2 +1,4 @@
> >  hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
> >  obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
> > +malidp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> > +obj-$(CONFIG_DRM_MALI_DISPLAY) += malidp.o
> > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> > b/drivers/gpu/drm/arm/malidp_crtc.c
> > new file mode 100644
> > index 000..aa49fd4
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> > @@ -0,0 +1,276 @@
> > +/*
> > + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> > + * Author: Liviu Dudau 
> > + *
> > + * This program is free software and is provided to you under the terms of 
> > the
> > + * GNU General Public License version 2 as published by the Free Software
> > + * Foundation, and any use by you of this program is subject to the terms
> > + * of such GNU licence.
> > + *
> > + * ARM Mali DP500/DP550/DP650 driver (crtc operations)
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "malidp_drv.h"
> > +#include "malidp_hw.h"
> > +
> > +static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> > +  const struct drm_display_mode *mode,
> > +  struct drm_display_mode *adjusted_mode)
> > +{
> > +   struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> > +   struct malidp_hw_device *hwdev = malidp->dev;
> > +
> > +   /*
> > +* check that the hardware can drive the required clock rate,
> > +* but skip the check if the clock is meant to be disabled (req_rate = 
> > 0)
> > +*/
> > +   long rate, req_rate = mode->crtc_clock * 1000;
> > +
> > +   if (req_rate) {
> > +   rate = clk_round_rate(hwdev->mclk, req_rate);
> > +   if (rate < req_rate) {
> > +   DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
> > +mode->crtc_clock);
> > +   return false;
> > +   }
> > +
> > +   rate = clk_round_rate(hwdev->pxlclk, req_rate);
> > +   if (rate != req_rate) {
> > +

[PATCH RFC 04/11] drm/tilcdc: Add tilcdc_crtc_mode_set_nofb()

2016-04-12 Thread Daniel Vetter

On Mon, Apr 11, 2016 at 07:46:31PM +0300, Jyri Sarha wrote:
> Add tilcdc_crtc_mode_set_nofb(). The mode_set_nofb() semantics do not
> fit well to LCDC, because of the mandatory framebuffer. However, when
> the primary plane is required in the check phase, it and the
> framebuffer can be found from the atomic state struct.
> 
> Signed-off-by: Jyri Sarha 

Yeah, if your hw always requires a primary plane then 2 bits needed: a)
make sure in the crtc's atomic_check it's there and set b) just use the
hooks whoever you want to. Atomic allows planes to be entirely independent
of the display pipeline, but doesn't require it really.
-Daniel

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 172 
> +++
>  1 file changed, 172 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 919c901..35f5682 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -310,6 +310,177 @@ static void tilcdc_crtc_commit(struct drm_crtc *crtc)
>   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>  }
>  
> +static void tilcdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
> +{
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
> + const struct tilcdc_panel_info *info = tilcdc_crtc->info;
> + uint32_t reg, hbp, hfp, hsw, vbp, vfp, vsw;
> + struct drm_display_mode *mode = >state->adjusted_mode;
> + struct drm_framebuffer *fb = crtc->primary->state->fb;
> +
> + if (WARN_ON(!info))
> + return;
> +
> + if (WARN_ON(!fb))
> + return;
> +
> + pm_runtime_get_sync(dev->dev);
> +
> + /* Configure the Burst Size and fifo threshold of DMA: */
> + reg = tilcdc_read(dev, LCDC_DMA_CTRL_REG) & ~0x0770;
> + switch (info->dma_burst_sz) {
> + case 1:
> + reg |= LCDC_DMA_BURST_SIZE(LCDC_DMA_BURST_1);
> + break;
> + case 2:
> + reg |= LCDC_DMA_BURST_SIZE(LCDC_DMA_BURST_2);
> + break;
> + case 4:
> + reg |= LCDC_DMA_BURST_SIZE(LCDC_DMA_BURST_4);
> + break;
> + case 8:
> + reg |= LCDC_DMA_BURST_SIZE(LCDC_DMA_BURST_8);
> + break;
> + case 16:
> + reg |= LCDC_DMA_BURST_SIZE(LCDC_DMA_BURST_16);
> + break;
> + default:
> + dev_err(dev->dev, "invalid burst size\n");
> + return;
> + }
> + reg |= (info->fifo_th << 8);
> + tilcdc_write(dev, LCDC_DMA_CTRL_REG, reg);
> +
> + /* Configure timings: */
> + hbp = mode->htotal - mode->hsync_end;
> + hfp = mode->hsync_start - mode->hdisplay;
> + hsw = mode->hsync_end - mode->hsync_start;
> + vbp = mode->vtotal - mode->vsync_end;
> + vfp = mode->vsync_start - mode->vdisplay;
> + vsw = mode->vsync_end - mode->vsync_start;
> +
> + DBG("%dx%d, hbp=%u, hfp=%u, hsw=%u, vbp=%u, vfp=%u, vsw=%u",
> + mode->hdisplay, mode->vdisplay, hbp, hfp, hsw, vbp, vfp, vsw);
> +
> + /* Set AC Bias Period and Number of Transitions per Interrupt: */
> + reg = tilcdc_read(dev, LCDC_RASTER_TIMING_2_REG) & ~0x000fff00;
> + reg |= LCDC_AC_BIAS_FREQUENCY(info->ac_bias) |
> + LCDC_AC_BIAS_TRANSITIONS_PER_INT(info->ac_bias_intrpt);
> +
> + /*
> +  * subtract one from hfp, hbp, hsw because the hardware uses
> +  * a value of 0 as 1
> +  */
> + if (priv->rev == 2) {
> + /* clear bits we're going to set */
> + reg &= ~0x7833;
> + reg |= ((hfp-1) & 0x300) >> 8;
> + reg |= ((hbp-1) & 0x300) >> 4;
> + reg |= ((hsw-1) & 0x3c0) << 21;
> + }
> + tilcdc_write(dev, LCDC_RASTER_TIMING_2_REG, reg);
> +
> + reg = (((mode->hdisplay >> 4) - 1) << 4) |
> + (((hbp-1) & 0xff) << 24) |
> + (((hfp-1) & 0xff) << 16) |
> + (((hsw-1) & 0x3f) << 10);
> + if (priv->rev == 2)
> + reg |= (((mode->hdisplay >> 4) - 1) & 0x40) >> 3;
> + tilcdc_write(dev, LCDC_RASTER_TIMING_0_REG, reg);
> +
> + reg = ((mode->vdisplay - 1) & 0x3ff) |
> + ((vbp & 0xff) << 24) |
> + ((vfp & 0xff) << 16) |
> + (((vsw-1) & 0x3f) << 10);
> + tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);
> +
> + /*
> +  * be sure to set Bit 10 for the V2 LCDC controller,
> +  * otherwise limited to 1024 pixels width, stopping
> +  * 1920x1080 being supported.
> +  */
> + if (priv->rev == 2) {
> + if ((mode->vdisplay - 1) & 0x400) {
> + tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG,
> + LCDC_LPP_B10);
> + } else {
> + tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG,
> + LCDC_LPP_B10);
> + }
> + }
> +
> + /* Configure display type:

[PATCH v8 00/10] Add DRM Driver for HiSilicon Kirin hi6220 SoC

2016-04-12 Thread Daniel Vetter

On Mon, Apr 11, 2016 at 04:55:33PM +0800, Xinliang Liu wrote:
> This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
> Current testing and support board is Hikey board which is one of Linaro
> 96boards. It is an arm64 open source board. For more information about
> this board, please access https://www.96boards.org.
> 
> Hardware Detail
> ---
>   The display subsystem of Hi6220 SoC is shown as bellow:
>  +-+   +--+ +-+ +-+
>  | |   |  | | | | |   
>  | FB  |-->|   ADE|>| DSI |>|   External  |
>  | |   |  | | | |  HDMI/panel |
>  +-+   +--+ +-+ +-+
> 
> - ADE(Advanced Display Engine) is the display controller. It contains 7
> channels, 3 overlay compositors and a LDI.
>   - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
>   - Overlay compositor is response to compose planes which come from 7
>   channels and pass composed image to LDI.
>   - LDI is response to generate timings and RGB data stream.
> - DSI converts the RGB data stream from ADE to DSI packets.
> - External HDMI/panel module is connected with DSI bus. Now Hikey use a
>   ADI's ADV7533 external HDMI chip.

I haven't looked at the details again, but seems it's all ready. Please
create a pull request for the entire pile against drm-next and submit it
to Dave Airlie.

Thanks, Daniel

> 
> Change History
> -
> Changes in v8:
> - Rebase to v4.6-rc3
> 
> Changes in v7:
> - Add config.mutex protection when accessing mode_config.connector_list.
> - Clean up match data getting of kirin_drm_drv.c.
> - A few Regs define clean up and typo fixs for ADE crtc and DSI encoder
>   driver.
> - Fix vblank irq flag "DRIVER_IRQF_SHARED" to "IRQF_SHARED".
> 
> Changes in v6:
> - Cleanup values part of reg and clocks relevant properties.
> - Change "pclk_dsi" clock name to "pclk".
> 
> Changes in v5:
> - Remove endpoint unit address of dsi output port.
> - Use syscon to access ADE media NOC QoS registers instread of directly
>   writing registers.
> - Use reset controller to reset ADE instead of directly writing registers.
> 
> Changes in v4:
> - Describe more specific of clocks and ports of binding docs.
> - Fix indentation of binding docs.
> 
> Changes in v3:
> - Move and rename all the files to kirin sub-directory.
>   So that we could separate different seires SoCs' driver.
> - Make ade as the drm master node.
> - Replace drm_platform_init, load, unload implementation.
> - Use assigned-clocks to set clock rate.
> - Use ports to connect display relevant nodes.
> - Rename hisi_drm_dsi.c to dw_drm_dsi.c
> - Make encoder type as DRM_MODE_ENCODER_DSI.
> - A few cleanup on regs and code.
> 
> Changes in v2:
> - Remove abtraction layer of plane/crtc/encoder/connector.
> - Refactor atomic implementation according to Daniel Vetter's guides:
> http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
> http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
> http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
> - Use bridge instead of slave encoder to connect external HDMI.
> - Move dt binding docs to bindings/display/hisilicon directory.
> 
> Xinliang Liu (10):
>   drm/hisilicon: Add device tree binding for hi6220 display subsystem
>   drm/hisilicon: Add hisilicon kirin drm master driver
>   drm/hisilicon: Add crtc driver for ADE
>   drm/hisilicon: Add plane driver for ADE
>   drm/hisilicon: Add vblank driver for ADE
>   drm/hisilicon: Add cma fbdev and hotplug
>   drm/hisilicon: Add designware dsi encoder driver
>   drm/hisilicon: Add designware dsi host driver
>   drm/hisilicon: Add support for external bridge
>   MAINTAINERS: Add maintainer for hisilicon DRM driver
> 
>  .../bindings/display/hisilicon/dw-dsi.txt  |   72 ++
>  .../bindings/display/hisilicon/hisi-ade.txt|   64 ++
>  MAINTAINERS|   10 +
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/hisilicon/Kconfig  |5 +
>  drivers/gpu/drm/hisilicon/Makefile |5 +
>  drivers/gpu/drm/hisilicon/kirin/Kconfig|   10 +
>  drivers/gpu/drm/hisilicon/kirin/Makefile   |5 +
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |  857 
>  drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h   |  103 ++
>  drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h|  230 +
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1057 
> 
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  367 +++
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h|   31 +
>  15 files changed, 2819 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>  create mode

[PATCH] drm: atomic: fix legacy gamma set helper

2016-04-12 Thread Daniel Vetter

On Tue, Apr 12, 2016 at 01:51:02PM +0100, Lionel Landwerlin wrote:
> On 12/04/16 12:57, Daniel Vetter wrote:
> >On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> >>Color management properties are a bit of an odd use case because
> >>they're not marked as atomic properties. Currently we're not updating
> >>the non atomic values so the drm_crtc_state is out of sync with the
> >>values stored in the crtc object.
> >tbh sounds like this is the bug here - why does the lookup of the correct
> >values stored in the crtc_state drm_atomic_crtc_get_property() not work?
> 
> This is only a problem when the kernel space modifies property values.
> User space ioctls do the right thing and update both places :
> 
> https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/drm_crtc.c#n4916

Nah, the problem is that we check fro DRIVER_ATOMIC in
drm_atomic_get_property, and because i915 is still not fully atomic that
gives us the wrong answer.

Can you pls double-check that enabling i915 atomic (i915.nuclear_flip=1)
also fixes the bug?

i915 is the only driver still transitioning, I definitely don't want to
have hacks all over for it.

> >Duct-taping over this bug in every place we update these properties
> >(you're just patching one of many) won't scale.
> >
> >Also: Where's the igt for this failure?
> >-Daniel
> 
> There is : 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/kms_pipe_color.c#n554
> That's how we caught it.

Needs a Testcase: igt/kms_pipe_color/$name line in the commit message. How
a bug was discovered and tested is a crucial part of a complete commit
message.
-Daniel

> 
> 
> >>v2: Update non atomic values only if commit succeeds (Bob Paauwe)
> >>
> >>v3: Do not access crtc_state after commit, use crtc->state (Maarten
> >> Lankhorst)
> >>
> >>Cc: Maarten Lankhorst 
> >>Cc: Bob Paauwe 
> >>Cc: 
> >>Signed-off-by: Lionel Landwerlin 
> >>---
> >>  drivers/gpu/drm/drm_atomic_helper.c | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >>b/drivers/gpu/drm/drm_atomic_helper.c
> >>index 7bf678e..13b86cf 100644
> >>--- a/drivers/gpu/drm/drm_atomic_helper.c
> >>+++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>@@ -2979,6 +2979,14 @@ retry:
> >>if (ret)
> >>goto fail;
> >>+   drm_object_property_set_value(>base,
> >>+   config->degamma_lut_property, 0);
> >>+   drm_object_property_set_value(>base,
> >>+   config->ctm_property, 0);
> >>+   drm_object_property_set_value(>base,
> >>+   config->gamma_lut_property,
> >>+   crtc->state->gamma_lut->base.id);
> >>+
> >>/* Driver takes ownership of state on successful commit. */
> >>drm_property_unreference_blob(blob);
> >>-- 
> >>2.8.0.rc3
> >>
> >>___
> >>dri-devel mailing list
> >>dri-devel at lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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

[PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

2016-04-12 Thread Ville Syrjälä

On Tue, Apr 12, 2016 at 04:32:19PM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
> 
> intel_pipe_update_start checks if no vblank interrupt will occur
> during vblank evasion, but cannot check whether the vblank handler has
> run to completion. This function uses the timestamps to determine
> when the last vblank has happened, and interpolates from there.
> 
> Changes since v1:
> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
> Changes since v2:
> - Don't return time of last vblank.
> 
> Cc: Mario Kleiner 
> Cc: Ville SyrjÃ¤lÃ¤ 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3c1a6f18e71c..32bfa4bb8f41 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -303,6 +303,32 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, _vblank, cur_vblank);
>  }
>  
> +/**
> + * drm_accurate_vblank_count - retrieve the master vblank counter
> + * @crtc: which counter to retrieve
> + * @tv_ret: last time counter was updated
> + *
> + * This function is similar to @drm_crtc_vblank_count but this
> + * function interpolates to handle a race with vblank irq's.
> + */
> +
> +u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + u32 vblank, pipe = drm_crtc_index(crtc);

pipe should be 'unsigned int' for consistency.

> + unsigned long flags;
> +
> + spin_lock_irqsave(>vblank_time_lock, flags);
> +
> + drm_update_vblank_count(dev, pipe, 0);

One thing that came to mind is some callers might end up doing the
update twice if the irq wasn't yet enabled when drm_vblank_get() was
called. Eg. drm_wait_one_vblank() might do that. So it might be a bit
more efficient to add a drm_vblank_get_and_update() instead, or something
like that. But I don't really care too much.

Reviewed-by: Ville SyrjÃ¤lÃ¤ 

> + vblank = dev->vblank[pipe].count;
> +
> + spin_unlock_irqrestore(>vblank_time_lock, flags);
> +
> + return vblank;
> +}
> +EXPORT_SYMBOL(drm_accurate_vblank_count);
> +
>  /*
>   * Disable vblank irq's on crtc, make sure that last vblank count
>   * of hardware and corresponding consistent software vblank counter
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 31483c2fef51..747c80da70e5 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -995,6 +995,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
>  extern void drm_vblank_cleanup(struct drm_device *dev);
> +extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
>  extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int 
> pipe);
>  
>  extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH] drm/crtc_helper: Reset empty plane state in drm_helper_crtc_mode_set_base()

2016-04-12 Thread Daniel Vetter

On Tue, Apr 05, 2016 at 04:50:39PM +0800, Liu Ying wrote:
> Transitional drivers might access the NULL pointer plane->state in
> drm_helper_crtc_mode_set_base(), which causes NULL pointer dereference.
> So, let's reset it before handing it over to those drivers.
> commit e4f31ad2b713 ("drm: reset empty state in transitional helpers")
> did the same thing for other transitional helpers, but it seems this one
> was missed.
> 
> Signed-off-by: Liu Ying 

This is kinda intentionally not done, assuming that drivers (when
transitioning) can't handle the full state stuff yet.

I'm not entirely opposed to this, but then we should do it for both plane
and crtc states, and in all cases I think.

Completely new drivers should never use transitional helpers, but instead
just bring up using native atomic helpers directly. So what exactly do you
need this for?
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 79555d2..66ca313 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -1053,10 +1053,12 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc 
> *crtc, int x, int y,
>  
>   if (plane->funcs->atomic_duplicate_state)
>   plane_state = plane->funcs->atomic_duplicate_state(plane);
> - else if (plane->state)
> + else {
> + if (!plane->state)
> + drm_atomic_helper_plane_reset(plane);
> +
>   plane_state = drm_atomic_helper_plane_duplicate_state(plane);
> - else
> - plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
> + }
>   if (!plane_state)
>   return -ENOMEM;
>   plane_state->plane = plane;
> -- 
> 2.5.0
> 

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

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Daniel Vetter

On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
> 
> Cc: David Brown 
> Cc: Brian Starkey 
> 
> Signed-off-by: Liviu Dudau 

Ok, on 2nd look something puzzling: Where are the
drm_encoder/drm_connectors in this driver? Somehow I think just these
parts here won't light up a lot ...
-Daniel

> ---
>  drivers/gpu/drm/arm/Kconfig |  15 +
>  drivers/gpu/drm/arm/Makefile|   2 +
>  drivers/gpu/drm/arm/malidp_crtc.c   | 276 +
>  drivers/gpu/drm/arm/malidp_drv.c| 486 ++
>  drivers/gpu/drm/arm/malidp_drv.h|  49 +++
>  drivers/gpu/drm/arm/malidp_hw.c | 777 
> 
>  drivers/gpu/drm/arm/malidp_hw.h | 192 +
>  drivers/gpu/drm/arm/malidp_planes.c | 342 
>  drivers/gpu/drm/arm/malidp_regs.h   | 172 
>  9 files changed, 2311 insertions(+)
>  create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
>  create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
>  create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index eaed454..e5b5b6b 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -25,3 +25,18 @@ config DRM_HDLCD_SHOW_UNDERRUN
> Enable this option to show in red colour the pixels that the
> HDLCD device did not fetch from framebuffer due to underrun
> conditions.
> +
> +config DRM_MALI_DISPLAY
> + tristate "ARM Mali Display Processor"
> + depends on DRM && OF && (ARM || ARM64)
> + depends on COMMON_CLK
> + select DRM_ARM
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_GEM_CMA_HELPER
> + select VIDEOMODE_HELPERS
> + help
> +   Choose this option if you want to compile the ARM Mali Display
> +   Processor driver. It supports all the variants of the hardware.
> +
> +   If compiled as a module it will be called malidp.
> diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> index 89dcb7b..3e76e6c 100644
> --- a/drivers/gpu/drm/arm/Makefile
> +++ b/drivers/gpu/drm/arm/Makefile
> @@ -1,2 +1,4 @@
>  hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
>  obj-$(CONFIG_DRM_HDLCD)  += hdlcd.o
> +malidp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> +obj-$(CONFIG_DRM_MALI_DISPLAY)   += malidp.o
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> b/drivers/gpu/drm/arm/malidp_crtc.c
> new file mode 100644
> index 000..aa49fd4
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -0,0 +1,276 @@
> +/*
> + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> + * Author: Liviu Dudau 
> + *
> + * This program is free software and is provided to you under the terms of 
> the
> + * GNU General Public License version 2 as published by the Free Software
> + * Foundation, and any use by you of this program is subject to the terms
> + * of such GNU licence.
> + *
> + * ARM Mali DP500/DP550/DP650 driver (crtc operations)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "malidp_drv.h"
> +#include "malidp_hw.h"
> +
> +static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)
> +{
> + struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> + struct malidp_hw_device *hwdev = malidp->dev;
> +
> + /*
> +  * check that the hardware can drive the required clock rate,
> +  * but skip the check if the clock is meant to be disabled (req_rate = 
> 0)
> +  */
> + long rate, req_rate = mode->crtc_clock * 1000;
> +
> + if (req_rate) {
> + rate = clk_round_rate(hwdev->mclk, req_rate);
> + if (rate < req_rate) {
> + DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
> +  mode->crtc_clock);
> + return false;
> + }
> +
> + rate = clk_round_rate(hwdev->pxlclk, req_rate);
> + if (rate != req_rate) {
> + DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
> +  req_rate);
> + return false;
> + }
> +
> + adjusted_mode->crtc_clock = rate / 1000;
> + }
> +
> + return true;
> +}
> +
> +static void malidp_crtc_mode_set_nofb(struct drm_crtc *crtc)
> +{
> + struct malidp_drm *malidp =

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from John Galt  ---
I've been able to "fix" the issue for tahiti and hawaii (without amdgpu) by
forcing an even 60.0hz refresh rate on this display. Despite the workaround, I
believe there's still a bug here. So I'm leaving the report open.

-- 
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/20160412/5a2fda64/attachment.html>

[RFC][PATCH 2/2] drm/arm: Add support for Mali Display Processors

2016-04-12 Thread Daniel Vetter

On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
> 
> Cc: David Brown 
> Cc: Brian Starkey 
> 
> Signed-off-by: Liviu Dudau 

Quickly scrolled through it with an eye towards atomic. Looks real pretty,
I think we're getting closer to the ideal world where a new atomic driver
is just hw specific code plus minimal amounts of glue.

Bunch of comments inline below.
-Daniel

> ---
>  drivers/gpu/drm/arm/Kconfig |  15 +
>  drivers/gpu/drm/arm/Makefile|   2 +
>  drivers/gpu/drm/arm/malidp_crtc.c   | 276 +
>  drivers/gpu/drm/arm/malidp_drv.c| 486 ++
>  drivers/gpu/drm/arm/malidp_drv.h|  49 +++
>  drivers/gpu/drm/arm/malidp_hw.c | 777 
> 
>  drivers/gpu/drm/arm/malidp_hw.h | 192 +
>  drivers/gpu/drm/arm/malidp_planes.c | 342 
>  drivers/gpu/drm/arm/malidp_regs.h   | 172 
>  9 files changed, 2311 insertions(+)
>  create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
>  create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
>  create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index eaed454..e5b5b6b 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -25,3 +25,18 @@ config DRM_HDLCD_SHOW_UNDERRUN
> Enable this option to show in red colour the pixels that the
> HDLCD device did not fetch from framebuffer due to underrun
> conditions.
> +
> +config DRM_MALI_DISPLAY
> + tristate "ARM Mali Display Processor"
> + depends on DRM && OF && (ARM || ARM64)
> + depends on COMMON_CLK
> + select DRM_ARM
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_GEM_CMA_HELPER
> + select VIDEOMODE_HELPERS
> + help
> +   Choose this option if you want to compile the ARM Mali Display
> +   Processor driver. It supports all the variants of the hardware.
> +
> +   If compiled as a module it will be called malidp.
> diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> index 89dcb7b..3e76e6c 100644
> --- a/drivers/gpu/drm/arm/Makefile
> +++ b/drivers/gpu/drm/arm/Makefile
> @@ -1,2 +1,4 @@
>  hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
>  obj-$(CONFIG_DRM_HDLCD)  += hdlcd.o
> +malidp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> +obj-$(CONFIG_DRM_MALI_DISPLAY)   += malidp.o
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> b/drivers/gpu/drm/arm/malidp_crtc.c
> new file mode 100644
> index 000..aa49fd4
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -0,0 +1,276 @@
> +/*
> + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> + * Author: Liviu Dudau 
> + *
> + * This program is free software and is provided to you under the terms of 
> the
> + * GNU General Public License version 2 as published by the Free Software
> + * Foundation, and any use by you of this program is subject to the terms
> + * of such GNU licence.
> + *
> + * ARM Mali DP500/DP550/DP650 driver (crtc operations)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "malidp_drv.h"
> +#include "malidp_hw.h"
> +
> +static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)
> +{
> + struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> + struct malidp_hw_device *hwdev = malidp->dev;
> +
> + /*
> +  * check that the hardware can drive the required clock rate,
> +  * but skip the check if the clock is meant to be disabled (req_rate = 
> 0)
> +  */
> + long rate, req_rate = mode->crtc_clock * 1000;
> +
> + if (req_rate) {
> + rate = clk_round_rate(hwdev->mclk, req_rate);
> + if (rate < req_rate) {
> + DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
> +  mode->crtc_clock);
> + return false;
> + }
> +
> + rate = clk_round_rate(hwdev->pxlclk, req_rate);
> + if (rate != req_rate) {
> + DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
> +  req_rate);
> + return false;
> + }
> +
> + adjusted_mode->crtc_clock = rate / 1000;
> + }
> +
> + return true;
> +}
> +
> +static void

[PATCH 2/2] drm/radeon: handle more than 10 UVD sessions

2016-04-12 Thread Ayyappa Ch

+   if ((version_major >= 0x01) && (version_minor >= 0x37))
+   rdev->uvd.max_handles = RADEON_MAX_UVD_HANDLES;

If major version greater than 01 no need to verify for minor version.

Can we modify like this?

  if ((version_major > 0x01) ||
  (version_major == 0x01 && version_minor >= 0x37)
 )
rdev->uvd.max_handles = RADEON_MAX_UVD_HANDLES;

Thanks,
Ayyappa

On Thu, Apr 7, 2016 at 1:03 AM, Leo Liu  wrote:
> From: Arindam Nath 
>
> Signed-off-by: Christian KÃ¶nig 
> Signed-off-by: Arindam Nath 
> Reviewed-by: Leo Liu 
> ---
>  drivers/gpu/drm/radeon/cikd.h   |  1 +
>  drivers/gpu/drm/radeon/radeon.h |  9 ++---
>  drivers/gpu/drm/radeon/radeon_uvd.c | 33 +
>  drivers/gpu/drm/radeon/uvd_v1_0.c   |  5 +++--
>  drivers/gpu/drm/radeon/uvd_v2_2.c   |  5 +++--
>  drivers/gpu/drm/radeon/uvd_v4_2.c   |  8 ++--
>  6 files changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
> index 391ff9d..cead228 100644
> --- a/drivers/gpu/drm/radeon/cikd.h
> +++ b/drivers/gpu/drm/radeon/cikd.h
> @@ -2071,6 +2071,7 @@
>  #define UVD_UDEC_DBW_ADDR_CONFIG   0xef54
>
>  #define UVD_LMI_EXT40_ADDR 0xf498
> +#define UVD_GP_SCRATCH40xf4e0
>  #define UVD_LMI_ADDR_EXT   0xf594
>  #define UVD_VCPU_CACHE_OFFSET0 0xf608
>  #define UVD_VCPU_CACHE_SIZE0   0xf60c
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 34694ad..827e623 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1669,15 +1669,18 @@ int radeon_pm_get_type_index(struct radeon_device 
> *rdev,
>  /*
>   * UVD
>   */
> -#define RADEON_MAX_UVD_HANDLES 10
> -#define RADEON_UVD_STACK_SIZE  (1024*1024)
> -#define RADEON_UVD_HEAP_SIZE   (1024*1024)
> +#define RADEON_DEFAULT_UVD_HANDLES 10
> +#define RADEON_MAX_UVD_HANDLES 30
> +#define RADEON_UVD_STACK_SIZE  (200*1024)
> +#define RADEON_UVD_HEAP_SIZE   (256*1024)
> +#define RADEON_UVD_SESSION_SIZE(50*1024)
>
>  struct radeon_uvd {
> boolfw_header_present;
> struct radeon_bo*vcpu_bo;
> void*cpu_addr;
> uint64_tgpu_addr;
> +   unsignedmax_handles;
> atomic_thandles[RADEON_MAX_UVD_HANDLES];
> struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
> unsignedimg_size[RADEON_MAX_UVD_HANDLES];
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 0897c66..f8de6d0 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -135,6 +135,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
> }
>
> rdev->uvd.fw_header_present = false;
> +   rdev->uvd.max_handles = RADEON_DEFAULT_UVD_HANDLES;
> if (fw_name) {
> /* Let's try to load the newer firmware first */
> r = request_firmware(>uvd_fw, fw_name, rdev->dev);
> @@ -142,11 +143,27 @@ int radeon_uvd_init(struct radeon_device *rdev)
> dev_err(rdev->dev, "radeon_uvd: Can't load firmware 
> \"%s\"\n",
> fw_name);
> } else {
> +   struct common_firmware_header *hdr = (void 
> *)rdev->uvd_fw->data;
> +   unsigned version_major, version_minor, family_id;
> +
> r = radeon_ucode_validate(rdev->uvd_fw);
> if (r)
> return r;
>
> rdev->uvd.fw_header_present = true;
> +
> +   family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
> +   version_major = (le32_to_cpu(hdr->ucode_version) >> 
> 24) & 0xff;
> +   version_minor = (le32_to_cpu(hdr->ucode_version) >> 
> 8) & 0xff;
> +   DRM_INFO("Found UVD firmware Version: %hu.%hu Family 
> ID: %hu\n",
> +version_major, version_minor, family_id);
> +
> +   /*
> +* Limit the number of UVD handles depending on
> +* microcode major and minor versions.
> +*/
> +   if ((version_major >= 0x01) && (version_minor >= 
> 0x37))
> +   rdev->uvd.max_handles = 
> RADEON_MAX_UVD_HANDLES;
> }
> }
>
> @@ -166,7 +183,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
>
> bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
>   RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE +
> - RADEON_GPU_PAGE_SIZE;

[PATCH 5/7] drm/exynos/decon5433: fix DECON standalone update

2016-04-12 Thread Inki Dae



2016ë 04ì 12ì¼ 16:33ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 04/12/2016 04:25 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> DECON should be updated after un-protecting windows and after changing
>>> output parameters, otherwise image is not displayed in case of HDMI path.
>> I'm not sure why STANDALONE_UPDATE_F bit should be updated after 
>> un-protecting windows and changing output parameters.
>> The fields with _F prefix mean that these will be applied after vsync so we 
>> use protection window in case of all registers which affect display output 
>> so that they can be updated together.
>>
>> Wouldn't there be other thing which affects HDMI output?
>>
>> In addition, we would need another patch which updates TV relevant registers 
>> only in case of DECON-TV. DECON_UPDATE is a register for DECON-TV.
> 
> DECON_UPDATE is present in both DECON and DECON-TV and in both cases
> have the same field STANDALONE_UPDATE_F.
> 
> Documentation for 5433 says:
>> When you modify the shadow attributed registers, set
>> STANDALONE_UPDATE_F.
>>
> So it should be set after setting registers with _F suffix,
> but it has also _F suffix - contradiction. So I guess this _F suffix
> should not be treated too strictly in this case. Moreover the suffix
> has been removed in Exynos7420 - it is called just STANDALONE_UPDATE.

Indeed. I thought the register name has TV suffix so this register is for 
DECON-TV. However, without the register setting, DECON didn't work correctly - 
display not updated.


> 
> Anyway I am not sure what is exact purpose of this register and
> the changes proposed in the patch are rather results of multiple tests
> with hardware - documentation is rather poor on this subject.
> 
> I am also not sure why DECON works without it but DECON-TV does not,
> anyway I set it in both variants because documentation says so.

Ok, picked them up.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 15 ---
>>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index ab9154e..7fec656 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -191,6 +191,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>  
>>> /* enable output and display signal */
>>> decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
>>> +
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int 
>>> win,
>>> @@ -316,9 +318,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
>>> *crtc,
>>>  
>>> /* window enable */
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
>>> -
>>> -   /* standalone update */
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
>>> @@ -336,9 +335,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
>>> *crtc,
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>>  
>>> decon_shadow_protect_win(ctx, win, false);
>>> -
>>> -   /* standalone update */
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
>>> @@ -352,6 +348,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
>>> *crtc)
>>> for (i = ctx->first_win; i < WINDOWS_NR; i++)
>>> decon_shadow_protect_win(ctx, i, false);
>>>  
>>> +   /* standalone update */
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> +
>>> if (ctx->out_type == IFTYPE_I80)
>>> set_bit(BIT_WIN_UPDATED, >flags);
>>>  }
>>> @@ -463,8 +462,10 @@ static void decon_clear_channels(struct 
>>> exynos_drm_crtc *crtc)
>>> decon_shadow_protect_win(ctx, win, true);
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>> decon_shadow_protect_win(ctx, win, false);
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> }
>>> +
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> +
>>> /* TODO: wait for possible vsync */
>>> msleep(50);
>>>  
>>>
> 
>

[PATCH v3] drm/core: Add drm_accurate_vblank_count, v3.

2016-04-12 Thread Maarten Lankhorst

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.

Cc: Mario Kleiner 
Cc: Ville SyrjÃ¤lÃ¤ 
Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f18e71c..32bfa4bb8f41 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -303,6 +303,32 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
store_vblank(dev, pipe, diff, _vblank, cur_vblank);
 }

+/**
+ * drm_accurate_vblank_count - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ * @tv_ret: last time counter was updated
+ *
+ * This function is similar to @drm_crtc_vblank_count but this
+ * function interpolates to handle a race with vblank irq's.
+ */
+
+u32 drm_accurate_vblank_count(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   u32 vblank, pipe = drm_crtc_index(crtc);
+   unsigned long flags;
+
+   spin_lock_irqsave(>vblank_time_lock, flags);
+
+   drm_update_vblank_count(dev, pipe, 0);
+   vblank = dev->vblank[pipe].count;
+
+   spin_unlock_irqrestore(>vblank_time_lock, flags);
+
+   return vblank;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count);
+
 /*
  * Disable vblank irq's on crtc, make sure that last vblank count
  * of hardware and corresponding consistent software vblank counter
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 31483c2fef51..747c80da70e5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -995,6 +995,7 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
 extern void drm_vblank_cleanup(struct drm_device *dev);
+extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
 extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);

 extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,

[PATCH 07/10] drm/virtio: Drop dummy gamma table support

2016-04-12 Thread Julia Lawall



On Tue, 12 Apr 2016, Emil Velikov wrote:

> On 30 March 2016 at 10:51, Daniel Vetter  wrote:
> > No need to confuse userspace like this.
> >
> > Cc: Gerd Hoffmann 
> > Cc: Dave Airlie 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> >  1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> > b/drivers/gpu/drm/virtio/virtgpu_display.c
> > index 4854dac87e24..12b72e29678a 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> > @@ -38,13 +38,6 @@
> >  #define XRES_MAX  8192
> >  #define YRES_MAX  8192
> >
> > -static void virtio_gpu_crtc_gamma_set(struct drm_crtc *crtc,
> > - u16 *red, u16 *green, u16 *blue,
> > - uint32_t start, uint32_t size)
> > -{
> > -   /* TODO */
> > -}
> > -
> >  static void
> >  virtio_gpu_hide_cursor(struct virtio_gpu_device *vgdev,
> >struct virtio_gpu_output *output)
> > @@ -173,7 +166,6 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
> >  static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
> > .cursor_set2= virtio_gpu_crtc_cursor_set,
> > .cursor_move= virtio_gpu_crtc_cursor_move,
> > -   .gamma_set  = virtio_gpu_crtc_gamma_set,
> > .set_config = drm_atomic_helper_set_config,
> > .destroy= drm_crtc_cleanup,
> >
> > @@ -416,7 +408,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
> > *vgdev, int index)
> > return PTR_ERR(plane);
> > drm_crtc_init_with_planes(dev, crtc, plane, NULL,
> >   _gpu_crtc_funcs, NULL);
> > -   drm_mode_crtc_set_gamma_size(crtc, 256);
> > drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
> > plane->crtc = crtc;
> >
> Out of curiosity:
>
> Coccinelle should be able to handle/generate such patches, shouldn't
> it ? I believe in the past people used it for similar
> refactoring/cleanups, yet not (m)any of them [the cocci files] got
> checked in the kernel tree.
>
> Thinking about future drivers derived from outdated sources - do you
> think it's a good/bad idea to check/run them along side the existing
> ones ?

The issue is that there is no point to put an empty function in a
structure?

It would be a bit subtle for Coccinelle, because it requires also knowing
that one is allowed to leave that particular field empty.

julia

[PATCH] drm/amdgpu: handle more than 10 UVD sessions (v2)

2016-04-12 Thread Christian König

Am 12.04.2016 um 15:14 schrieb Emil Velikov:
> On 12 April 2016 at 12:46, Christian KÃ¶nig  
> wrote:
>> From: Arindam Nath 
>>
>> Change History
>> --
>>
>> v2:
>> - Make firmware version check correctly. Firmware
>>versions >= 1.80 should all support 40 UVD
>>instances.
> Fwiw, this is the type of information that people [unfamiliar with the
> firmware] will appreciate in the commit message. Currently it's almost
> like a "here a magic commit"
>
> Can we have something like that for the future, pretty please ?

Well, unfortunately not most of the time. A lot of firmware changes are 
usually about top secrete stuff where you need explicit approval.

Getting this for each individual firmware change is usually just to much 
overhead.

Christan.

>
> -Emil

[PATCH v2] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae

This patch cleans up interface type relevant codes.

Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode - For DECON-TV, HW Trigger mode is flaged mandatorily
because HDMI Timing Generator generates VSYNC signal
which works as a hardware trigger.

Changelog v2.
- If interface type is HDMI then set out_type to I80.
- fix compile warning.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 57 ++-
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5245bc5..eacbb73 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -28,6 +28,10 @@
 #define WINDOWS_NR 3
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128

+#define IFTYPE_I80 (1 << 0)
+#define I80_HW_TRG (1 << 1)
+#define IFTYPE_HDMI(1 << 2)
+
 static const char * const decon_clks_name[] = {
"pclk",
"aclk_decon",
@@ -38,12 +42,6 @@ static const char * const decon_clks_name[] = {
"sclk_decon_eclk",
 };

-enum decon_iftype {
-   IFTYPE_RGB,
-   IFTYPE_I80,
-   IFTYPE_HDMI
-};
-
 enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
@@ -61,7 +59,7 @@ struct decon_context {
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
int pipe;
unsigned long   flags;
-   enum decon_iftype   out_type;
+   unsigned long   out_type;
int first_win;
 };

@@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)

if (!test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
val = VIDINTCON0_INTEN;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN;
@@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)

 static void decon_setup_trigger(struct decon_context *ctx)
 {
-   u32 val = (ctx->out_type != IFTYPE_HDMI)
+   u32 val = !(ctx->out_type & I80_HW_TRG)
? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
  TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
@@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
if (test_bit(BIT_SUSPENDED, >flags))
return;

-   if (ctx->out_type == IFTYPE_HDMI) {
+   if (ctx->out_type & IFTYPE_HDMI) {
m->crtc_hsync_start = m->crtc_hdisplay + 10;
m->crtc_hsync_end = m->crtc_htotal - 92;
m->crtc_vsync_start = m->crtc_vdisplay + 1;
@@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc *crtc)

/* lcd on and use command if */
val = VIDOUT_LCD_ON;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
-   else
+   decon_setup_trigger(ctx);
+   } else {
val |= VIDOUT_RGB_IF;
+   }
+
writel(val, ctx->addr + DECON_VIDOUTCON0);

val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);

-   if (ctx->out_type != IFTYPE_I80) {
+   if (!(ctx->out_type & IFTYPE_I80)) {
val = VIDTCON00_VBPD_F(
m->crtc_vtotal - m->crtc_vsync_end - 1) |
VIDTCON00_VFPD_F(
@@ -183,8 +184,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_VIDTCON11);
}

-   decon_setup_trigger(ctx);
-
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
 }
@@ -300,7 +299,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = dma_addr + pitch * state->src.h;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));

-   if (ctx->out_type != IFTYPE_HDMI)
+   if (!(ctx->out_type & IFTYPE_HDMI))
val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
| BIT_VAL(state->crtc.w * bpp, 13, 0);
else
@@ -348,7 +347,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);

-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, >flags);
 }

@@ -374,7 +373,7 @@ static void decon_swreset(struct decon_context *ctx)

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae



2016ë 04ì 12ì¼ 14:55ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> On 04/12/2016 02:40 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>>>  Hi Andrzej,
>>>
>>> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
 Hi Inki,

 On 04/05/2016 10:27 AM, Inki Dae wrote:
> This patch cleans up interface type relevant codes.
>
> Trigger mode is determinded only by i80 mode, which isn't
> related to Display types - HDMI or Display controller.
> So this patch makes the trigger mode to be set only in case of
> i80 mode.
 With this patch HDMI path image has serious synchronization problems.
 Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
 signal which works as a hardware trigger for DECON-TV, so I guess
 trigger is required.
>>> Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.
>> Looks considered already. for DECON-TV, I80_HW_TRG flag is used mandatorily,
>>  .compatible = "samsung,exynos5433-decon-tv",
>>  .data = (void *)(I80_HW_TRG | IFTYPE_HDMI)
> Here it is OK, but there are other changes, see below for more details.
>>
 Btw, I think it could be good to remove suffixes I80_RGV from
 TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
 misleading and differ from documentation.
>>> Indeed. Looked strange when I wrote the suffixes.
>> will send another cleanup patch.
>>
>> Thanks,
>> Inki Dae
>>
 As far as I have tested I80 mode works OK on Decon5433.
>>> Thanks for testing.
>>> Inki Dae
>>>
 Regards
 Andrzej

> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
> ++-
>  1 file changed, 27 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 5245bc5..5922e99 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -28,6 +28,10 @@
>  #define WINDOWS_NR   3
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>
> +#define IFTYPE_I80   (1 << 0)
> +#define I80_HW_TRG   (1 << 1)
> +#define IFTYPE_HDMI  (1 << 2)
> +
>  static const char * const decon_clks_name[] = {
>   "pclk",
>   "aclk_decon",
> @@ -38,12 +42,6 @@ static const char * const decon_clks_name[] = {
>   "sclk_decon_eclk",
>  };
>
> -enum decon_iftype {
> - IFTYPE_RGB,
> - IFTYPE_I80,
> - IFTYPE_HDMI
> -};
> -
>  enum decon_flag_bits {
>   BIT_CLKS_ENABLED,
>   BIT_IRQS_ENABLED,
> @@ -61,7 +59,7 @@ struct decon_context {
>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>   int pipe;
>   unsigned long   flags;
> - enum decon_iftype   out_type;
> + unsigned intout_type;
>   int first_win;
>  };
>
> @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
> *crtc)
>
>   if (!test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
>   val = VIDINTCON0_INTEN;
> - if (ctx->out_type == IFTYPE_I80)
> + if (ctx->out_type & IFTYPE_I80)
>   val |= VIDINTCON0_FRAMEDONE;
>   else
>   val |= VIDINTCON0_INTFRMEN;
> @@ -119,7 +117,7 @@ static void decon_disable_vblank(struct 
> exynos_drm_crtc *crtc)
>
>  static void decon_setup_trigger(struct decon_context *ctx)
>  {
> - u32 val = (ctx->out_type != IFTYPE_HDMI)
> + u32 val = !(ctx->out_type & I80_HW_TRG)
>   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> @@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   if (test_bit(BIT_SUSPENDED, >flags))
>   return;
>
> - if (ctx->out_type == IFTYPE_HDMI) {
> + if (ctx->out_type & IFTYPE_HDMI) {
>   m->crtc_hsync_start = m->crtc_hdisplay + 10;
>   m->crtc_hsync_end = m->crtc_htotal - 92;
>   m->crtc_vsync_start = m->crtc_vdisplay + 1;
> @@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc 
> *crtc)
>
>   /* lcd on and use command if */
>   val = VIDOUT_LCD_ON;
> - if (ctx->out_type == IFTYPE_I80)
> + if (ctx->out_type & IFTYPE_I80) {
>   val |= VIDOUT_COMMAND_IF;
> - else
> + decon_setup_trigger(ctx);
> + } else {
>   val |= VIDOUT_RGB_IF;
> + }
> +

[PATCH 07/10] drm/virtio: Drop dummy gamma table support

2016-04-12 Thread Emil Velikov

On 30 March 2016 at 10:51, Daniel Vetter  wrote:
> No need to confuse userspace like this.
>
> Cc: Gerd Hoffmann 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 4854dac87e24..12b72e29678a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -38,13 +38,6 @@
>  #define XRES_MAX  8192
>  #define YRES_MAX  8192
>
> -static void virtio_gpu_crtc_gamma_set(struct drm_crtc *crtc,
> - u16 *red, u16 *green, u16 *blue,
> - uint32_t start, uint32_t size)
> -{
> -   /* TODO */
> -}
> -
>  static void
>  virtio_gpu_hide_cursor(struct virtio_gpu_device *vgdev,
>struct virtio_gpu_output *output)
> @@ -173,7 +166,6 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
>  static const struct drm_crtc_funcs virtio_gpu_crtc_funcs = {
> .cursor_set2= virtio_gpu_crtc_cursor_set,
> .cursor_move= virtio_gpu_crtc_cursor_move,
> -   .gamma_set  = virtio_gpu_crtc_gamma_set,
> .set_config = drm_atomic_helper_set_config,
> .destroy= drm_crtc_cleanup,
>
> @@ -416,7 +408,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
> *vgdev, int index)
> return PTR_ERR(plane);
> drm_crtc_init_with_planes(dev, crtc, plane, NULL,
>   _gpu_crtc_funcs, NULL);
> -   drm_mode_crtc_set_gamma_size(crtc, 256);
> drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
> plane->crtc = crtc;
>
Out of curiosity:

Coccinelle should be able to handle/generate such patches, shouldn't
it ? I believe in the past people used it for similar
refactoring/cleanups, yet not (m)any of them [the cocci files] got
checked in the kernel tree.

Thinking about future drivers derived from outdated sources - do you
think it's a good/bad idea to check/run them along side the existing
ones ?

-Emil

[PATCH] drm/amdgpu: handle more than 10 UVD sessions (v2)

2016-04-12 Thread Emil Velikov

On 12 April 2016 at 12:46, Christian KÃ¶nig  wrote:
> From: Arindam Nath 
>
> Change History
> --
>
> v2:
> - Make firmware version check correctly. Firmware
>   versions >= 1.80 should all support 40 UVD
>   instances.
Fwiw, this is the type of information that people [unfamiliar with the
firmware] will appreciate in the commit message. Currently it's almost
like a "here a magic commit"

Can we have something like that for the future, pretty please ?

-Emil

[PATCH] drm: atomic: fix legacy gamma set helper

2016-04-12 Thread Daniel Vetter

On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc object.

tbh sounds like this is the bug here - why does the lookup of the correct
values stored in the crtc_state drm_atomic_crtc_get_property() not work?

Duct-taping over this bug in every place we update these properties
(you're just patching one of many) won't scale.

Also: Where's the igt for this failure?
-Daniel

> 
> v2: Update non atomic values only if commit succeeds (Bob Paauwe)
> 
> v3: Do not access crtc_state after commit, use crtc->state (Maarten
> Lankhorst)
> 
> Cc: Maarten Lankhorst 
> Cc: Bob Paauwe 
> Cc: 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7bf678e..13b86cf 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2979,6 +2979,14 @@ retry:
>   if (ret)
>   goto fail;
>  
> + drm_object_property_set_value(>base,
> + config->degamma_lut_property, 0);
> + drm_object_property_set_value(>base,
> + config->ctm_property, 0);
> + drm_object_property_set_value(>base,
> + config->gamma_lut_property,
> + crtc->state->gamma_lut->base.id);
> +
>   /* Driver takes ownership of state on successful commit. */
>  
>   drm_property_unreference_blob(blob);
> -- 
> 2.8.0.rc3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

tgsi: add support for buffer/atomic operations to tgsi_exec

2016-04-12 Thread Dieter Nützel

Warning during compilation after git pull:

tgsi/tgsi_exec.c: In function 'exec_atomop_buf':
tgsi/tgsi_exec.c:4060:8: warning: array subscript is above array bounds 
[-Warray-bounds]
r[3].f[j] = rgba[3][j];
 ^

Any hints where I should look?

Dieter

[PATCH 02/23] ARM: dts: n950: add display support

2016-04-12 Thread Tony Lindgren

* Sebastian Reichel  [160324 17:16]:
> On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > I _think_, that your HW team decided to cover the first and the
> > > last few pixels of the 864 display with plastic. So technically
> > > it's a 864 display, but effectively it's 854.

Sebastian, should I apply this dts patch as is or are changes
still needed?

Tony

[PATCH] drm: atomic: fix legacy gamma set helper

2016-04-12 Thread Lionel Landwerlin

On 12/04/16 12:57, Daniel Vetter wrote:
> On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
>> Color management properties are a bit of an odd use case because
>> they're not marked as atomic properties. Currently we're not updating
>> the non atomic values so the drm_crtc_state is out of sync with the
>> values stored in the crtc object.
> tbh sounds like this is the bug here - why does the lookup of the correct
> values stored in the crtc_state drm_atomic_crtc_get_property() not work?

This is only a problem when the kernel space modifies property values.
User space ioctls do the right thing and update both places :

https://cgit.freedesktop.org/drm-intel/tree/drivers/gpu/drm/drm_crtc.c#n4916

>
> Duct-taping over this bug in every place we update these properties
> (you're just patching one of many) won't scale.
>
> Also: Where's the igt for this failure?
> -Daniel

There is : 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tests/kms_pipe_color.c#n554
That's how we caught it.


>> v2: Update non atomic values only if commit succeeds (Bob Paauwe)
>>
>> v3: Do not access crtc_state after commit, use crtc->state (Maarten
>>  Lankhorst)
>>
>> Cc: Maarten Lankhorst 
>> Cc: Bob Paauwe 
>> Cc: 
>> Signed-off-by: Lionel Landwerlin 
>> ---
>>   drivers/gpu/drm/drm_atomic_helper.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 7bf678e..13b86cf 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2979,6 +2979,14 @@ retry:
>>  if (ret)
>>  goto fail;
>>   
>> +drm_object_property_set_value(>base,
>> +config->degamma_lut_property, 0);
>> +drm_object_property_set_value(>base,
>> +config->ctm_property, 0);
>> +drm_object_property_set_value(>base,
>> +config->gamma_lut_property,
>> +crtc->state->gamma_lut->base.id);
>> +
>>  /* Driver takes ownership of state on successful commit. */
>>   
>>  drm_property_unreference_blob(blob);
>> -- 
>> 2.8.0.rc3
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: handle more than 10 UVD sessions (v2)

2016-04-12 Thread Christian König

From: Arindam Nath 

Change History
--

v2:
- Make firmware version check correctly. Firmware
  versions >= 1.80 should all support 40 UVD
  instances.
- Replace AMDGPU_MAX_UVD_HANDLES with max_handles
  variable.

v1:
- The firmware can handle upto 40 UVD sessions.

Signed-off-by: Arindam Nath 
Signed-off-by: Ayyappa Chandolu 
Reviewed-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 11 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 30 --
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |  5 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |  5 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  7 +++--
 .../gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_d.h   |  1 +
 6 files changed, 41 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 36afabb..4805e45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1592,16 +1592,19 @@ void amdgpu_get_pcie_info(struct amdgpu_device *adev);
 /*
  * UVD
  */
-#define AMDGPU_MAX_UVD_HANDLES 10
-#define AMDGPU_UVD_STACK_SIZE  (1024*1024)
-#define AMDGPU_UVD_HEAP_SIZE   (1024*1024)
-#define AMDGPU_UVD_FIRMWARE_OFFSET 256
+#define AMDGPU_DEFAULT_UVD_HANDLES 10
+#define AMDGPU_MAX_UVD_HANDLES 40
+#define AMDGPU_UVD_STACK_SIZE  (200*1024)
+#define AMDGPU_UVD_HEAP_SIZE   (256*1024)
+#define AMDGPU_UVD_SESSION_SIZE(50*1024)
+#define AMDGPU_UVD_FIRMWARE_OFFSET 256

 struct amdgpu_uvd {
struct amdgpu_bo*vcpu_bo;
void*cpu_addr;
uint64_tgpu_addr;
void*saved_bo;
+   unsignedmax_handles;
atomic_thandles[AMDGPU_MAX_UVD_HANDLES];
struct drm_file *filp[AMDGPU_MAX_UVD_HANDLES];
struct delayed_work idle_work;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 338da80..76ebc10 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -151,6 +151,9 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
return r;
}

+   /* Set the default UVD handles that the firmware can handle */
+   adev->uvd.max_handles = AMDGPU_DEFAULT_UVD_HANDLES;
+
hdr = (const struct common_firmware_header *)adev->uvd.fw->data;
family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
version_major = (le32_to_cpu(hdr->ucode_version) >> 24) & 0xff;
@@ -158,8 +161,19 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
DRM_INFO("Found UVD firmware Version: %hu.%hu Family ID: %hu\n",
version_major, version_minor, family_id);

+   /*
+* Limit the number of UVD handles depending on microcode major
+* and minor versions. The firmware version which has 40 UVD
+* instances support is 1.80. So all subsequent versions should
+* also have the same support.
+*/
+   if ((version_major > 0x01) ||
+   ((version_major == 0x01) && (version_minor >= 0x50)))
+   adev->uvd.max_handles = AMDGPU_MAX_UVD_HANDLES;
+
bo_size = AMDGPU_GPU_PAGE_ALIGN(le32_to_cpu(hdr->ucode_size_bytes) + 8)
-+  AMDGPU_UVD_STACK_SIZE + AMDGPU_UVD_HEAP_SIZE;
+ +  AMDGPU_UVD_STACK_SIZE + AMDGPU_UVD_HEAP_SIZE
+ +  AMDGPU_UVD_SESSION_SIZE * adev->uvd.max_handles;
r = amdgpu_bo_create(adev, bo_size, PAGE_SIZE, true,
 AMDGPU_GEM_DOMAIN_VRAM,
 AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
@@ -202,7 +216,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
return r;
}

-   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i) {
+   for (i = 0; i < adev->uvd.max_handles; ++i) {
atomic_set(>uvd.handles[i], 0);
adev->uvd.filp[i] = NULL;
}
@@ -248,7 +262,7 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
if (adev->uvd.vcpu_bo == NULL)
return 0;

-   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i)
+   for (i = 0; i < adev->uvd.max_handles; ++i)
if (atomic_read(>uvd.handles[i]))
break;

@@ -303,7 +317,7 @@ void amdgpu_uvd_free_handles(struct amdgpu_device *adev, 
struct drm_file *filp)
struct amdgpu_ring *ring = >uvd.ring;
int i, r;

-   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i) {
+   for (i = 0; i < adev->uvd.max_handles; ++i) {
uint32_t handle = atomic_read(>uvd.handles[i]);
if (handle != 0 && adev->uvd.filp[i] == filp) {
struct fence *fence;
@@ -563,7 +577,7 @@ static int amdgpu_uvd_cs_msg(struct amdgpu_uvd_cs_ctx *ctx,
amdgpu_bo_kunmap(bo);

[PATCH v4 RESEND 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

2016-04-12 Thread Jani Nikula

On Mon, 28 Mar 2016, Lyude  wrote:
> Resending this because it looks like replying to my previous series of patches
> causes patchwork to pick up patches from the original version of this and
> try to apply them along with this one.

Lyude, these don't seem to apply cleanly, please rebase and repost, and
we can pick them up once Ville confirms they don't break his display.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 07/10] drm/virtio: Drop dummy gamma table support

2016-04-12 Thread Daniel Vetter

On Fri, Apr 01, 2016 at 10:38:09AM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> > No need to confuse userspace like this.
> 
> Reviewed-by: Gerd Hoffmann 

This and the bochs one applied to drm-misc, thanks for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88

2016-04-12 Thread Hwang, Dongseong

Follow-up of the kernel patch: 
https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html

The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
with OpenGL shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.

CC: Peter FrÃ¼hberger 
Cc: Rainer Hochecker 
Cc: Benjamin Widawsky 
CC: Chad Versace 
Signed-off-by: Dongseong Hwang 
---
 include/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..ca2f488 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -34,6 +34,13 @@
 /* color index */
 #define DRM_FORMAT_C8  fourcc_code('C', '8', ' ', ' ') /* [7:0] C */

+/* 8 bpp Red */
+#define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.5.0
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Intel-gfx] [PATCH] drm/core: Fix ordering in drm_mode_config_cleanup.

2016-04-12 Thread Daniel Vetter

On Fri, Apr 01, 2016 at 11:04:10PM +0300, Ville SyrjÃ¤lÃ¤ wrote:
> On Tue, Mar 22, 2016 at 04:08:39PM +0100, Maarten Lankhorst wrote:
> > Op 22-03-16 om 15:58 schreef Ville SyrjÃ¤lÃ¤:
> > > On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
> > >> __drm_atomic_helper_plane_destroy_state calls
> > >> drm_framebuffer_unreference, which means that if drm_framebuffer_free
> > >> is called before plane->destroy freed memory will be accessed.
> > >>
> > >> A similar case happens for the blob list, which was freed before the
> > >> crtc state was, resulting in the unreference_blob from crtc_destroy_state
> > >> pointing to garbage memory causing another opportunity for a GPF.
> > >>
> > >> Signed-off-by: Maarten Lankhorst 
> > >> ---
> > >>  drivers/gpu/drm/drm_crtc.c | 18 +-
> > >>  1 file changed, 9 insertions(+), 9 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > >> index 51c5a00ffdff..5a13b1afccbe 100644
> > >> --- a/drivers/gpu/drm/drm_crtc.c
> > >> +++ b/drivers/gpu/drm/drm_crtc.c
> > >> @@ -5958,6 +5958,15 @@ void drm_mode_config_cleanup(struct drm_device 
> > >> *dev)
> > >>  drm_property_destroy(dev, property);
> > >>  }
> > > And what about props? Any chance of explosion due to those being gone?
> > >
> > Not as far as I'm aware of.
> > 
> > If you use something like a crtc_x property, only the value gets written to 
> > crtc_state, the value is an int that would still be valid.
> 
> I was too lazy to confirm this for all drivers. But at least i915 looked
> clean on that front. So
> 
> Reviewed-by: Ville SyrjÃ¤lÃ¤ 

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

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-04-12 Thread Daniel Vetter

On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
> 
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
> 
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
> 
> Cc: stable at vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References: 
> https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom 
> Cc: David Herrmann 

Reviewed-by: Daniel Vetter 

But definitely want a t-b from Thomas before applying, since he reported
this regression.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>   return 0;
>  }
>  
> +struct drm_mode_rmfb_work {
> + struct work_struct work;
> + struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> + drm_framebuffer_remove(arg->fb);
> +}
> +
>  /**
>   * drm_mode_rmfb - remove an FB from the configuration
>   * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
>   mutex_unlock(>mode_config.fb_lock);
>   mutex_unlock(_priv->fbs_lock);
>  
> - drm_framebuffer_unreference(fb);
> + /*
> +  * drm_framebuffer_remove may fail with -EINTR on pending signals,
> +  * so run this in a separate stack as there's no way to correctly
> +  * handle this after the fb is already removed from the lookup table.
> +  */
> + if (atomic_read(>refcount.refcount) > 1) {
> + struct drm_mode_rmfb_work arg;
> +
> + INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
> + arg.fb = fb;
> +
> + schedule_work();
> + flush_work();
> + destroy_work_on_stack();
> + } else
> + drm_framebuffer_unreference(fb);
>  
>   return 0;
>  
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[RFC 1/5] drm: Add DRM support for tiny LCD displays

2016-04-12 Thread Daniel Vetter

On Fri, Apr 01, 2016 at 09:15:45PM +0200, Noralf TrÃ¸nnes wrote:
> Den 29.03.2016 09:27, skrev Daniel Vetter:
> >I was wondering whether we couldn't avoid the _with_funcs here by setting
> >up fbdefio iff ->dirty is set. Then you could add the generic defio setup
> >code to drm_fbdev_cma_create after helper->fb is allocated, but only if
> >helper->fb->funcs->dirty is set. Makes for a bit less boilerplate.
> >
> >Or did I miss something?
> 
> I don't see how I can avoid drm_fbdev_cma_init_with_funcs():
> 
> static struct drm_framebuffer_funcs tinydrm_fb_cma_funcs = {
> .destroy= drm_fb_cma_destroy,
> .create_handle  = drm_fb_cma_create_handle,
> .dirty  = tinydrm_fbdev_dirty,
> };
> 
> static int tinydrm_fbdev_create(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size *sizes)
> {
> return drm_fbdev_cma_create_with_funcs(helper, sizes,
> _fb_cma_funcs);
> }
> 
> static const struct drm_fb_helper_funcs tinydrm_fb_helper_funcs = {
> .fb_probe = tinydrm_fbdev_create,
> };
> 
> int tinydrm_fbdev_init(struct tinydrm_device *tdev)
> {
> struct drm_device *dev = tdev->base;
> struct drm_fbdev_cma *cma;
> 
> cma = drm_fbdev_cma_init_with_funcs(dev, 16,
> dev->mode_config.num_crtc,
> dev->mode_config.num_connector,
> _fb_helper_funcs);
> if (IS_ERR(cma))
> return PTR_ERR(cma);
> 
> tdev->fbdev_cma = cma;
> 
> return 0;
> }
> 
> 
> Thanks for your feedback so far Daniel, I quite like the direction this is
> taking. I'll try and implement it in a new version of the patchset.

Yeah I was dense really. One option to avoid most of this might be to add
a framebuffer_create helper function to dev->mode_config->helpers (we
don't yet have a vtable for global helper hooks, so would need to add
that), which instead of the top-level uin32_t -> drm_framebuffer gets a
struct *drm_gem_object[4] array parameter with already decoded buffer
object handles. Drivers could then use that to add their own dirtyfb hooks
and other special sauce to drm_framebuffer, while cma would just use that
hook (if it's set) instead of calling cma_create_fb directly.

So yeah, essentially go back to one of your original proposals. But it
will still not be entirely clean, so whatever you think looks better I'd
say ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/ttm: Fix TTM BO accounting

2016-04-12 Thread Felix Kuehling

This is the implementation of ttm_round_pot:

size_t ttm_round_pot(size_t size)
{
if ((size & (size - 1)) == 0)
return size;
else if (size > PAGE_SIZE)
return PAGE_ALIGN(size);
else {
size_t tmp_size = 4;

while (tmp_size < size)
tmp_size <<= 1;

return tmp_size;
}
return 0;
}

As you can see, for size > PAGE_SIZE it just returns PAGE_ALIGN(size).
It does not actually round to a power of two in this case.

Regards,
  Felix

On 16-04-12 12:21 PM, Thomas Hellstrom wrote:
> On 04/12/2016 05:57 PM, Alex Deucher wrote:
>> From: Felix Kuehling 
>>
>> TTM BO accounting is out of sync with how memory is really allocated
>> in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
>> estimated overhead with many small allocations.
>>
>> ttm_dma_tt_alloc_page_directory makes a single allocation for three
>> arrays: pages, DMA and CPU addresses. It uses drm_calloc_large, which
>> uses kmalloc internally for allocations smaller than PAGE_SIZE.
>> ttm_round_pot should be a good approximation of its memory usage both
>> above and below PAGE_SIZE.
> I think for allocations larger than PAGE_SIZE,
> ttm_round_pot() will overestimate. You should probably use the smaller
> of the two.
>
> /Thomas
>
>
>
>> Signed-off-by: Felix Kuehling 
>> Reviewed-by: Monk Liu 
>> Reviewed-by: Christian KÃ¶nig 
>> ---
>>  drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 4cbf265..870a87a 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1215,7 +1215,7 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>>  size_t size = 0;
>>  
>>  size += ttm_round_pot(struct_size);
>> -size += PAGE_ALIGN(npages * sizeof(void *));
>> +size += ttm_round_pot(npages * sizeof(void *));
>>  size += ttm_round_pot(sizeof(struct ttm_tt));
>>  return size;
>>  }
>> @@ -1229,8 +1229,7 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>>  size_t size = 0;
>>  
>>  size += ttm_round_pot(struct_size);
>> -size += PAGE_ALIGN(npages * sizeof(void *));
>> -size += PAGE_ALIGN(npages * sizeof(dma_addr_t));
>> +size += ttm_round_pot(npages * (2*sizeof(void *) + sizeof(dma_addr_t)));
>>  size += ttm_round_pot(sizeof(struct ttm_dma_tt));
>>  return size;
>>  }

-- 
F e l i x   K u e h l i n g
SMTS Software Development Engineer | Vertical Workstation/Compute
1 Commerce Valley Dr. East, Markham, ON L3T 7X6 Canada
(O) +1(289)695-1597
   _ _   _   _   _
  / \   | \ / | |  _  \  \ _  |
 / A \  | \M/ | | |D) )  /|_| |
/_/ \_\ |_| |_| |_/ |__/ \|   facebook.com/AMD | amd.com

[PATCH v3 1/3] drm/edid: Add drm_edid_get_monitor_name()

2016-04-12 Thread Jani Nikula

On Mon, 11 Apr 2016, Jim Bride  wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file  where the rest of the EDID helper
> functions are implemented.
>
> v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld()
> use a common helper function to extract the monitor name from the
> edid. [Jani] + rebase.
>
> v3: Minor changes suggested by Jani + rebase.
>
> cc: dri-devel at lists.freedesktop.org
> cc: Jani Nikula 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/drm_edid.c | 51 
> ++
>  include/drm/drm_crtc.h |  2 ++
>  2 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 558ef9f..da30ce3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3293,6 +3293,46 @@ monitor_name(struct detailed_timing *t, void *data)
>   *(u8 **)data = t->data.other_data.data.str.str;
>  }
>  
> +static int get_monitor_name(struct edid *edid, char name[13])
> +{
> + char *edid_name = NULL;
> + int mnl;
> +
> + if (!edid || !name)
> + return 0;
> +
> + drm_for_each_detailed_block((u8 *)edid, monitor_name, _name);
> + for (mnl = 0; edid_name && mnl < 13; mnl++) {
> + if (edid_name[mnl] == 0x0a)
> + break;
> +
> + name[mnl] = edid_name[mnl];
> + }
> +
> + return mnl;
> +}
> +
> +/**
> + * drm_edid_get_monitor_name - fetch the monitor name from the edid
> + * @edid: monitor EDID information
> + * @name: pointer to a character array to hold the name of the monitor
> + * @bufsize: The size of the name buffer (should be at least 13 chars.)

Nitpick, should be 13 + termination = 14 bytes.

> + *
> + */
> +void drm_edid_get_monitor_name(struct edid *edid, char *name, int bufsize)
> +{
> + int name_length = -1;

Nitpick, no need to initialize.

Other than those,

Reviewed-by: Jani Nikula 


> + char buf[13];
> + 
> + if (bufsize <= 0)
> + return;
> +
> + name_length = min(get_monitor_name(edid, buf), bufsize - 1);
> + memcpy(name, buf, name_length);
> + name[name_length] = '\0';
> +}
> +EXPORT_SYMBOL(drm_edid_get_monitor_name);
> +
>  /**
>   * drm_edid_to_eld - build ELD from EDID
>   * @connector: connector corresponding to the HDMI/DP sink
> @@ -3306,7 +3346,6 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>  {
>   uint8_t *eld = connector->eld;
>   u8 *cea;
> - u8 *name;
>   u8 *db;
>   int total_sad_count = 0;
>   int mnl;
> @@ -3320,14 +3359,8 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>   return;
>   }
>  
> - name = NULL;
> - drm_for_each_detailed_block((u8 *)edid, monitor_name, );
> - /* max: 13 bytes EDID, 16 bytes ELD */
> - for (mnl = 0; name && mnl < 13; mnl++) {
> - if (name[mnl] == 0x0a)
> - break;
> - eld[20 + mnl] = name[mnl];
> - }
> + mnl = get_monitor_name(edid, eld + 20);
> +
>   eld[4] = (cea[1] << 5) | mnl;
>   DRM_DEBUG_KMS("ELD monitor %s\n", eld + 20);
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8cb377c..6d46842 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2500,6 +2500,8 @@ extern int drm_edid_header_is_valid(const u8 *raw_edid);
>  extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>bool *edid_corrupt);
>  extern bool drm_edid_is_valid(struct edid *edid);
> +extern void drm_edid_get_monitor_name(struct edid *edid, char *name,
> +   int buflen);
>  
>  extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
> *dev,
>char topology[8]);

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v4 RESEND 0/5] Move workarounds from intel_dp_dpcd_read_wake() into drm's DP helpers

2016-04-12 Thread Lyude

Sounds good, I'll have the rebased versions posted in a bit

On Tue, 2016-04-12 at 13:17 +0300, Jani Nikula wrote:
> On Mon, 28 Mar 2016, Lyude  wrote:
> > 
> > Resending this because it looks like replying to my previous series
> > of patches
> > causes patchwork to pick up patches from the original version of
> > this and
> > try to apply them along with this one.
> Lyude, these don't seem to apply cleanly, please rebase and repost,
> and
> we can pick them up once Ville confirms they don't break his display.
> 
> BR,
> Jani.
> 
> 
-- 
Cheers,
Lyude

[PATCH] drm/ttm: Fix TTM BO accounting

2016-04-12 Thread Alex Deucher

From: Felix Kuehling 

TTM BO accounting is out of sync with how memory is really allocated
in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
estimated overhead with many small allocations.

ttm_dma_tt_alloc_page_directory makes a single allocation for three
arrays: pages, DMA and CPU addresses. It uses drm_calloc_large, which
uses kmalloc internally for allocations smaller than PAGE_SIZE.
ttm_round_pot should be a good approximation of its memory usage both
above and below PAGE_SIZE.

Signed-off-by: Felix Kuehling 
Reviewed-by: Monk Liu 
Reviewed-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4cbf265..870a87a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1215,7 +1215,7 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
size_t size = 0;

size += ttm_round_pot(struct_size);
-   size += PAGE_ALIGN(npages * sizeof(void *));
+   size += ttm_round_pot(npages * sizeof(void *));
size += ttm_round_pot(sizeof(struct ttm_tt));
return size;
 }
@@ -1229,8 +1229,7 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
size_t size = 0;

size += ttm_round_pot(struct_size);
-   size += PAGE_ALIGN(npages * sizeof(void *));
-   size += PAGE_ALIGN(npages * sizeof(dma_addr_t));
+   size += ttm_round_pot(npages * (2*sizeof(void *) + sizeof(dma_addr_t)));
size += ttm_round_pot(sizeof(struct ttm_dma_tt));
return size;
 }
-- 
2.5.5

[PATCH 00/11] ASoC: hdac_hdmi: Add multichannel support

2016-04-12 Thread Subhransu S. Prusty

On Tue, Apr 12, 2016 at 06:54:35AM +0100, Mark Brown wrote:
> On Tue, Apr 12, 2016 at 07:43:59AM +0200, Takashi Iwai wrote:
> 
> > But the problem is more complicated because you're changing drm stuff,
> > too.  This is usually managed in drm tree.  So this cross over three
> > different trees.
> 
> The DRM folks tend to leave this up to us, or at least review on any of
> these crossover patches has been extremely light.
> 
> > Do we really need this?  Even the direct reference is pretty much
> > obvious.  e.g. I see no big difference between two lines below:
> > spk_alloc = drm_eld_get_spk_alloc(some_eld);
> > spk_alloc = some_eld[DRM_ELD_SPAEKER];
> 
> That'd make things even easier of course.

Takashi/Mark, Thanks for the review. Agree, accomodating in the driver is
easier and the inline function doesn't make much difference. I will
accomodate the change in the driver itself.

Shall I repost the series with these changes, which can be reviewed further
or wait for more review comments before reposting?

Regards,
Subhransu

--

[PATCH 5/7] drm/exynos/decon5433: fix DECON standalone update

2016-04-12 Thread Inki Dae

Hi Andrzej,

2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> DECON should be updated after un-protecting windows and after changing
> output parameters, otherwise image is not displayed in case of HDMI path.

I'm not sure why STANDALONE_UPDATE_F bit should be updated after un-protecting 
windows and changing output parameters.
The fields with _F prefix mean that these will be applied after vsync so we use 
protection window in case of all registers which affect display output so that 
they can be updated together.

Wouldn't there be other thing which affects HDMI output?

In addition, we would need another patch which updates TV relevant registers 
only in case of DECON-TV. DECON_UPDATE is a register for DECON-TV.

Thanks,
Inki Dae

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index ab9154e..7fec656 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -191,6 +191,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>  
>   /* enable output and display signal */
>   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
> +
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
> @@ -316,9 +318,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>  
>   /* window enable */
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
> -
> - /* standalone update */
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -336,9 +335,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
> *crtc,
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>  
>   decon_shadow_protect_win(ctx, win, false);
> -
> - /* standalone update */
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
> @@ -352,6 +348,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
> *crtc)
>   for (i = ctx->first_win; i < WINDOWS_NR; i++)
>   decon_shadow_protect_win(ctx, i, false);
>  
> + /* standalone update */
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> +
>   if (ctx->out_type == IFTYPE_I80)
>   set_bit(BIT_WIN_UPDATED, >flags);
>  }
> @@ -463,8 +462,10 @@ static void decon_clear_channels(struct exynos_drm_crtc 
> *crtc)
>   decon_shadow_protect_win(ctx, win, true);
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>   decon_shadow_protect_win(ctx, win, false);
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>   }
> +
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> +
>   /* TODO: wait for possible vsync */
>   msleep(50);
>  
>

[PATCH] drm/amdgpu: handle more than 10 UVD sessions (v2)

2016-04-12 Thread Alex Deucher

Applied, thanks!

Alex

On Tue, Apr 12, 2016 at 7:46 AM, Christian KÃ¶nig
 wrote:
> From: Arindam Nath 
>
> Change History
> --
>
> v2:
> - Make firmware version check correctly. Firmware
>   versions >= 1.80 should all support 40 UVD
>   instances.
> - Replace AMDGPU_MAX_UVD_HANDLES with max_handles
>   variable.
>
> v1:
> - The firmware can handle upto 40 UVD sessions.
>
> Signed-off-by: Arindam Nath 
> Signed-off-by: Ayyappa Chandolu 
> Reviewed-by: Christian KÃ¶nig 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h| 11 +---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 30 
> --
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |  5 ++--
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |  5 ++--
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  7 +++--
>  .../gpu/drm/amd/include/asic_reg/uvd/uvd_6_0_d.h   |  1 +
>  6 files changed, 41 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 36afabb..4805e45 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1592,16 +1592,19 @@ void amdgpu_get_pcie_info(struct amdgpu_device *adev);
>  /*
>   * UVD
>   */
> -#define AMDGPU_MAX_UVD_HANDLES 10
> -#define AMDGPU_UVD_STACK_SIZE  (1024*1024)
> -#define AMDGPU_UVD_HEAP_SIZE   (1024*1024)
> -#define AMDGPU_UVD_FIRMWARE_OFFSET 256
> +#define AMDGPU_DEFAULT_UVD_HANDLES 10
> +#define AMDGPU_MAX_UVD_HANDLES 40
> +#define AMDGPU_UVD_STACK_SIZE  (200*1024)
> +#define AMDGPU_UVD_HEAP_SIZE   (256*1024)
> +#define AMDGPU_UVD_SESSION_SIZE(50*1024)
> +#define AMDGPU_UVD_FIRMWARE_OFFSET 256
>
>  struct amdgpu_uvd {
> struct amdgpu_bo*vcpu_bo;
> void*cpu_addr;
> uint64_tgpu_addr;
> void*saved_bo;
> +   unsignedmax_handles;
> atomic_thandles[AMDGPU_MAX_UVD_HANDLES];
> struct drm_file *filp[AMDGPU_MAX_UVD_HANDLES];
> struct delayed_work idle_work;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 338da80..76ebc10 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -151,6 +151,9 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
> return r;
> }
>
> +   /* Set the default UVD handles that the firmware can handle */
> +   adev->uvd.max_handles = AMDGPU_DEFAULT_UVD_HANDLES;
> +
> hdr = (const struct common_firmware_header *)adev->uvd.fw->data;
> family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
> version_major = (le32_to_cpu(hdr->ucode_version) >> 24) & 0xff;
> @@ -158,8 +161,19 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
> DRM_INFO("Found UVD firmware Version: %hu.%hu Family ID: %hu\n",
> version_major, version_minor, family_id);
>
> +   /*
> +* Limit the number of UVD handles depending on microcode major
> +* and minor versions. The firmware version which has 40 UVD
> +* instances support is 1.80. So all subsequent versions should
> +* also have the same support.
> +*/
> +   if ((version_major > 0x01) ||
> +   ((version_major == 0x01) && (version_minor >= 0x50)))
> +   adev->uvd.max_handles = AMDGPU_MAX_UVD_HANDLES;
> +
> bo_size = AMDGPU_GPU_PAGE_ALIGN(le32_to_cpu(hdr->ucode_size_bytes) + 
> 8)
> -+  AMDGPU_UVD_STACK_SIZE + AMDGPU_UVD_HEAP_SIZE;
> + +  AMDGPU_UVD_STACK_SIZE + AMDGPU_UVD_HEAP_SIZE
> + +  AMDGPU_UVD_SESSION_SIZE * adev->uvd.max_handles;
> r = amdgpu_bo_create(adev, bo_size, PAGE_SIZE, true,
>  AMDGPU_GEM_DOMAIN_VRAM,
>  AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
> @@ -202,7 +216,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
> return r;
> }
>
> -   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i) {
> +   for (i = 0; i < adev->uvd.max_handles; ++i) {
> atomic_set(>uvd.handles[i], 0);
> adev->uvd.filp[i] = NULL;
> }
> @@ -248,7 +262,7 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
> if (adev->uvd.vcpu_bo == NULL)
> return 0;
>
> -   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i)
> +   for (i = 0; i < adev->uvd.max_handles; ++i)
> if (atomic_read(>uvd.handles[i]))
> break;
>
> @@ -303,7 +317,7 @@ void amdgpu_uvd_free_handles(struct amdgpu_device *adev, 
> struct drm_file *filp)
> struct amdgpu_ring *ring = >uvd.ring;
> int i, r;
>
> -   for (i = 0; i < AMDGPU_MAX_UVD_HANDLES; ++i) {
> +   for (i = 0; i < adev->uvd.max_handles; ++i) {
>

[RESEND] fence: add missing descriptions for fence

2016-04-12 Thread Sumit Semwal

Hi Luis,


On 12 April 2016 at 04:03, Luis de Bethencourt  
wrote:
> On 11/04/16 21:09, Gustavo Padovan wrote:
>> Hi Luis,
>>
>> 2016-04-11 Luis de Bethencourt :
>>
>>> The members child_list and active_list were added to the fence struct
>>> without descriptions for the Documentation. Adding these.
>>>
Thanks for the patch; will get it queued for for-next.

>>> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
>>> Signed-off-by: Luis de Bethencourt 
>>> Reviewed-by: Javier Martinez Canillas 
>>> ---
>>> Hi,
>>>
>>> Just resending this patch since it hasn't had any reviews in since
>>> March 21st.
>>>
>>> Thanks,
>>> Luis
>>>
>>>  include/linux/fence.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>
>> Reviewed-by: Gustavo Padovan 
>>
>>   Gustavo
>>
>
> Thank you Gustavo.
>
> Nice seeing you around here :)
>
> Luis

BR,
Sumit.

[PATCH RFC 09/11] drm/tilcdc: Set DRIVER_ATOMIC and use atomic crtc helpers

2016-04-12 Thread Jyri Sarha

On 04/11/16 19:46, Jyri Sarha wrote:
> Set DRIVER_ATOMIC and use atomic helpers and rename commit and prepare
> crtc helpers to enable and disable. This makes the final jump to mode
> setting, but there is lot of obsolete code to clean up.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 16 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 69045d8..e8e309e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -17,6 +17,7 @@
>  
>  #include "drm_flip_work.h"
>  #include 
> +#include 
>  
>  #include "tilcdc_drv.h"
>  #include "tilcdc_regs.h"
> @@ -300,12 +301,12 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc 
> *crtc,
>   return true;
>  }
>  
> -static void tilcdc_crtc_prepare(struct drm_crtc *crtc)
> +static void tilcdc_crtc_disable(struct drm_crtc *crtc)
>  {
>   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
>  }
>  
> -static void tilcdc_crtc_commit(struct drm_crtc *crtc)
> +static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>  {
>   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>  }
> @@ -713,9 +714,12 @@ static int tilcdc_crtc_mode_set_base(struct drm_crtc 
> *crtc, int x, int y,
>  }
>  
>  static const struct drm_crtc_funcs tilcdc_crtc_funcs = {
> - .destroy= tilcdc_crtc_destroy,
> - .set_config = drm_crtc_helper_set_config,
> - .page_flip  = tilcdc_crtc_page_flip,
> + .destroy= tilcdc_crtc_destroy,
> + .set_config = drm_atomic_helper_set_config,
> + .page_flip  = drm_atomic_helper_page_flip,
> + .reset  = drm_atomic_helper_crtc_reset,
> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>  };
>  
>  static const struct drm_crtc_helper_funcs tilcdc_crtc_helper_funcs = {
> @@ -725,6 +729,8 @@ static const struct drm_crtc_helper_funcs 
> tilcdc_crtc_helper_funcs = {
>   .commit = tilcdc_crtc_commit,
Oops, I made a compile breakage here in the last phase. The
tilcdc_crtc_commit () and tilcdc_crtc_preapre() above were renamed to
*enable() and *disable(). I'll fix that in the next round.

>   .mode_set   = tilcdc_crtc_mode_set,
>   .mode_set_base  = tilcdc_crtc_mode_set_base,
> + .enable = tilcdc_crtc_enable,
> + .disable= tilcdc_crtc_disable,
>   .atomic_check   = tilcdc_crtc_atomic_check,
>   .mode_set_nofb  = tilcdc_crtc_mode_set_nofb,
>  };
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index dc0d1e9..6569d3a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -587,7 +587,7 @@ static const struct file_operations fops = {
>  
>  static struct drm_driver tilcdc_driver = {
>   .driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
> -DRIVER_PRIME),
> +DRIVER_PRIME | DRIVER_ATOMIC),
>   .load   = tilcdc_load,
>   .unload = tilcdc_unload,
>   .lastclose  = tilcdc_lastclose,
>

[PATCH 02/11] drm/edid: Add API to get speaker allocation

2016-04-12 Thread Subhransu S. Prusty

Signed-off-by: Subhransu S. Prusty 
Signed-off-by: Vinod Koul 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter 
---
 include/drm/drm_edid.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index dec6221..99142d1 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -415,6 +415,15 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
 }

+/**
+ * drm_eld_get_spk_alloc - Get ELD speaker allocation
+ * @eld: pointer to an eld memory structure
+ */
+static inline const u8 drm_eld_get_spk_alloc(const uint8_t *eld)
+{
+   return eld[DRM_ELD_SPEAKER];
+}
+
 struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
  size_t len),
-- 
1.9.1

[PATCH 00/11] ASoC: hdac_hdmi: Add multichannel support

2016-04-12 Thread Subhransu S. Prusty

This series parses ELD to identify multichannel capability of the
sync, and uses HDA framework to programs codec's channel map
registers.

Channel map controls are registered in patch 8, with which user
can specify a specific channel order. chmap controls are
registered inside jack_init callback. As PCMs need to be
registered before registering chmap controls, jack_init call in
the machine driver is moved to late_probe instead of init
callback.

Skylake driver is modified and buffer size calculation is fixed
for multichannel support.

Please note, patch 2 and 4 adds small macros to read speaker
allocation from ELD and channel counts from cap bits respectively
in DRM and HDA headers.  We have CCed DRM folks here. Please ack
patch 1, so that we can have this series merged through sound
trees. Patch 3 needs Takashi's ack, so that it can be merged
through ASoC.

Patch 9 has dependency on commit#44fde3b ("ALSA: hda - Update
chmap tlv to report sink's capability) which is merged in
Takashi's tree.

So this may be merged in ASoC with Takashi's Ack and pulling in
changes from Takashi's tree or alternatively it can be directly
merged in Takashi's with Mark's Ack

Takashi/Mark, please decide how you guys want this to be merged. 

Cc: Jani Nikula 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter 

Subhransu S. Prusty (11):
  ASoC: Intel: Skylake: Fix ibs/obs calc for non-integral sampling rates
  drm/edid: Add API to get speaker allocation
  ASoC: hdac_hdmi: parse eld for channel map capability
  ALSA: hda - add helper to get channels from cap bits
  ASoC: hdac_hdmi: Add multichannel support
  ASoC: skl_rt286: Fix to support hdmi channel map support
  ASoC: Intel: boards: Update skl_nau88l25_max98357a driver to support
chmap
  ASoC: Intel: boards: Update skl_nau88l25_ssm4567 driver to support
chmap
  ASoC: hdac_hdmi: Register chmap controls and ops
  ASoC: Intel: Skylake: Add multichannel support for HDMI
  ASoC: Intel: Skylake: Update channel map based on runtime params

 include/drm/drm_edid.h  |   9 ++
 sound/hda/local.h   |  10 ++
 sound/soc/codecs/hdac_hdmi.c| 165 ++--
 sound/soc/intel/boards/skl_nau88l25_max98357a.c |  74 ++-
 sound/soc/intel/boards/skl_nau88l25_ssm4567.c   |  73 ++-
 sound/soc/intel/boards/skl_rt286.c  |  48 ++-
 sound/soc/intel/skylake/skl-pcm.c   |  14 +-
 sound/soc/intel/skylake/skl-topology.c  |  49 +--
 8 files changed, 409 insertions(+), 33 deletions(-)

-- 
1.9.1

[PATCH] drm/exynos: clean up register definions for fimd and decon

2016-04-12 Thread Inki Dae

This patch removes suffixes from I80 relevant register definitions,
which are misleading.

This is based on top of below patch set,
 http://www.spinics.net/lists/dri-devel/msg104057.html

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 23 +++
 include/video/exynos5433_decon.h  |  6 +++---
 3 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5922e99..8cfef0d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -121,7 +121,7 @@ static void decon_setup_trigger(struct decon_context *ctx)
? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
  TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
- TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
+ TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
writel(val, ctx->addr + DECON_TRIGCON);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index c4cd16a..9fa07a6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -68,15 +68,15 @@
 /* color key value register for hardware window 1 ~ 4. */
 #define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))

-/* I80 / RGB trigger control register */
+/* I80 trigger control register */
 #define TRIGCON0x1A4
-#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
-#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+#define TRGMODE_ENABLE (1 << 0)
+#define SWTRGCMD_ENABLE(1 << 1)
 /* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
-#define HWTRGEN_I80_RGB_ENABLE (1 << 3)
-#define HWTRGMASK_I80_RGB_ENABLE   (1 << 4)
+#define HWTRGEN_ENABLE (1 << 3)
+#define HWTRGMASK_ENABLE   (1 << 4)
 /* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
-#define HWTRIGEN_PER_RGB_ENABLE(1 << 31)
+#define HWTRIGEN_PER_ENABLE(1 << 31)

 /* display mode change control register except exynos4 */
 #define VIDOUT_CON 0x000
@@ -425,16 +425,15 @@ static void fimd_setup_trigger(struct fimd_context *ctx)
u32 trg_type = ctx->driver_data->trg_type;
u32 val = readl(timing_base + TRIGCON);

-   val &= ~(TRGMODE_I80_RGB_ENABLE_I80);
+   val &= ~(TRGMODE_ENABLE);

if (trg_type == I80_HW_TRG) {
if (ctx->driver_data->has_hw_trigger)
-   val |= HWTRGEN_I80_RGB_ENABLE |
-   HWTRGMASK_I80_RGB_ENABLE;
+   val |= HWTRGEN_ENABLE | HWTRGMASK_ENABLE;
if (ctx->driver_data->has_trigger_per_te)
-   val |= HWTRIGEN_PER_RGB_ENABLE;
+   val |= HWTRIGEN_PER_ENABLE;
} else {
-   val |= TRGMODE_I80_RGB_ENABLE_I80;
+   val |= TRGMODE_ENABLE;
}

writel(val, timing_base + TRIGCON);
@@ -884,7 +883,7 @@ static void fimd_trigger(struct device *dev)
atomic_set(>triggering, 1);

reg = readl(timing_base + TRIGCON);
-   reg |= (TRGMODE_I80_RGB_ENABLE_I80 | SWTRGCMD_I80_RGB_ENABLE);
+   reg |= (TRGMODE_ENABLE | SWTRGCMD_ENABLE);
writel(reg, timing_base + TRIGCON);

/*
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index c1c1ca1..0098a52 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -179,9 +179,9 @@
 #define TRIGCON_TRIGMODE_W1BUF (1 << 10)
 #define TRIGCON_SWTRIGCMD_W0BUF(1 << 6)
 #define TRIGCON_TRIGMODE_W0BUF (1 << 5)
-#define TRIGCON_HWTRIGMASK_I80_RGB (1 << 4)
-#define TRIGCON_HWTRIGEN_I80_RGB   (1 << 3)
-#define TRIGCON_HWTRIG_INV_I80_RGB (1 << 2)
+#define TRIGCON_HWTRIGMASK (1 << 4)
+#define TRIGCON_HWTRIGEN   (1 << 3)
+#define TRIGCON_HWTRIG_INV (1 << 2)
 #define TRIGCON_SWTRIGCMD  (1 << 1)
 #define TRIGCON_SWTRIGEN   (1 << 0)

-- 
1.9.1

[PATCH] drm: rcar-du: Only unwindow as necessary on probe failure

2016-04-12 Thread Geert Uytterhoeven

Hi Sjoerd,

On Wed, Apr 6, 2016 at 11:45 AM, Sjoerd Simons
 wrote:
> Simply calling rcar_du_remove on any error can cause unbalanced calls to
> various functions (e.g. drm_connector_register/unregister,
> drm_dev_register/drm_dev_unref).
>
> This can be seen at bootup of my Porter boards with current next:
>
> [2.789322] rcar-du feb0.display: failed to initialize DRM/KMS (-517)
> [2.796267] [ cut here ]
> [2.800996] WARNING: CPU: 1 PID: 1 at include/drm/drm_crtc.h:2623 
> drm_connector_unregister_all+0x60/0x68
> [2.810689] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
> 4.6.0-rc2-next-20160405-dirty #11
> [2.818864] Hardware name: Generic R8A7791 (Flattened Device Tree)
> [2.825174] Backtrace:
> [2.827699] [] (dump_backtrace) from [] 
> (show_stack+0x18/0x1c)
> [2.835430]  r7:c042da78 r6:0009 r5:6013 r4:
> [2.841251] [] (show_stack) from [] 
> (dump_stack+0x84/0xa4)
> [2.848632] [] (dump_stack) from [] (__warn+0xd0/0x100)
> [2.855739]  r5: r4:
> [2.859409] [] (__warn) from [] 
> (warn_slowpath_null+0x28/0x30)
> [2.867139]  r9:0001 r8:ef1dc610 r7:ef114010 r6:ef1dc600 r5:ef114010 
> r4:ef2f2400
> [2.875096] [] (warn_slowpath_null) from [] 
> (drm_connector_unregister_all+0x60/0x68)
> [2.884785] [] (drm_connector_unregister_all) from [] 
> (rcar_du_remove+0x1c/0x5c)
> [2.894111]  r5:ef114010 r4:ef2f2400
> [2.897780] [] (rcar_du_remove) from [] 
> (rcar_du_probe+0x1d0/0x210)
> [2.905953]  r5:ef2f2400 r4:fdfb
> [2.909625] [] (rcar_du_probe) from [] 
> (platform_drv_probe+0x58/0xa8)
> [2.917976]  r9: r8:c0a1cca4 r7:c0a71a48 r6:c0a1cca4 r5:ef1dc610 
> r4:c0440b80
>
> Adjust the code to only unwind as necessary on probe failures
>
> Signed-off-by: Sjoerd Simons 

Thanks!

I can confirm your patch fixes the same warning on r8a7791/koelsch, so
I'll include it in today's renesas-drivers release.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae

Hi Andrzej,

2016ë 04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>  Hi Andrzej,
> 
> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>> Hi Inki,
>>
>> On 04/05/2016 10:27 AM, Inki Dae wrote:
>>> This patch cleans up interface type relevant codes.
>>>
>>> Trigger mode is determinded only by i80 mode, which isn't
>>> related to Display types - HDMI or Display controller.
>>> So this patch makes the trigger mode to be set only in case of
>>> i80 mode.
>>
>> With this patch HDMI path image has serious synchronization problems.
>> Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
>> signal which works as a hardware trigger for DECON-TV, so I guess
>> trigger is required.
> 
> Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.

Looks considered already. for DECON-TV, I80_HW_TRG flag is used mandatorily,
.compatible = "samsung,exynos5433-decon-tv",
.data = (void *)(I80_HW_TRG | IFTYPE_HDMI)

>>
>> Btw, I think it could be good to remove suffixes I80_RGV from
>> TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
>> misleading and differ from documentation.
> 
> Indeed. Looked strange when I wrote the suffixes.

will send another cleanup patch.

Thanks,
Inki Dae

> 
>>
>> As far as I have tested I80 mode works OK on Decon5433.
> 
> Thanks for testing.
> Inki Dae
> 
>>
>> Regards
>> Andrzej
>>
>>>
>>> Signed-off-by: Inki Dae 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
>>> ++-
>>>  1 file changed, 27 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index 5245bc5..5922e99 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -28,6 +28,10 @@
>>>  #define WINDOWS_NR   3
>>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>>>
>>> +#define IFTYPE_I80   (1 << 0)
>>> +#define I80_HW_TRG   (1 << 1)
>>> +#define IFTYPE_HDMI  (1 << 2)
>>> +
>>>  static const char * const decon_clks_name[] = {
>>>   "pclk",
>>>   "aclk_decon",
>>> @@ -38,12 +42,6 @@ static const char * const decon_clks_name[] = {
>>>   "sclk_decon_eclk",
>>>  };
>>>
>>> -enum decon_iftype {
>>> - IFTYPE_RGB,
>>> - IFTYPE_I80,
>>> - IFTYPE_HDMI
>>> -};
>>> -
>>>  enum decon_flag_bits {
>>>   BIT_CLKS_ENABLED,
>>>   BIT_IRQS_ENABLED,
>>> @@ -61,7 +59,7 @@ struct decon_context {
>>>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>>>   int pipe;
>>>   unsigned long   flags;
>>> - enum decon_iftype   out_type;
>>> + unsigned intout_type;
>>>   int first_win;
>>>  };
>>>
>>> @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
>>> *crtc)
>>>
>>>   if (!test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
>>>   val = VIDINTCON0_INTEN;
>>> - if (ctx->out_type == IFTYPE_I80)
>>> + if (ctx->out_type & IFTYPE_I80)
>>>   val |= VIDINTCON0_FRAMEDONE;
>>>   else
>>>   val |= VIDINTCON0_INTFRMEN;
>>> @@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
>>> *crtc)
>>>
>>>  static void decon_setup_trigger(struct decon_context *ctx)
>>>  {
>>> - u32 val = (ctx->out_type != IFTYPE_HDMI)
>>> + u32 val = !(ctx->out_type & I80_HW_TRG)
>>>   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>>   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> @@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>   if (test_bit(BIT_SUSPENDED, >flags))
>>>   return;
>>>
>>> - if (ctx->out_type == IFTYPE_HDMI) {
>>> + if (ctx->out_type & IFTYPE_HDMI) {
>>>   m->crtc_hsync_start = m->crtc_hdisplay + 10;
>>>   m->crtc_hsync_end = m->crtc_htotal - 92;
>>>   m->crtc_vsync_start = m->crtc_vdisplay + 1;
>>> @@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>
>>>   /* lcd on and use command if */
>>>   val = VIDOUT_LCD_ON;
>>> - if (ctx->out_type == IFTYPE_I80)
>>> + if (ctx->out_type & IFTYPE_I80) {
>>>   val |= VIDOUT_COMMAND_IF;
>>> - else
>>> + decon_setup_trigger(ctx);
>>> + } else {
>>>   val |= VIDOUT_RGB_IF;
>>> + }
>>> +
>>>   writel(val, ctx->addr + DECON_VIDOUTCON0);
>>>
>>>   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
>>>   VIDTCON2_HOZVAL(m->hdisplay - 1);
>>>   writel(val, ctx->addr + DECON_VIDTCON2);
>>>
>>> - if (ctx->out_type != IFTYPE_I80) {
>>> + if (!(ctx->out_type & IFTYPE_I80)) {
>>>   val = VIDTCON00_VBPD_F(
>>>   m->crtc_vtotal - m->crtc_vsync_end -

[PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

2016-04-12 Thread Shawn Guo

On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
> mixes the bus clock with the display controllers pixel clock. Tests
> have shown that the gates in CCM_CCGR3/9 registers do not control
> the DCU pixel clock, but only the register access clock (bus clock).
> 
> Fix this by defining the parent clock of VF610_CLK_DCUx to be the bus
> clock (ipg_bus).
> 
> Since the clock has not been used far, there are no further changes
> needed.
> 
> Signed-off-by: Stefan Agner 

Applied 1 and 2, with updating subject prefix to be 'clk: imx: vf610: '

Shawn

> ---
>  drivers/clk/imx/clk-vf610.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> index 0a94d96..426fde2 100644
> --- a/drivers/clk/imx/clk-vf610.c
> +++ b/drivers/clk/imx/clk-vf610.c
> @@ -321,11 +321,11 @@ static void __init vf610_clocks_init(struct device_node 
> *ccm_node)
>   clk[VF610_CLK_DCU0_SEL] = imx_clk_mux("dcu0_sel", CCM_CSCMR1, 28, 1, 
> dcu_sels, 2);
>   clk[VF610_CLK_DCU0_EN] = imx_clk_gate("dcu0_en", "dcu0_sel", 
> CCM_CSCDR3, 19);
>   clk[VF610_CLK_DCU0_DIV] = imx_clk_divider("dcu0_div", "dcu0_en", 
> CCM_CSCDR3, 16, 3);
> - clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "dcu0_div", CCM_CCGR3, 
> CCM_CCGRx_CGn(8));
> + clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "ipg_bus", CCM_CCGR3, 
> CCM_CCGRx_CGn(8));
>   clk[VF610_CLK_DCU1_SEL] = imx_clk_mux("dcu1_sel", CCM_CSCMR1, 29, 1, 
> dcu_sels, 2);
>   clk[VF610_CLK_DCU1_EN] = imx_clk_gate("dcu1_en", "dcu1_sel", 
> CCM_CSCDR3, 23);
>   clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", 
> CCM_CSCDR3, 20, 3);
> - clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, 
> CCM_CCGRx_CGn(8));
> + clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "ipg_bus", CCM_CCGR9, 
> CCM_CCGRx_CGn(8));
>  
>   clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, 
> esai_sels, 4);
>   clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", 
> CCM_CSCDR2, 30);
> -- 
> 2.7.4
> 
>

[PATCH 5/7] drm/exynos/decon5433: fix DECON standalone update

2016-04-12 Thread Andrzej Hajda

On 04/12/2016 04:25 AM, Inki Dae wrote:
> Hi Andrzej,
>
> 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> DECON should be updated after un-protecting windows and after changing
>> output parameters, otherwise image is not displayed in case of HDMI path.
> I'm not sure why STANDALONE_UPDATE_F bit should be updated after 
> un-protecting windows and changing output parameters.
> The fields with _F prefix mean that these will be applied after vsync so we 
> use protection window in case of all registers which affect display output so 
> that they can be updated together.
>
> Wouldn't there be other thing which affects HDMI output?
>
> In addition, we would need another patch which updates TV relevant registers 
> only in case of DECON-TV. DECON_UPDATE is a register for DECON-TV.

DECON_UPDATE is present in both DECON and DECON-TV and in both cases
have the same field STANDALONE_UPDATE_F.

Documentation for 5433 says:
> When you modify the shadow attributed registers, set
> STANDALONE_UPDATE_F.
>
So it should be set after setting registers with _F suffix,
but it has also _F suffix - contradiction. So I guess this _F suffix
should not be treated too strictly in this case. Moreover the suffix
has been removed in Exynos7420 - it is called just STANDALONE_UPDATE.

Anyway I am not sure what is exact purpose of this register and
the changes proposed in the patch are rather results of multiple tests
with hardware - documentation is rather poor on this subject.

I am also not sure why DECON works without it but DECON-TV does not,
anyway I set it in both variants because documentation says so.

Regards
Andrzej

>
> Thanks,
> Inki Dae
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 15 ---
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index ab9154e..7fec656 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -191,6 +191,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>  
>>  /* enable output and display signal */
>>  decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
>> +
>> +decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>  }
>>  
>>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int 
>> win,
>> @@ -316,9 +318,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
>> *crtc,
>>  
>>  /* window enable */
>>  decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
>> -
>> -/* standalone update */
>> -decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>  }
>>  
>>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
>> @@ -336,9 +335,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
>> *crtc,
>>  decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>  
>>  decon_shadow_protect_win(ctx, win, false);
>> -
>> -/* standalone update */
>> -decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>  }
>>  
>>  static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
>> @@ -352,6 +348,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
>> *crtc)
>>  for (i = ctx->first_win; i < WINDOWS_NR; i++)
>>  decon_shadow_protect_win(ctx, i, false);
>>  
>> +/* standalone update */
>> +decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>> +
>>  if (ctx->out_type == IFTYPE_I80)
>>  set_bit(BIT_WIN_UPDATED, >flags);
>>  }
>> @@ -463,8 +462,10 @@ static void decon_clear_channels(struct exynos_drm_crtc 
>> *crtc)
>>  decon_shadow_protect_win(ctx, win, true);
>>  decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>  decon_shadow_protect_win(ctx, win, false);
>> -decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>  }
>> +
>> +decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>> +
>>  /* TODO: wait for possible vsync */
>>  msleep(50);
>>  
>>

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-12 Thread Andrzej Hajda

Hi Inki,

On 04/12/2016 02:40 AM, Inki Dae wrote:
> Hi Andrzej,
>
> 2016ë 04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>>  Hi Andrzej,
>>
>> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>>> Hi Inki,
>>>
>>> On 04/05/2016 10:27 AM, Inki Dae wrote:
 This patch cleans up interface type relevant codes.

 Trigger mode is determinded only by i80 mode, which isn't
 related to Display types - HDMI or Display controller.
 So this patch makes the trigger mode to be set only in case of
 i80 mode.
>>> With this patch HDMI path image has serious synchronization problems.
>>> Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
>>> signal which works as a hardware trigger for DECON-TV, so I guess
>>> trigger is required.
>> Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.
> Looks considered already. for DECON-TV, I80_HW_TRG flag is used mandatorily,
>   .compatible = "samsung,exynos5433-decon-tv",
>   .data = (void *)(I80_HW_TRG | IFTYPE_HDMI)
Here it is OK, but there are other changes, see below for more details.
>
>>> Btw, I think it could be good to remove suffixes I80_RGV from
>>> TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
>>> misleading and differ from documentation.
>> Indeed. Looked strange when I wrote the suffixes.
> will send another cleanup patch.
>
> Thanks,
> Inki Dae
>
>>> As far as I have tested I80 mode works OK on Decon5433.
>> Thanks for testing.
>> Inki Dae
>>
>>> Regards
>>> Andrzej
>>>
 Signed-off-by: Inki Dae 
 ---
  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
 ++-
  1 file changed, 27 insertions(+), 26 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
 b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 index 5245bc5..5922e99 100644
 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 @@ -28,6 +28,10 @@
  #define WINDOWS_NR   3
  #define MIN_FB_WIDTH_FOR_16WORD_BURST128

 +#define IFTYPE_I80   (1 << 0)
 +#define I80_HW_TRG   (1 << 1)
 +#define IFTYPE_HDMI  (1 << 2)
 +
  static const char * const decon_clks_name[] = {
   "pclk",
   "aclk_decon",
 @@ -38,12 +42,6 @@ static const char * const decon_clks_name[] = {
   "sclk_decon_eclk",
  };

 -enum decon_iftype {
 - IFTYPE_RGB,
 - IFTYPE_I80,
 - IFTYPE_HDMI
 -};
 -
  enum decon_flag_bits {
   BIT_CLKS_ENABLED,
   BIT_IRQS_ENABLED,
 @@ -61,7 +59,7 @@ struct decon_context {
   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
   int pipe;
   unsigned long   flags;
 - enum decon_iftype   out_type;
 + unsigned intout_type;
   int first_win;
  };

 @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
 *crtc)

   if (!test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
   val = VIDINTCON0_INTEN;
 - if (ctx->out_type == IFTYPE_I80)
 + if (ctx->out_type & IFTYPE_I80)
   val |= VIDINTCON0_FRAMEDONE;
   else
   val |= VIDINTCON0_INTFRMEN;
 @@ -119,7 +117,7 @@ static void decon_disable_vblank(struct 
 exynos_drm_crtc *crtc)

  static void decon_setup_trigger(struct decon_context *ctx)
  {
 - u32 val = (ctx->out_type != IFTYPE_HDMI)
 + u32 val = !(ctx->out_type & I80_HW_TRG)
   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
 TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
 @@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
   if (test_bit(BIT_SUSPENDED, >flags))
   return;

 - if (ctx->out_type == IFTYPE_HDMI) {
 + if (ctx->out_type & IFTYPE_HDMI) {
   m->crtc_hsync_start = m->crtc_hdisplay + 10;
   m->crtc_hsync_end = m->crtc_htotal - 92;
   m->crtc_vsync_start = m->crtc_vdisplay + 1;
 @@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc 
 *crtc)

   /* lcd on and use command if */
   val = VIDOUT_LCD_ON;
 - if (ctx->out_type == IFTYPE_I80)
 + if (ctx->out_type & IFTYPE_I80) {
   val |= VIDOUT_COMMAND_IF;
 - else
 + decon_setup_trigger(ctx);
 + } else {
   val |= VIDOUT_RGB_IF;
 + }
 +
   writel(val, ctx->addr + DECON_VIDOUTCON0);

   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
   VIDTCON2_HOZVAL(m->hdisplay - 1);
   writel(val,

[PATCH 00/11] ASoC: hdac_hdmi: Add multichannel support

2016-04-12 Thread Takashi Iwai

On Tue, 12 Apr 2016 07:01:22 +0200,
Subhransu S. Prusty wrote:
> 
> This series parses ELD to identify multichannel capability of the
> sync, and uses HDA framework to programs codec's channel map
> registers.
> 
> Channel map controls are registered in patch 8, with which user
> can specify a specific channel order. chmap controls are
> registered inside jack_init callback. As PCMs need to be
> registered before registering chmap controls, jack_init call in
> the machine driver is moved to late_probe instead of init
> callback.
> 
> Skylake driver is modified and buffer size calculation is fixed
> for multichannel support.
> 
> Please note, patch 2 and 4 adds small macros to read speaker
> allocation from ELD and channel counts from cap bits respectively
> in DRM and HDA headers.  We have CCed DRM folks here. Please ack
> patch 1, so that we can have this series merged through sound
> trees. Patch 3 needs Takashi's ack, so that it can be merged
> through ASoC.
> 
> Patch 9 has dependency on commit#44fde3b ("ALSA: hda - Update
> chmap tlv to report sink's capability) which is merged in
> Takashi's tree.
> 
> So this may be merged in ASoC with Takashi's Ack and pulling in
> changes from Takashi's tree or alternatively it can be directly
> merged in Takashi's with Mark's Ack
> 
> Takashi/Mark, please decide how you guys want this to be merged. 

Mark needs to pull my for-next branch beforehand.
Or, Mark needs to send a pull request so that I pull Mark's tree, then
sync both before applying yours.

But the problem is more complicated because you're changing drm stuff,
too.  This is usually managed in drm tree.  So this cross over three
different trees.

And, the change in drm is only this:

> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -415,6 +415,15 @@ static inline u8 drm_eld_get_conn_type(const uint8_t 
> *eld)
>   return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
>  }
>  
> +/**
> + * drm_eld_get_spk_alloc - Get ELD speaker allocation
> + * @eld: pointer to an eld memory structure
> + */
> +static inline const u8 drm_eld_get_spk_alloc(const uint8_t *eld)
> +{
> + return eld[DRM_ELD_SPEAKER];
> +}

Do we really need this?  Even the direct reference is pretty much
obvious.  e.g. I see no big difference between two lines below:
spk_alloc = drm_eld_get_spk_alloc(some_eld);
spk_alloc = some_eld[DRM_ELD_SPAEKER];


thanks,

Takashi

[PATCH 00/11] ASoC: hdac_hdmi: Add multichannel support

2016-04-12 Thread Mark Brown

On Tue, Apr 12, 2016 at 11:56:11AM +0530, Subhransu S. Prusty wrote:

> Shall I repost the series with these changes, which can be reviewed further
> or wait for more review comments before reposting?

I don't mind.  I did already apply the first patch as a fix.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/bb32bec4/attachment.sig>

[PATCH] drm/amd/powerplay: make fiji command table constant.

2016-04-12 Thread Dave Airlie

On 12 April 2016 at 07:11, Dave Airlie  wrote:
> From: Dave Airlie 

Oh ignore these, I see Nils has sent some that do the same and a lot more!

Dave.

[PATCH] drm/amdgpu/powerplay: make fiji powertune defaults static const

2016-04-12 Thread Dave Airlie

From: Dave Airlie 

This makes these non-global and constant.

before:
1213447   182251532 1233204  12d134 drivers/gpu/drm/amd/amdgpu/amdgpu.ko
after:
1213447   181931532 1233172  12d114 drivers/gpu/drm/amd/amdgpu/amdgpu.ko

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_powertune.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h
index a16f7cd..d4d0c5e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.h
@@ -263,7 +263,7 @@ struct fiji_hwmgr {
bool   enable_tdc_limit_feature;
bool   enable_pkg_pwr_tracking_feature;
bool   disable_uvd_power_tune_feature;
-   struct fiji_pt_defaults   *power_tune_defaults;
+   const struct fiji_pt_defaults   *power_tune_defaults;
struct SMU73_Discrete_PmFuses  power_tune_table;
uint32_t   dte_tj_offset;
uint32_t   fast_watermark_threshold;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_powertune.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_powertune.c
index 6efcb2b..fbe21b2 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_powertune.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_powertune.c
@@ -32,7 +32,7 @@
 #define VOLTAGE_SCALE  4
 #define POWERTUNE_DEFAULT_SET_MAX1

-struct fiji_pt_defaults 
fiji_power_tune_data_set_array[POWERTUNE_DEFAULT_SET_MAX] = {
+static const struct fiji_pt_defaults 
fiji_power_tune_data_set_array[POWERTUNE_DEFAULT_SET_MAX] = {
/*sviLoadLIneEn,  SviLoadLineVddC, 
TDC_VDDC_ThrottleReleaseLimitPerc */
{1,   0xF, 0xFD,
/* TDC_MAWt, TdcWaterfallCtl, DTEAmbientTempBase */
@@ -143,7 +143,7 @@ static void get_scl_sda_value(uint8_t line, uint8_t *scl, 
uint8_t* sda)
 int fiji_populate_bapm_parameters_in_dpm_table(struct pp_hwmgr *hwmgr)
 {
struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
-   struct fiji_pt_defaults *defaults = data->power_tune_defaults;
+   const struct fiji_pt_defaults *defaults = data->power_tune_defaults;
SMU73_Discrete_DpmTable  *dpm_table = &(data->smc_state_table);
struct phm_ppt_v1_information *table_info =
(struct phm_ppt_v1_information *)(hwmgr->pptable);
@@ -222,7 +222,7 @@ int fiji_populate_bapm_parameters_in_dpm_table(struct 
pp_hwmgr *hwmgr)
 static int fiji_populate_svi_load_line(struct pp_hwmgr *hwmgr)
 {
 struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
-struct fiji_pt_defaults *defaults = data->power_tune_defaults;
+const struct fiji_pt_defaults *defaults = data->power_tune_defaults;

 data->power_tune_table.SviLoadLineEn = defaults->SviLoadLineEn;
 data->power_tune_table.SviLoadLineVddC = defaults->SviLoadLineVddC;
@@ -238,7 +238,7 @@ static int fiji_populate_tdc_limit(struct pp_hwmgr *hwmgr)
struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
struct phm_ppt_v1_information *table_info =
(struct phm_ppt_v1_information *)(hwmgr->pptable);
-   struct  fiji_pt_defaults *defaults = data->power_tune_defaults;
+   const struct  fiji_pt_defaults *defaults = data->power_tune_defaults;

/* TDC number of fraction bits are changed from 8 to 7
 * for Fiji as requested by SMC team
@@ -256,7 +256,7 @@ static int fiji_populate_tdc_limit(struct pp_hwmgr *hwmgr)
 static int fiji_populate_dw8(struct pp_hwmgr *hwmgr, uint32_t 
fuse_table_offset)
 {
struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
-   struct  fiji_pt_defaults *defaults = data->power_tune_defaults;
+   const struct  fiji_pt_defaults *defaults = data->power_tune_defaults;
uint32_t temp;

if (fiji_read_smc_sram_dword(hwmgr->smumgr,
-- 
2.5.5

[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

Edwin Smith  changed:

   What|Removed |Added

 Resolution|NOTOURBUG   |FIXED
 Status|RESOLVED|VERIFIED

--- Comment #12 from Edwin Smith  ---
Marking as FIXED as the issue was resolved on the client side in 2014

-- 
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/20160412/c3b72c87/attachment.html>

[PATCH] drm/amd/powerplay: make fiji command table constant.

2016-04-12 Thread Dave Airlie

From: Dave Airlie 

On my otherly hacked up kernel module this does:
1090519  1411691532 1233220  12d144 drivers/gpu/drm/amd/amdgpu/amdgpu.ko

1213447   182251532 1233204  12d134 drivers/gpu/drm/amd/amdgpu/amdgpu.ko

clearly having less data is better.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h  | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h 
b/drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h
index 0262ad3..8a31665 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/fiji_pwrvirus.h
@@ -46,7 +46,7 @@ struct PWR_Command_Table
 typedef struct PWR_Command_Table PWR_Command_Table;

 #define PWR_VIRUS_TABLE_SIZE  10243
-static PWR_Command_Table PwrVirusTable[PWR_VIRUS_TABLE_SIZE] =
+static const PWR_Command_Table PwrVirusTable[PWR_VIRUS_TABLE_SIZE] =
 {
 { PwrCmdWrite, 0x100100b6, mmPCIE_INDEX   },
 { PwrCmdWrite, 0x, mmPCIE_DATA},
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
index cdbb9f8..070f2a2 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
@@ -665,7 +665,7 @@ int fiji_setup_pwr_virus(struct pp_smumgr *smumgr)
 {
int i, result = -1;
uint32_t reg, data;
-   PWR_Command_Table *virus = PwrVirusTable;
+   const PWR_Command_Table *virus = PwrVirusTable;
struct fiji_smumgr *priv = (struct fiji_smumgr *)(smumgr->backend);

priv->avfs.AvfsBtcStatus = AVFS_LOAD_VIRUS;
-- 
2.5.5

[PATCH 00/11] ASoC: hdac_hdmi: Add multichannel support

2016-04-12 Thread Mark Brown

On Tue, Apr 12, 2016 at 07:43:59AM +0200, Takashi Iwai wrote:

> But the problem is more complicated because you're changing drm stuff,
> too.  This is usually managed in drm tree.  So this cross over three
> different trees.

The DRM folks tend to leave this up to us, or at least review on any of
these crossover patches has been extremely light.

> Do we really need this?  Even the direct reference is pretty much
> obvious.  e.g. I see no big difference between two lines below:
>   spk_alloc = drm_eld_get_spk_alloc(some_eld);
>   spk_alloc = some_eld[DRM_ELD_SPAEKER];

That'd make things even easier of course.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/1eb22089/attachment.sig>

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from John Galt  ---
Created attachment 122877
  --> https://bugs.freedesktop.org/attachment.cgi?id=122877=edit
Dmesg of video playback with skipped vblanks with
/sys/module/drm/parameters/debug set to 63 then 0 afterward.

-- 
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/20160412/683a84ce/attachment.html>

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Michel Dï¿½nzer  ---
Please write 63 to /sys/module/drm/parameters/debug before reproducing the
problem and 0 again afterwards, then attach the dmesg output generated in
between.

-- 
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/20160412/3565e9d7/attachment.html>

i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

2016-04-12 Thread Florian Zumbiehl

Hi,

> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
> 
> Not quite completely, it seems ...
> 
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]

ping?

Regards, Florian

[Bug 94903] Tahiti and Hawaii (without amdgpu support) skips vblanks on wayland (weston and others) on some displays.

2016-04-12 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 94903
Summary: Tahiti and Hawaii (without amdgpu support) skips
vblanks on wayland (weston and others) on some
displays.
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: johngaltfirstrun at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

When running weston on this hardware with Shimian QHD270 displays, vblanks are
skipped resulting in stuttering video playback on any framerate other than
60fps (with multiple players and vo including opengl and wayland (shm)).
System:
Mesa: git
linux: 4.4, 4.5, 4.6 from a drm-next-wip branch
wayland: git
weston: git

A few notes:
- This doesn't occur when using amdgpu (for instance building with hawaii
amdgpu support.
- This bug goes back as far as a year, and another user verified they had this
issue on a radeonsi card with a specific monitor.
- When utilizing amdgpu, the EDID is correctly read from these monitors.
Without, the EDID read fails. I've written the EDID to a file in /lib/firmware/
and successfully loaded with no change however.
- Outside of video playback, there are no vblank skips. It was explained that
each application affects the entire compositor.
- No change on video size. The issue is apparent (with no discernible change)
on non-60fps 360p youtube videos on up to high bitrate x265 4K tv shows.
- By increasing repaint-window, I'm able to get consistent playback and no
vblank skips. However I do run into other issues with it, showing it's clearly
not a real solution for wayland support on radeon.
- During video playback, weston-presentation-shm shows the missing vblanks
just as a timeline does (so including weston-presentation-shm log for
readability instead).

weston-presentation-shm log with video playback at beginning:
https://bpaste.net/show/f8c9b910ddc1. When vblanks are no longer skipped, the
video playback has stopped.

--
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/20160412/a845345e/attachment.html>

[Bug 67681] Asus G75VW F keys Not Working For WiFi & Brightness

2016-04-12 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #41 from KernelBug <3fdd1e5d at opayq.com> ---
Can someone PLEASE be kind enough to tell me if the kernel now has the support
for these functions for this laptop?

thank you

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

[PATCH v5 00/46] pwm: add support for atomic update

2016-04-12 Thread Boris Brezillon

Hi Thierry,

On Wed, 30 Mar 2016 22:03:23 +0200
Boris Brezillon  wrote:

> Hello,
> 
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
> 
> It also adds support for initial PWM state retrieval (or hardware readout),
> which should allow smooth handover between the bootloader and Linux. For
> example, critical PWM users (like critical regulators controlled by a PWM)
> can query the current PWM state, and adapt the PWM config without having
> to disable/enable the PWM, or abruptly change the period/dutycyle/polarity
> config.
> 
> Thierry, I hope this version meets your expectations, if that's not the
> case, could you let me know quickly so I can adjust the implementation
> accordingly (I'd really like to get most of those changes in 4.7).

Still haven't had a clear feedback from your side on this series (you
commented on a few details, but nothing on the general approach). Could
you please have at a quick look at it, and let me know if I should
adjust the implementation?

Note that I plan to send a new version  addressing comments made by
other maintainers/developers by the end of the week. In the meantime,
could you have a look at the first set of patches (patch 1 to 4 are
completely independent), and apply them if you're happy with it.

As you can see, I now have a lot of patches. This helps in showing the
big picture, but also annoys people when I send this 50+ patchset. So,
if you don't mind, I'd like to drop the changes touching PWM user
drivers (to make them use the atomic API) until we get the other parts
applied.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[RESEND] fence: add missing descriptions for fence

2016-04-12 Thread Luis de Bethencourt

On 11/04/16 21:09, Gustavo Padovan wrote:
> Hi Luis,
> 
> 2016-04-11 Luis de Bethencourt :
> 
>> The members child_list and active_list were added to the fence struct
>> without descriptions for the Documentation. Adding these.
>>
>> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
>> Signed-off-by: Luis de Bethencourt 
>> Reviewed-by: Javier Martinez Canillas 
>> ---
>> Hi,
>>
>> Just resending this patch since it hasn't had any reviews in since
>> March 21st.
>>
>> Thanks,
>> Luis
>>
>>  include/linux/fence.h | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> Reviewed-by: Gustavo Padovan 
> 
>   Gustavo
> 

Thank you Gustavo.

Nice seeing you around here :)

Luis

71 matches

Mail list logo