[Bug 97122] list of 12 dEQP-GLES2 tests causing systematic GPU lockups

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97122

--- Comment #1 from Mauro Rossi  ---
Created attachment 125387
  --> https://bugs.freedesktop.org/attachment.cgi?id=125387=edit
dmesg for uniform_iterations#conditional_continue_fragment FAIL

-- 
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/20160728/d60e34c6/attachment-0001.html>


[Bug 97122] list of 12 dEQP-GLES2 tests causing systematic GPU lockups

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97122

Bug ID: 97122
   Summary: list of 12 dEQP-GLES2 tests causing systematic GPU
lockups
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: issor.oruam at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 125386
  --> https://bugs.freedesktop.org/attachment.cgi?id=125386=edit
List of tests inducing systematic GPU lockups

Hi,

while performing Android Compatibility Test Suite run on marshamallow-x86 with
mesa 12.0.1 I encountered systematic GPU lockups preceeded by full screen
artifact, sometime "noise screen alike" and some others "vertical stripes".

The issue was observed on HD7750 and HD7950.

The pattern and list of the 12 dEQP-GLES2 tests causing systematic GPU lockups
is the following:

dEQP-GLES2.functional.shaders.loops.while_{constant,uniform,dynamic}.{conditional,double}_continue_{vertex,fragment}

You can find in the attachments the dEQP GLES2 tests logs and some dmesg logs
captured during these GPU lockups.

I am available to collect further logs, if you could provide me instructions,
or to test patches and report back to help resolve the issue.

NOTE: I've already tried to define R600_DEBUG=nosb
which in android-x86 has to be done in init.x86.rc before building the iso
image,
but then running a test plan with the aforementioned failed tests,
I get again systematic GPU lockups.

Mauro Rossi

-- 
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/20160728/1d415916/attachment-0001.html>


[PATCH] drm/nouveau/fbcon: fix font width not divisible by 8

2016-07-28 Thread Mikulas Patocka
The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the
display when using fonts with width that is not divisiable by 8.

The monochrome bitmap for each character is stored in memory by lines from top
to bottom. Each line is padded to a full byte.

For example, for 22x11 font, each line is padded to 16 bits, so each 
character is consuming 44 bytes total, that is 11 32-bit words. The patch 
f045f459d925 changed the logic to "dsize = ALIGN(image->width * 
image->height, 32) >> 5", that is just 8 words - this is incorrect and it 
causes display corruption.

This patch adds the necesary padding of lines to 8 bytes.

This patch should be backported to stable kernels where f045f459d925 was 
backported.

Signed-off-by: Mikulas Patocka 
Fixes: f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
Cc: stable at vger.kernel.org

Index: linux-2.6/drivers/gpu/drm/nouveau/nvc0_fbcon.c
===
--- linux-2.6.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
+++ linux-2.6/drivers/gpu/drm/nouveau/nvc0_fbcon.c
@@ -125,7 +125,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
OUT_RING  (chan, 0);
OUT_RING  (chan, image->dy);

-   dwords = ALIGN(image->width * image->height, 32) >> 5;
+   dwords = ALIGN(ALIGN(image->width, 8) * image->height, 32) >> 5;
while (dwords) {
int push = dwords > 2047 ? 2047 : dwords;

Index: linux-2.6/drivers/gpu/drm/nouveau/nv04_fbcon.c
===
--- linux-2.6.orig/drivers/gpu/drm/nouveau/nv04_fbcon.c
+++ linux-2.6/drivers/gpu/drm/nouveau/nv04_fbcon.c
@@ -107,11 +107,11 @@ nv04_fbcon_imageblit(struct fb_info *inf
 ((image->dx + image->width) & 0x));
OUT_RING(chan, bg);
OUT_RING(chan, fg);
-   OUT_RING(chan, (image->height << 16) | image->width);
+   OUT_RING(chan, (image->height << 16) | ALIGN(image->width, 8));
OUT_RING(chan, (image->height << 16) | image->width);
OUT_RING(chan, (image->dy << 16) | (image->dx & 0x));

-   dsize = ALIGN(image->width * image->height, 32) >> 5;
+   dsize = ALIGN(ALIGN(image->width, 8) * image->height, 32) >> 5;
while (dsize) {
int iter_len = dsize > 128 ? 128 : dsize;

Index: linux-2.6/drivers/gpu/drm/nouveau/nv50_fbcon.c
===
--- linux-2.6.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ linux-2.6/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -125,7 +125,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
OUT_RING(chan, 0);
OUT_RING(chan, image->dy);

-   dwords = ALIGN(image->width * image->height, 32) >> 5;
+   dwords = ALIGN(ALIGN(image->width, 8) * image->height, 32) >> 5;
while (dwords) {
int push = dwords > 2047 ? 2047 : dwords;



[PATCH] drm: aux ->transfer() can return 0, deal with it

2016-07-28 Thread Daniel Vetter
On Thu, Jul 28, 2016 at 05:54:42PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> Restore the correct behaviour (as in check msg.reply) when aux
> ->transfer() returns 0. It got removed in
> commit 82922da39190 ("drm/dp_helper: Retry aux transactions on all errors")
> 
> Now I can actually dump the "entire" DPCD on a Dell UP2314Q with
> ddrescue. It has some offsets in the DPCD that can't be read
> for some resaon, all you get is defers. Previously ddrescue would
> just give up at the first unredable offset on account of
> read() returning 0 means EOF. Here's the ddrescue log
> for the interested:
> 0x  0x1400  +
> 0x1400  0x0030  -
> 0x1430  0x01D0  +
> 0x1600  0x0030  -
> 0x1630  0x0001F9D0  +
> 0x00021000  0x0001  -
> 0x00021001  0x000DEFFF  +
> 
> Cc: Lyude 
> Cc: Daniel Vetter  Cc: stable at vger.kernel.org
> Fixes: 82922da39190 ("drm/dp_helper: Retry aux transactions on all errors")
> Signed-off-by: Ville Syrjälä 

Seems to correctly restore that special case.

Reviewed-by: Daniel Vetter 

Dave, since I just send out a drm-misc pull, can you pls apply this one
directly to drm-next?
-Daniel

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 091053e995e5..8f11b8741e42 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -203,7 +203,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>  
>   ret = aux->transfer(aux, );
>  
> - if (ret > 0) {
> + if (ret >= 0) {
>   native_reply = msg.reply & DP_AUX_NATIVE_REPLY_MASK;
>   if (native_reply == DP_AUX_NATIVE_REPLY_ACK) {
>   if (ret == size)
> -- 
> 2.7.4
> 

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


[PATCH] drm: aux ->transfer() can return 0, deal with it

2016-07-28 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

Restore the correct behaviour (as in check msg.reply) when aux
->transfer() returns 0. It got removed in
commit 82922da39190 ("drm/dp_helper: Retry aux transactions on all errors")

Now I can actually dump the "entire" DPCD on a Dell UP2314Q with
ddrescue. It has some offsets in the DPCD that can't be read
for some resaon, all you get is defers. Previously ddrescue would
just give up at the first unredable offset on account of
read() returning 0 means EOF. Here's the ddrescue log
for the interested:
0x  0x1400  +
0x1400  0x0030  -
0x1430  0x01D0  +
0x1600  0x0030  -
0x1630  0x0001F9D0  +
0x00021000  0x0001  -
0x00021001  0x000DEFFF  +

Cc: Lyude 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 091053e995e5..8f11b8741e42 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -203,7 +203,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,

ret = aux->transfer(aux, );

-   if (ret > 0) {
+   if (ret >= 0) {
native_reply = msg.reply & DP_AUX_NATIVE_REPLY_MASK;
if (native_reply == DP_AUX_NATIVE_REPLY_ACK) {
if (ret == size)
-- 
2.7.4



[PATCH v4 4/8] drm/mediatek: add support for Mediatek SoC MT2701

2016-07-28 Thread CK Hu
Hi, YT:


On Thu, 2016-07-28 at 15:17 +0800, YT Shen wrote:
> Hi Philipp, CK,
> 
> On Thu, 2016-07-28 at 10:07 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Wed, 2016-07-27 at 12:03 +0200, Philipp Zabel wrote:
> > > Am Dienstag, den 26.07.2016, 18:42 +0800 schrieb YT Shen:
> > > > Hi CK,
> > > > 
> > > > On Wed, 2016-07-20 at 14:53 +0800, CK Hu wrote:
> > > > > Hi, YT:
> > > > > 
> > > > > Some comments inline.
> > > > > 
> > > > > On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> > > > > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > > > > There is only one OVL engine in MT2701.
> > > > > > 
> > > > > > Signed-off-by: YT Shen 
> > > > > > ---
> > > > > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 
> > > > > >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 
> > > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   41 
> > > > > > +++
> > > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 +
> > > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
> > > > > >  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   31 
> > > > > > 
> > > > > >  6 files changed, 92 insertions(+)
> > > > > > 
> > > > > 
> > > > > [snip...]
> > > > > 
> > > > > >  
> > > > > >  static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > > > > > +   { .compatible = "mediatek,mt2701-disp-ovl",   .data = (void 
> > > > > > *)MTK_DISP_OVL },
> > > > > > { .compatible = "mediatek,mt8173-disp-ovl",   .data = (void 
> > > > > > *)MTK_DISP_OVL },
> > > > > > +   { .compatible = "mediatek,mt2701-disp-rdma",  .data = (void 
> > > > > > *)MTK_DISP_RDMA },
> > > > > > { .compatible = "mediatek,mt8173-disp-rdma",  .data = (void 
> > > > > > *)MTK_DISP_RDMA },
> > > > > > +   { .compatible = "mediatek,mt2701-disp-wdma",  .data = (void 
> > > > > > *)MTK_DISP_WDMA },
> > > > > 
> > > > > Is WDMA different from MT8173 to MT2701. If they are the same, you 
> > > > > need
> > > > > not to add compatible of 'mediatek,mt2701-disp-wdma' because use
> > > > > 'mediatek,mt8173-disp-wdma' is enough.
> > > > Yes, the hardware has differences, so we need add new compatible
> > > > 'mt2701-disp-wdma'
> > > 
> > > It would be nice if you could add a short paragraph to the patch
> > > description about what the hardware differences are (probably just
> > > changed register layout in most cases).
> Thanks for the suggestions, we will add more descriptions in the future.
> 
> > 
> > If you don't want to add description, you may separate the modification
> > of OVL, RDMA, WDMA, PWM to different patch. And you send patch of OVL
> > and RDMA first because you have related code modification for these two.
> > You temporarily treat WDMA and PWM as MT8173 and it works. And one day
> > you need to modify code of WDMA and PWM for MT2701, then you send the
> > patch of WDMA and PWM and you need not to add any description because we
> > can find out the difference from source code.
> 
> The display module connections is shown in mt2701_mtk_ddp_main[] and
> mt2701_mtk_ddp_ext[].
> OVL -> RDMA -> COLOR -> BLS(pwm) -> DSI
> RDMA -> DPI
> 
> This patch series mainly focus on DSI support for MT2701 SoC and the
> basic functions.  The BLS(pwm) and DPI parts are not included here.
> 
> We will remove 'mt2701-disp-wdma'. We didn't implement its driver and it
> is unused now.
> 
> For the pwm part, we need the device node to establish the display
> module connections.  The pwm compatible string is described in
> "dt-bindings: pwm: Add MediaTek display PWM bindings" [1] and the
> control is implemented in "pwm: Add MediaTek MT2701 display PWM driver
> support" [2].
> 
> For the dpi part, we need the device node to establish the display
> module connections.  The dpi patch will be in another patch series,
> split out from "drm/mediatek: fix the wrong pixel clock when resolution
> is 4K" [3].

For dpi part, I think you need not to include it in this patch. You can
send it with the MT2701 DPI patch. For module connection, you can use
"mediatek,mt8173-dpi" and it works. If you want to add it in this patch,
please describe the difference of mt8173-dpi and mt2701-dpi in this
patch.

> 
> 
> [1] https://patchwork.kernel.org/patch/9222997/
> [2] https://patchwork.kernel.org/patch/9223001/
> [3] https://patchwork.kernel.org/patch/9249471/ 
> 
> Regards,
> yt.shen
> 
> > 
> > > 
> > > regards
> > > Philipp
> > > 
> > 
> > Regards,
> > CK
> > 
> 
> 

Regards,
CK



ATPX changes in drm-next-4.8 and D3cold handling

2016-07-28 Thread Lukas Wunner
On Thu, Jul 28, 2016 at 03:33:25PM +, Deucher, Alexander wrote:
> > From: Peter Wu [mailto:peter at lekensteyn.nl]
> > Sent: Thursday, July 21, 2016 6:43 AM
> > In case you missed it, Dave's D3cold patches were succeeded by changes
> > in PCI core. Relevant commits in the pci/pm branch:
> > 
> > 006d44e PCI: Add runtime PM support for PCIe ports
> > 16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan
> > d963f65 PCI: Power on bridges before scanning new devices
> > 9d26d3a PCI: Put PCIe ports into D3 during suspend
> > 43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports
> 
> Did those get merged yet?

They will go into 4.8. Should have gone into 4.7 already but were
dropped at the last minute.


> I just need to revert this commit once the d3cold patches land:
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8=bdfb76040068d960cb9e226876be8a508d741c4a

So you probably need to revert this now.

Best regards,

Lukas


[PATCH 1/3] drm: introduce share plane

2016-07-28 Thread Mark yao
On 2016年07月28日 16:03, Daniel Vetter wrote:
> On Thu, Jul 28, 2016 at 11:01:04AM +0800, Mark yao wrote:
>> Any ideas for the share planes?
>>
>> This function is important for our series of vop full design.
>>  The series of vop is:
>>  IP versionchipname
>>  3.1   rk3288
>>  3.2   rk3368
>>  3.4   rk3366
>>  3.5   rk3399 big
>>  3.6   rk3399 lit
>>  3.7   rk322x
>>
>> example on rk3288:  if not support share plane, each vop only support four
>> planes, but if support this function, each vop can support ten planes.
> Like I said, register 10 planes in the kernel driver, figure out a good
> way to actually allocate them to hw resources. We have a similar issue on
> skl/bxt in the i915 driver where there's only a limited amount of
> scalers, and we need to dynamically allocate them to drm_plane. Here you
> have fancy amount of scanout engines which you need to dynamically
> allocate.
>
>> On 2016年07月26日 17:51, Mark yao wrote:
>>> On 2016年07月26日 16:26, Daniel Vetter wrote:
 On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
>> What is share plane:
>> Plane hardware only be used when the display scanout run into
> plane active
>> scanout, that means we can reuse the plane hardware resources on plane
>> non-active scanout.
>>
>>   --
>>  |  scanout   |
>>  | -- |
>>  | | parent plane   | |
>>  | | active scanout | |
>>  | ||   - |
>>  | --   | share plane 1 | |
>>  |  -   |active scanout | |
>>  |  | share plane 0 |   |   | |
>>  |  |active scanout |   - |
>>  |  |   | |
>>  |  - |
>>  --
>> One plane hardware can be reuse for multi-planes, we assume the first
>> plane is parent plane, other planes share the resource with first one.
>>  parent plane
>>  |---share plane 0
>>  |---share plane 1
>>  ...
>>
>> Because resource share, There are some limit on share plane: one group
>> of share planes need use same zpos, can not overlap, etc.
>>
>> We assume share plane is a universal plane with some limit flags.
>> people who use the share plane need know the limit, should call
> the ioctl
>> DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
>>
>> A group of share planes would has same shard id, so userspace can
>> group them, judge share plane's limit.
>>
>> Signed-off-by: Mark Yao
 This seems extremely hw specific, why exactly do we need to add a new
 relationship on planes? What does this buy on_other_  drivers?
>>> Yes, now it's plane hardware specific, maybe others have same design,
>>> because this design
>>> would save hardware resource to support multi-planes.
>>>
 Imo this should be solved by virtualizing planes in the driver.
 Start out
 by assigning planes, and if you can reuse one for sharing then do that,
 otherwise allocate a new one. If there's not enough real planes,
 fail the
 atomic_check.
>>> I think that is too complex, trying with atomic_check I think it's not a
>>> good idea, userspace try planes every commit would be a heavy work.
>>>
>>> Userspace need  know all planes relationship, group them, some display
>>> windows can put together, some can't,
>>> too many permutation and combination, I think can't just commit with try.
>>>
>>> example:
>>> userspace:
>>> windows 1: pos(0, 0)  size(1024, 100)
>>> windows 2: pos(0, 50) size(400, 500)
>>> windows 3: pos(0, 200) size(800, 300)
>>>
>>> drm plane resources:
>>> plane 0 and plane 1 is a group of share planes
>>> plane 2 is common plane.
>>>
>>> if userspace know the relationship, then they can assign windows 1 and
>>> window 3 to plane0 and plane 1. that would be success.
>>> but if they don't know, assign window 1/2 to plane 0/1, failed, assign
>>> window 2/3 to plane 0/1, failed. mostly would get failed.
> You can still do this with the design I describe. The only difference is
> that you allow generic userspace to make optimal use of your planes, too.
>
 This seems way to hw specific to be useful as a generic concept.
>>> We want to change the drm_mode_getplane_res behavior, if userspace call
>>> DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware limit,
>>> then we return full planes support to userspace, if don't, just make a
>>> group of share planes as one plane.
>>> this work is on generic 

[PATCH v5 10/10] arm: dts: mt2701: Add display subsystem related nodes for MT2701

2016-07-28 Thread YT Shen
This patch adds the device nodes for the DISP function blocks for MT2701

Signed-off-by: YT Shen 
---
 arch/arm/boot/dts/mt2701.dtsi |  100 +
 1 file changed, 100 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 363de0d..7da9310 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -24,6 +24,11 @@
compatible = "mediatek,mt2701";
interrupt-parent = <>;

+   aliases {
+   rdma0 = 
+   rdma1 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -171,6 +176,16 @@
power-domains = < MT2701_POWER_DOMAIN_DISP>;
};

+   mipi_tx0: mipi-dphy at 1001 {
+   compatible = "mediatek,mt2701-mipi-tx";
+   reg = <0 0x1001 0 0x90>;
+   clocks = <>;
+   clock-output-names = "mipi_tx0_pll";
+   #clock-cells = <0>;
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
sysirq: interrupt-controller at 10200100 {
compatible = "mediatek,mt2701-sysirq",
 "mediatek,mt6577-sysirq";
@@ -255,6 +270,68 @@
status = "disabled";
};

+   ovl at 14007000 {
+   compatible = "mediatek,mt2701-disp-ovl";
+   reg = <0 0x14007000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_OVL>;
+   iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
+   mediatek,larb = <>;
+   };
+
+   rdma0: rdma at 14008000 {
+   compatible = "mediatek,mt2701-disp-rdma";
+   reg = <0 0x14008000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_RDMA>;
+   iommus = < MT2701_M4U_PORT_DISP_RDMA>;
+   mediatek,larb = <>;
+   };
+
+   wdma at 14009000 {
+   compatible = "mediatek,mt2701-disp-wdma";
+   reg = <0 0x14009000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_WDMA>;
+   iommus = < MT2701_M4U_PORT_DISP_WDMA>;
+   mediatek,larb = <>;
+   };
+
+   bls at 1400a000 {
+   compatible = "mediatek,mt2701-disp-pwm";
+   reg = <0 0x1400a000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_BLS>;
+   };
+
+   color at 1400b000 {
+   compatible = "mediatek,mt2701-disp-color";
+   reg = <0 0x1400b000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_COLOR>;
+   };
+
+   dsi0: dsi at 1400c000 {
+   compatible = "mediatek,mt2701-dsi";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DSI_ENGINE>, < CLK_MM_DSI_DIG>,
+<_tx0>;
+   clock-names = "engine", "digital", "hs";
+   mediatek,syscon-dsi = < 0x138>;
+   mediatek,ssc-range = <5>;
+   phys = <_tx0>;
+   phy-names = "dphy";
+   status = "disabled";
+   };
+
+   mutex: mutex at 1400e000 {
+   compatible = "mediatek,mt2701-disp-mutex";
+   reg = <0 0x1400e000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_MUTEX_32K>;
+   };
+
larb0: larb at 1401 {
compatible = "mediatek,mt2701-smi-larb";
reg = <0 0x1401 0 0x1000>;
@@ -265,6 +342,29 @@
power-domains = < MT2701_POWER_DOMAIN_DISP>;
};

+   rdma1: rdma at 14012000 {
+   compatible = "mediatek,mt2701-disp-rdma";
+   reg = <0 0x14012000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_RDMA1>;
+   iommus = < MT2701_M4U_PORT_DISP_RDMA1>;
+   mediatek,larb = <>;
+   };
+
+   dpi0: dpi at 14014000 {
+   compatible = "mediatek,mt2701-dpi";
+   reg = <0 0x14014000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DPI1_DIGL>,
+< CLK_MM_DPI1_ENGINE>,
+< CLK_TOP_DPI1_SEL>,
+< CLK_TOP_TVDPLL>,
+< CLK_TOP_TVDPLL_D2>,
+< CLK_TOP_TVDPLL_D4>;
+   clock-names = "pixel", "engine", "sel","div1","div2","div4";
+   status = "disabled";
+   };
+
imgsys: syscon at 1500 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
-- 
1.7.9.5



[PATCH v5 09/10] drm/mediatek: add support for Mediatek SoC MT2701

2016-07-28 Thread YT Shen
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 ++
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   17 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   30 +++
 drivers/gpu/drm/mediatek/mtk_dsi.c  |1 +
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |   27 +++-
 8 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index eb5c05e..1da0a71 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -286,11 +286,17 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
return 0;
 }

+static const struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
+   .ovl = {0x0040, 1 << 12, 0}
+};
+
 static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
.ovl = {0x0f40, 0, 1 << 12}
 };

 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = _ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
  .data = _ovl_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index fb0db50..506a353 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -225,11 +225,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
*pdev)
return 0;
 }

+static const struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
+   .rdma_fifo_pseudo_size = SZ_4K,
+};
+
 static const struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
.rdma_fifo_pseudo_size = SZ_8K,
 };

 static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-rdma",
+ .data = _rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
  .data = _rdma_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 329da541..7678ac0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -60,6 +60,13 @@
 #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
 #define MT8173_MUTEX_MOD_DISP_OD   BIT(25)

+#define MT2701_MUTEX_MOD_DISP_OVL  BIT(3)
+#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
+#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
+#define MT2701_MUTEX_MOD_DISP_BLS  BIT(9)
+#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
+#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+
 #define MUTEX_SOF_SINGLE_MODE  0
 #define MUTEX_SOF_DSI0 1
 #define MUTEX_SOF_DSI1 2
@@ -92,6 +99,15 @@ struct mtk_ddp {
const unsigned int  *mutex_mod;
 };

+static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+   [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
+   [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
+   [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
+   [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
+   [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
+   [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
+};
+
 static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -389,6 +405,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
 }

 static const struct of_device_id ddp_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
 };
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4b4e449..465819b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -112,6 +112,7 @@ struct mtk_ddp_comp_match {

 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = 
{
[DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, NULL },
+   [DDP_COMPONENT_BLS] = { MTK_DISP_PWM,   0, NULL },
[DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
[DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
@@ -130,11 +131,17 @@ static const struct mtk_ddp_comp_match 
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {

[PATCH v5 08/10] drm/mediatek: update DSI sub driver flow

2016-07-28 Thread YT Shen
This patch update enable/disable flow of DSI module and MIPI TX module

Signed-off-by: shaoming chen 
Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |  104 ++--
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c |   32 +-
 2 files changed, 103 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 1d36524..2646f83 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -95,6 +95,8 @@
 #define DSI_RACK   0x84
 #define RACK   BIT(0)

+#define DSI_MEM_CONTI  0x90
+
 #define DSI_PHY_LCCON  0x104
 #define LC_HS_TX_ENBIT(0)
 #define LC_ULPM_EN BIT(1)
@@ -127,6 +129,10 @@
 #define CLK_HS_POST(0xff << 8)
 #define CLK_HS_EXIT(0xff << 16)

+#define DSI_VM_CMD_CON 0x130
+#define VM_CMD_EN  BIT(0)
+#define TS_VFP_EN  BIT(5)
+
 #define DSI_CMDQ0  0x180

 #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
@@ -266,7 +272,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
 * we set mipi_ratio is 1.05.
 */
-   dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+   dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
+   dsi->data_rate /= (dsi->lanes * 1000 * 10);
+   dev_info(dev, "set mipitx's data rate: %dMHz\n", dsi->data_rate);

ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 100);
if (ret < 0) {
@@ -288,10 +296,6 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
goto err_disable_engine_clk;
}

-   mtk_dsi_enable(dsi);
-   mtk_dsi_reset_engine(dsi);
-   mtk_dsi_phy_timconfig(dsi);
-
return 0;

 err_disable_engine_clk:
@@ -306,7 +310,7 @@ err_refcount:
 static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
-   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
+   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, LC_ULPM_EN);
 }

 static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
@@ -319,7 +323,7 @@ static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
 static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
-   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
+   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, LD0_ULPM_EN);
 }

 static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
@@ -355,11 +359,21 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
vid_mode = BURST_MODE;
+   else
+   vid_mode = SYNC_EVENT_MODE;
}

writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
 }

+static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
+{
+   writel(0x3c, dsi->regs + DSI_MEM_CONTI);
+
+   mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
+   mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
+}
+
 static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
 {
struct videomode *vm = >vm;
@@ -416,6 +430,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
break;
}

+   tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
+   tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
+
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
 }

@@ -494,6 +511,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
 }

+static void mtk_dsi_stop(struct mtk_dsi *dsi)
+{
+   writel(0, dsi->regs + DSI_START);
+}
+
+static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
+{
+   writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
+}
+
 static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
 {
u32 inten = DSI_INT_ALL_BITS;
@@ -543,6 +570,27 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }

+static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
+{
+   s32 ret = 0;
+   unsigned long timeout = msecs_to_jiffies(500);
+
+   mtk_dsi_set_cmd_mode(dsi);
+
+   ret = wait_event_interruptible_timeout(_dsi_wait_vm_done_queue,
+   dsi->irq_data & VM_DONE_INT_FLAG, timeout);
+   if (ret == 0) {
+   dev_info(dsi->dev, "dsi wait engine idle timeout\n");
+
+   mtk_dsi_enable(dsi);
+   mtk_dsi_reset_engine(dsi);
+
+   return;
+   }
+
+   dsi->irq_data &= ~VM_DONE_INT_FLAG;
+}
+
 static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 {
if (WARN_ON(dsi->refcount == 0))
@@ 

[PATCH v5 07/10] drm/mediatek: add dsi transfer function

2016-07-28 Thread YT Shen
From: shaoming chen 

add dsi read/write commands for transfer function

Signed-off-by: shaoming chen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |  286 
 1 file changed, 286 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 553443a..1d36524 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "mtk_drm_ddp_comp.h"
@@ -81,8 +82,16 @@
 #define DSI_HBP_WC 0x54
 #define DSI_HFP_WC 0x58

+#define DSI_CMDQ_SIZE  0x60
+#define CMDQ_SIZE  0x3f
+
 #define DSI_HSTX_CKL_WC0x64

+#define DSI_RX_DATA0   0x74
+#define DSI_RX_DATA1   0x78
+#define DSI_RX_DATA2   0x7c
+#define DSI_RX_DATA3   0x80
+
 #define DSI_RACK   0x84
 #define RACK   BIT(0)

@@ -118,8 +127,25 @@
 #define CLK_HS_POST(0xff << 8)
 #define CLK_HS_EXIT(0xff << 16)

+#define DSI_CMDQ0  0x180
+
 #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))

+#define MTK_DSI_HOST_IS_READ(type) \
+   ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
+   (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
+   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
+   (type == MIPI_DSI_DCS_READ))
+
+#define MTK_DSI_HOST_IS_WRITE(type) \
+   ((type == MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM) || \
+   (type == MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM) || \
+   (type == MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM) || \
+   (type == MIPI_DSI_DCS_SHORT_WRITE) || \
+   (type == MIPI_DSI_DCS_SHORT_WRITE_PARAM) || \
+   (type == MIPI_DSI_GENERIC_LONG_WRITE) || \
+   (type == MIPI_DSI_DCS_LONG_WRITE))
+
 struct phy;

 struct mtk_dsi {
@@ -149,6 +175,17 @@ struct mtk_dsi {
int irq_data;
 };

+struct dsi_rxtx_data {
+   u8 byte0;
+   u8 byte1;
+   u8 byte2;
+   u8 byte3;
+};
+
+struct dsi_tx_cmdq_regs {
+   struct dsi_rxtx_data data[128];
+};
+
 static wait_queue_head_t _dsi_cmd_done_wait_queue;
 static wait_queue_head_t _dsi_dcs_read_wait_queue;
 static wait_queue_head_t _dsi_wait_vm_done_queue;
@@ -813,9 +850,258 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
 }

+static void mtk_dsi_set_cmdq(void __iomem *reg, u32 mask, u32 data)
+{
+   u32 temp = readl(reg);
+
+   writel((temp & ~mask) | (data & mask), reg);
+}
+
+static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
+{
+   u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
+
+   while (timeout_ms--) {
+   if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
+   break;
+
+   usleep_range(2, 4);
+   }
+
+   if (timeout_ms == 0) {
+   dev_info(dsi->dev, "polling dsi wait not busy timeout!\n");
+
+   mtk_dsi_enable(dsi);
+   mtk_dsi_reset_engine(dsi);
+   }
+}
+
+static void mtk_dsi_wait_for_cmd_done(struct mtk_dsi *dsi)
+{
+   s32 ret = 0;
+   unsigned long timeout = msecs_to_jiffies(500);
+
+   ret = wait_event_interruptible_timeout(_dsi_cmd_done_wait_queue,
+   dsi->irq_data & CMD_DONE_INT_FLAG, timeout);
+   if (ret == 0) {
+   dev_info(dsi->dev, "dsi wait engine cmd done fail\n");
+   mtk_dsi_enable(dsi);
+   mtk_dsi_reset_engine(dsi);
+   return;
+   }
+
+   dsi->irq_data &= ~CMD_DONE_INT_FLAG;
+}
+
+static ssize_t mtk_dsi_host_read_cmd(struct mtk_dsi *dsi,
+const struct mipi_dsi_msg *msg)
+{
+   u8 max_try_count = 5;
+   u32 recv_cnt, tmp_val;
+   struct dsi_rxtx_data read_data0, read_data1, read_data2, read_data3;
+   u8 config, type, data0, data1;
+   s32 ret;
+
+   u8 *buffer = msg->rx_buf;
+   u8 buffer_size = msg->rx_len;
+
+   if (readl(dsi->regs + DSI_MODE_CTRL) & 0x03) {
+   dev_info(dsi->dev, "dsi engine is not command mode\n");
+   return -1;
+   }
+
+   if (!buffer) {
+   dev_info(dsi->dev, "dsi receive buffer size may be NULL\n");
+   return -1;
+   }
+
+   do {
+   if (max_try_count == 0) {
+   dev_info(dsi->dev, "dsi engine read counter has been 
maxinum\n");
+   return -1;
+   }
+
+   max_try_count--;
+   recv_cnt = 0;
+
+   mtk_dsi_wait_for_idle(dsi);
+
+   config = 0x04;
+   data0 = *((u8 *)(msg->tx_buf));
+
+   if (buffer_size < 3)
+   type = MIPI_DSI_DCS_READ;
+   else
+   type = MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM;
+
+   data1 = 0;
+
+   tmp_val = (data1 

[PATCH v5 06/10] drm/mediatek: add dsi interrupt control

2016-07-28 Thread YT Shen
From: shaoming chen 

add dsi interrupt control

Signed-off-by: shaoming chen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |   92 
 1 file changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a9cf5a1..553443a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,17 @@

 #define DSI_START  0x00

+#define DSI_INTEN  0x08
+
+#define DSI_INTSTA 0x0c
+#define LPRX_RD_RDY_INT_FLAG   BIT(0)
+#define CMD_DONE_INT_FLAG  BIT(1)
+#define TE_RDY_INT_FLAGBIT(2)
+#define VM_DONE_INT_FLAG   BIT(3)
+#define EXT_TE_RDY_INT_FLAGBIT(4)
+#define DSI_INT_ALL_BITS   0x7f
+#define DSI_BUSY   BIT(31)
+
 #define DSI_CON_CTRL   0x10
 #define DSI_RESET  BIT(0)
 #define DSI_EN BIT(1)
@@ -71,6 +83,9 @@

 #define DSI_HSTX_CKL_WC0x64

+#define DSI_RACK   0x84
+#define RACK   BIT(0)
+
 #define DSI_PHY_LCCON  0x104
 #define LC_HS_TX_ENBIT(0)
 #define LC_ULPM_EN BIT(1)
@@ -131,8 +146,13 @@ struct mtk_dsi {
struct videomode vm;
int refcount;
bool enabled;
+   int irq_data;
 };

+static wait_queue_head_t _dsi_cmd_done_wait_queue;
+static wait_queue_head_t _dsi_dcs_read_wait_queue;
+static wait_queue_head_t _dsi_wait_vm_done_queue;
+
 static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
 {
return container_of(e, struct mtk_dsi, encoder);
@@ -437,6 +457,55 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
 }

+static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
+{
+   u32 inten = DSI_INT_ALL_BITS;
+
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO)
+   inten &= ~(TE_RDY_INT_FLAG | EXT_TE_RDY_INT_FLAG);
+
+   writel(inten, dsi->regs + DSI_INTEN);
+}
+
+static void mtk_dsi_irq_wakeup(struct mtk_dsi *dsi, u32 irq_bit)
+{
+   dsi->irq_data |= irq_bit;
+}
+
+static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
+{
+   struct mtk_dsi *dsi = dev_id;
+
+   u32 status, tmp;
+
+   status = readl(dsi->regs + DSI_INTSTA);
+
+   if (status & LPRX_RD_RDY_INT_FLAG) {
+   do {
+   mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
+   tmp = readl(dsi->regs + DSI_INTSTA);
+   } while (tmp & DSI_BUSY);
+
+   mtk_dsi_mask(dsi, DSI_INTSTA, LPRX_RD_RDY_INT_FLAG, 0);
+   mtk_dsi_irq_wakeup(dsi, LPRX_RD_RDY_INT_FLAG);
+   wake_up_interruptible(&_dsi_dcs_read_wait_queue);
+   }
+
+   if (status & CMD_DONE_INT_FLAG) {
+   mtk_dsi_mask(dsi, DSI_INTSTA, CMD_DONE_INT_FLAG, 0);
+   mtk_dsi_irq_wakeup(dsi, CMD_DONE_INT_FLAG);
+   wake_up_interruptible(&_dsi_cmd_done_wait_queue);
+   }
+
+   if (status & VM_DONE_INT_FLAG) {
+   mtk_dsi_mask(dsi, DSI_INTSTA, VM_DONE_INT_FLAG, 0);
+   mtk_dsi_irq_wakeup(dsi, VM_DONE_INT_FLAG);
+   wake_up_interruptible(&_dsi_wait_vm_done_queue);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 {
if (WARN_ON(dsi->refcount == 0))
@@ -485,6 +554,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)

mtk_dsi_ps_control_vact(dsi);
mtk_dsi_config_vdo_timing(dsi);
+   mtk_dsi_set_interrupt_enable(dsi);

mtk_dsi_set_mode(dsi);
mtk_dsi_clk_hs_mode(dsi, 1);
@@ -804,6 +874,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *remote_node, *endpoint;
struct resource *regs;
+   int irq_num;
int comp_id;
int ret;

@@ -880,8 +951,29 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}

+   irq_num = platform_get_irq(pdev, 0);
+   if (irq_num < 0) {
+   dev_err(>dev, "failed to request dsi irq resource\n");
+   return -EPROBE_DEFER;
+   }
+
+   irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
+   ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
+  IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
+   if (ret) {
+   dev_err(>dev, "failed to request mediatek dsi irq\n");
+   return -EPROBE_DEFER;
+   }
+
+   dsi->irq_data = 0;
+   dev_info(dev, "dsi irq num is 0x%x\n", irq_num);
+
platform_set_drvdata(pdev, dsi);

+   init_waitqueue_head(&_dsi_cmd_done_wait_queue);
+   init_waitqueue_head(&_dsi_dcs_read_wait_queue);
+   

[PATCH v5 05/10] drm/mediatek: cleaning up and refine

2016-07-28 Thread YT Shen
cleaning up unused define and refine function name and variable

Signed-off-by: shaoming chen 
Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |   77 +++-
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c |8 ++--
 2 files changed, 41 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2d808e5..a9cf5a1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -27,9 +27,6 @@

 #include "mtk_drm_ddp_comp.h"

-#define DSI_VIDEO_FIFO_DEPTH   (1920 / 4)
-#define DSI_HOST_FIFO_DEPTH64
-
 #define DSI_START  0x00

 #define DSI_CON_CTRL   0x10
@@ -46,7 +43,7 @@
 #define MIX_MODE   BIT(17)

 #define DSI_TXRX_CTRL  0x18
-#define VC_NUM (2 << 0)
+#define VC_NUM BIT(1)
 #define LANE_NUM   (0xf << 2)
 #define DIS_EOTBIT(6)
 #define NULL_ENBIT(7)
@@ -158,11 +155,11 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
 }

-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
 {
u32 timcon0, timcon1, timcon2, timcon3;
-   unsigned int ui, cycle_time;
-   unsigned int lpx;
+   u32 ui, cycle_time;
+   u32 lpx;

ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
@@ -192,7 +189,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
 }

-static void mtk_dsi_reset(struct mtk_dsi *dsi)
+static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
@@ -235,8 +232,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}

mtk_dsi_enable(dsi);
-   mtk_dsi_reset(dsi);
-   dsi_phy_timconfig(dsi);
+   mtk_dsi_reset_engine(dsi);
+   mtk_dsi_phy_timconfig(dsi);

return 0;

@@ -249,33 +246,33 @@ err_refcount:
return ret;
 }

-static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
 }

-static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
 }

-static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
 }

-static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
 {
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
 }

-static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
+static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
 {
u32 tmp_reg1;

@@ -283,15 +280,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
 }

-static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
+static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
 {
-   if (enter && !dsi_clk_hs_state(dsi))
+   if (enter && !mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
-   else if (!enter && dsi_clk_hs_state(dsi))
+   else if (!enter && mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
 }

-static void dsi_set_mode(struct mtk_dsi *dsi)
+static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
 {
u32 vid_mode = CMD_MODE;

@@ -306,7 +303,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
 }

-static void dsi_ps_control_vact(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
 {
struct videomode *vm = >vm;
u32 dsi_buf_bpp, ps_wc;
@@ -340,7 +337,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
 }

-static void dsi_rxtx_control(struct mtk_dsi *dsi)
+static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
 {
u32 tmp_reg;

@@ -365,9 +362,9 @@ static void dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
 }

-static void 

[PATCH v5 04/10] drm/mediatek: update display module connections

2016-07-28 Thread YT Shen
update connections for OVL, RDMA, BLS, DSI

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..329da541 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -32,6 +32,10 @@
 #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
 #define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100

+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+
 #define DISP_REG_MUTEX_EN(n)   (0x20 + 0x20 * (n))
 #define DISP_REG_MUTEX(n)  (0x24 + 0x20 * (n))
 #define DISP_REG_MUTEX_RST(n)  (0x28 + 0x20 * (n))
@@ -71,6 +75,10 @@
 #define DPI0_SEL_IN_RDMA1  0x1
 #define COLOR1_SEL_IN_OVL1 0x1

+#define OVL_MOUT_EN_RDMA   0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1   0x8
+#define DSI_SEL_IN_BLS 0x0
+
 struct mtk_disp_mutex {
int id;
bool claimed;
@@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
cur,
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
+   } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
+   *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+   value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
@@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
+   } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+   *addr = DISP_REG_CONFIG_DSI_SEL;
+   value = DSI_SEL_IN_BLS;
} else {
value = 0;
}
@@ -155,6 +169,14 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }

+static void mtk_ddp_sout_sel(void __iomem *config_regs,
+   enum mtk_ddp_comp_id cur, enum mtk_ddp_comp_id next)
+{
+   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+   writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+  config_regs + DISP_REG_CONFIG_OUT_SEL);
+}
+
 void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
@@ -167,6 +189,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
writel_relaxed(reg, config_regs + addr);
}

+   mtk_ddp_sout_sel(config_regs, cur, next);
+
value = mtk_ddp_sel_in(cur, next, );
if (value) {
reg = readl_relaxed(config_regs + addr) | value;
-- 
1.7.9.5



[PATCH v5 03/10] drm/mediatek: add shadow register support

2016-07-28 Thread YT Shen
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   75 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   25 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |1 +
 4 files changed, 74 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..80d9641 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -315,6 +315,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
*mtk_crtc)
pm_runtime_put(drm->dev);
 }

+static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+{
+   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+   struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+   unsigned int i;
+
+   /*
+* TODO: instead of updating the registers here, we should prepare
+* working registers in atomic_commit and let the hardware command
+* queue update module registers on vblank.
+*/
+   if (state->pending_config) {
+   mtk_ddp_comp_config(ovl, state->pending_width,
+   state->pending_height,
+   state->pending_vrefresh);
+
+   state->pending_config = false;
+   }
+
+   if (mtk_crtc->pending_planes) {
+   for (i = 0; i < OVL_LAYER_NR; i++) {
+   struct drm_plane *plane = _crtc->planes[i].base;
+   struct mtk_plane_state *plane_state;
+
+   plane_state = to_mtk_plane_state(plane->state);
+
+   if (plane_state->pending.config) {
+   mtk_ddp_comp_layer_config(ovl, i, plane_state);
+   plane_state->pending.config = false;
+   }
+   }
+   mtk_crtc->pending_planes = false;
+   }
+}
+
 static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -391,6 +427,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+   struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
int i;

@@ -409,6 +446,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
}
if (pending_planes)
mtk_crtc->pending_planes = true;
+
+   if (priv->data->shadow_register) {
+   mtk_disp_mutex_acquire(mtk_crtc->mutex);
+   mtk_crtc_ddp_config(crtc);
+   mtk_disp_mutex_release(mtk_crtc->mutex);
+   }
 }

 static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -453,36 +496,10 @@ err_cleanup_crtc:
 void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
 {
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
-   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
-   unsigned int i;
+   struct mtk_drm_private *priv = crtc->dev->dev_private;

-   /*
-* TODO: instead of updating the registers here, we should prepare
-* working registers in atomic_commit and let the hardware command
-* queue update module registers on vblank.
-*/
-   if (state->pending_config) {
-   mtk_ddp_comp_config(ovl, state->pending_width,
-   state->pending_height,
-   state->pending_vrefresh);
-
-   state->pending_config = false;
-   }
-
-   if (mtk_crtc->pending_planes) {
-   for (i = 0; i < OVL_LAYER_NR; i++) {
-   struct drm_plane *plane = _crtc->planes[i].base;
-   struct mtk_plane_state *plane_state;
-
-   plane_state = to_mtk_plane_state(plane->state);
-
-   if (plane_state->pending.config) {
-   mtk_ddp_comp_layer_config(ovl, i, plane_state);
-   plane_state->pending.config = false;
-   }
-   }
-   mtk_crtc->pending_planes = false;
-   }
+   if (!priv->data->shadow_register)
+   mtk_crtc_ddp_config(crtc);

mtk_drm_finish_page_flip(mtk_crtc);
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8030769..b77d456 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -12,6 +12,7 @@
  */

 #include 
+#include 
 #include 
 

[PATCH v5 02/10] drm/mediatek: add *driver_data for different hardware settings

2016-07-28 Thread YT Shen
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |   26 --
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|   11 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   11 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   27 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   13 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   25 ++---
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |8 
 7 files changed, 92 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8f62671f..eb5c05e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -40,8 +40,6 @@
 #defineOVL_RDMA_MEM_GMC0x40402020

 #define OVL_CON_BYTE_SWAP  BIT(24)
-#define OVL_CON_CLRFMT_RGB565  (0 << 12)
-#define OVL_CON_CLRFMT_RGB888  (1 << 12)
 #define OVL_CON_CLRFMT_RGBA(2 << 12)
 #define OVL_CON_CLRFMT_ARGB(3 << 12)
 #defineOVL_CON_AEN BIT(8)
@@ -136,18 +134,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, 
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
 }

-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_ddp_comp *comp, unsigned int 
fmt)
 {
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
-   return OVL_CON_CLRFMT_RGB565;
+   return comp->data->ovl.fmt_rgb565;
case DRM_FORMAT_BGR565:
-   return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+   return comp->data->ovl.fmt_rgb565 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
-   return OVL_CON_CLRFMT_RGB888;
+   return comp->data->ovl.fmt_rgb888;
case DRM_FORMAT_BGR888:
-   return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+   return comp->data->ovl.fmt_rgb888 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -177,7 +175,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);

-   con = ovl_fmt_convert(fmt);
+   con = ovl_fmt_convert(comp, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;

@@ -185,7 +183,8 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
-   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+   writel_relaxed(addr, comp->regs + comp->data->ovl.addr_offset
+   + idx * 0x20);

if (pending->enable)
mtk_ovl_layer_on(comp, idx);
@@ -269,6 +268,8 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}

+   priv->ddp_comp.data = of_device_get_match_data(dev);
+
platform_set_drvdata(pdev, priv);

ret = component_add(dev, _disp_ovl_component_ops);
@@ -285,8 +286,13 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
return 0;
 }

+static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
+   .ovl = {0x0f40, 0, 1 << 12}
+};
+
 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
-   { .compatible = "mediatek,mt8173-disp-ovl", },
+   { .compatible = "mediatek,mt8173-disp-ovl",
+ .data = _ovl_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 5fb80cb..fb0db50 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -122,7 +122,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
 */
threshold = width * height * vrefresh * 4 * 7 / 100;
reg = RDMA_FIFO_UNDERFLOW_EN |
- RDMA_FIFO_PSEUDO_SIZE(SZ_8K) |
+ RDMA_FIFO_PSEUDO_SIZE(comp->data->rdma_fifo_pseudo_size) |
  RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
 }
@@ -207,6 +207,8 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return ret;
}

+   priv->ddp_comp.data = of_device_get_match_data(dev);
+
 

[PATCH v5 01/10] drm/mediatek: rename macros, add chip prefix

2016-07-28 Thread YT Shen
Add MT8173 prefix for hardware related macros.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c |   60 
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 17ba935..2fc4321 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -36,21 +36,21 @@
 #define DISP_REG_MUTEX_MOD(n)  (0x2c + 0x20 * (n))
 #define DISP_REG_MUTEX_SOF(n)  (0x30 + 0x20 * (n))

-#define MUTEX_MOD_DISP_OVL0BIT(11)
-#define MUTEX_MOD_DISP_OVL1BIT(12)
-#define MUTEX_MOD_DISP_RDMA0   BIT(13)
-#define MUTEX_MOD_DISP_RDMA1   BIT(14)
-#define MUTEX_MOD_DISP_RDMA2   BIT(15)
-#define MUTEX_MOD_DISP_WDMA0   BIT(16)
-#define MUTEX_MOD_DISP_WDMA1   BIT(17)
-#define MUTEX_MOD_DISP_COLOR0  BIT(18)
-#define MUTEX_MOD_DISP_COLOR1  BIT(19)
-#define MUTEX_MOD_DISP_AAL BIT(20)
-#define MUTEX_MOD_DISP_GAMMA   BIT(21)
-#define MUTEX_MOD_DISP_UFOEBIT(22)
-#define MUTEX_MOD_DISP_PWM0BIT(23)
-#define MUTEX_MOD_DISP_PWM1BIT(24)
-#define MUTEX_MOD_DISP_OD  BIT(25)
+#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
+#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
+#define MT8173_MUTEX_MOD_DISP_RDMA0BIT(13)
+#define MT8173_MUTEX_MOD_DISP_RDMA1BIT(14)
+#define MT8173_MUTEX_MOD_DISP_RDMA2BIT(15)
+#define MT8173_MUTEX_MOD_DISP_WDMA0BIT(16)
+#define MT8173_MUTEX_MOD_DISP_WDMA1BIT(17)
+#define MT8173_MUTEX_MOD_DISP_COLOR0   BIT(18)
+#define MT8173_MUTEX_MOD_DISP_COLOR1   BIT(19)
+#define MT8173_MUTEX_MOD_DISP_AAL  BIT(20)
+#define MT8173_MUTEX_MOD_DISP_GAMMABIT(21)
+#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
+#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
+#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
+#define MT8173_MUTEX_MOD_DISP_OD   BIT(25)

 #define MUTEX_SOF_SINGLE_MODE  0
 #define MUTEX_SOF_DSI0 1
@@ -80,21 +80,21 @@ struct mtk_ddp {
 };

 static const unsigned int mutex_mod[DDP_COMPONENT_ID_MAX] = {
-   [DDP_COMPONENT_AAL] = MUTEX_MOD_DISP_AAL,
-   [DDP_COMPONENT_COLOR0] = MUTEX_MOD_DISP_COLOR0,
-   [DDP_COMPONENT_COLOR1] = MUTEX_MOD_DISP_COLOR1,
-   [DDP_COMPONENT_GAMMA] = MUTEX_MOD_DISP_GAMMA,
-   [DDP_COMPONENT_OD] = MUTEX_MOD_DISP_OD,
-   [DDP_COMPONENT_OVL0] = MUTEX_MOD_DISP_OVL0,
-   [DDP_COMPONENT_OVL1] = MUTEX_MOD_DISP_OVL1,
-   [DDP_COMPONENT_PWM0] = MUTEX_MOD_DISP_PWM0,
-   [DDP_COMPONENT_PWM1] = MUTEX_MOD_DISP_PWM1,
-   [DDP_COMPONENT_RDMA0] = MUTEX_MOD_DISP_RDMA0,
-   [DDP_COMPONENT_RDMA1] = MUTEX_MOD_DISP_RDMA1,
-   [DDP_COMPONENT_RDMA2] = MUTEX_MOD_DISP_RDMA2,
-   [DDP_COMPONENT_UFOE] = MUTEX_MOD_DISP_UFOE,
-   [DDP_COMPONENT_WDMA0] = MUTEX_MOD_DISP_WDMA0,
-   [DDP_COMPONENT_WDMA1] = MUTEX_MOD_DISP_WDMA1,
+   [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
+   [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
+   [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
+   [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+   [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
+   [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
+   [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
+   [DDP_COMPONENT_PWM1] = MT8173_MUTEX_MOD_DISP_PWM1,
+   [DDP_COMPONENT_RDMA0] = MT8173_MUTEX_MOD_DISP_RDMA0,
+   [DDP_COMPONENT_RDMA1] = MT8173_MUTEX_MOD_DISP_RDMA1,
+   [DDP_COMPONENT_RDMA2] = MT8173_MUTEX_MOD_DISP_RDMA2,
+   [DDP_COMPONENT_UFOE] = MT8173_MUTEX_MOD_DISP_UFOE,
+   [DDP_COMPONENT_WDMA0] = MT8173_MUTEX_MOD_DISP_WDMA0,
+   [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
 };

 static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
-- 
1.7.9.5



[PATCH v5 00/10] MT2701 DRM support

2016-07-28 Thread YT Shen
This is MT2701 DRM support PATCH v5, based on 4.7-rc1.
We add DSI interrupt control, transfer function for MIPI DSI panel support.
Most codes are the same, except some register changed.

For example:
 - DISP_OVL address offset changed, color format definition changed.
 - DISP_RDMA fifo size changed.
 - DISP_COLOR offset changed.
 - MIPI_TX setting changed.

We add a new component DDP_COMPONENT_BLS, and the connections are updated.
OVL -> RDMA -> COLOR -> BLS -> DSI
RDMA -> DPI
And we have shadow register support in MT2701.

Changes since v4:
- Add messages when timeout in mtk_disp_mutex_acquire()
- Add descriptions for DISP_REG_MUTEX registers
- Move connection settings for display modules to a separate patch
- Remove 'mt2701-disp-wdma' because it is unused
- Move cleaning up and renaming to a separate patch
- Use wait_event_interruptible_timeout() to replace polling
- Remove irq_num from mtk_dsi structure
- Remove redundant and debug codes

Changes since v3:
- Add DSI support for MIPI DSI panels
- Update BLS binding to PWM nodes
- Remove ufoe device nodes
- Remove redundant parentheses
- Remove global variable initialization

Changes since v2:
- Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
- Update mt2701_mtk_ddp_ext components
- Changed to prefix naming
- Reorder the patch series
- Use of_device_get_match_data() to get driver private data
- Use iopoll macros to implement mtk_disp_mutex_acquire()
- Removed empty device tree nodes

Changes since v1:
- Removed BLS bindings and codes, which belong to pwm driver
- Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
- Split patch into smaller parts
- Added const keyword to constant structure
- Removed codes for special memory align

The PATCH depends on the following patch:
https://patchwork.kernel.org/patch/8832441/ ("dt-bindings: ARM: Mediatek: 
Document bindings for MT2701")
https://patchwork.kernel.org/patch/9222997/ ("dt-bindings: pwm: Add MediaTek 
display PWM bindings")
https://patchwork.kernel.org/patch/9164029/ ("dt-bindings: mediatek: add 
descriptions for mediatek mt2701 iommu and smi")
https://patchwork.kernel.org/patch/9164017/ ("iommu/mediatek: move the common 
struct into header file")
https://patchwork.kernel.org/patch/9164025/ ("memory/mediatek: add support for 
mt2701")
https://patchwork.kernel.org/patch/9164041/ ("iommu/mediatek: add support for 
mtk iommu generation one HW")
https://patchwork.kernel.org/patch/9164013/ ("ARM: dts: mt2701: add iommu/smi 
dtsi node for mt2701")

Thanks,
yt.shen

YT Shen (8):
  drm/mediatek: rename macros, add chip prefix
  drm/mediatek: add *driver_data for different hardware settings
  drm/mediatek: add shadow register support
  drm/mediatek: update display module connections
  drm/mediatek: cleaning up and refine
  drm/mediatek: update DSI sub driver flow
  drm/mediatek: add support for Mediatek SoC MT2701
  arm: dts: mt2701: Add display subsystem related nodes for MT2701

shaoming chen (2):
  drm/mediatek: add dsi interrupt control
  drm/mediatek: add dsi transfer function

 arch/arm/boot/dts/mt2701.dtsi   |  100 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |   32 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|   17 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   75 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |  137 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   34 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   14 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   55 ++-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |9 +
 drivers/gpu/drm/mediatek/mtk_dsi.c  |  548 ---
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |   67 +++-
 12 files changed, 930 insertions(+), 160 deletions(-)

-- 
1.7.9.5



[PATCH v7 1/4] drm: add generic zpos property

2016-07-28 Thread Benjamin Gaignard
2016-07-28 14:55 GMT+02:00 Emil Velikov :
> Hi Benjamin,
>
> Just spotted a couple of small bits which, imho, should be fine with
> squashing with follow up patch(es).
>
> On 28 July 2016 at 09:07, Benjamin Gaignard
>  wrote:
>
>> +EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos);
> The symbols is internal only thus the EXPORT_SYMBOL notation isn't needed.
> Rule of thumb - interfaces used by other modules are declared in
> include/drm and the symbol(s) should be annotated with EXPORT_SYMBOL*
>
drm_blend.c is linked into drm.o while
drm_atomic_helper_normalize_zpos is used in
drm_atomic_helper.c linked within drm_kms_helper.o
so EXPORT_SYMBOL is need either I got linked error while compiling drm
as a module

>> +
>> +int drm_plane_atomic_set_zpos_property(struct drm_plane *plane,
>> +  struct drm_plane_state *state,
>> +  struct drm_property *property,
>> +  uint64_t val);
>> +
>> +int drm_plane_atomic_get_zpos_property(struct drm_plane *plane,
>> +  const struct drm_plane_state *state,
>> +  struct drm_property *property,
>> +  uint64_t *val);
>> +
> Dead code/declarations ?
>

yes dead code, I will remove it.

> Cheers,
> Emil

Thanks,
Benjamin

-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog


[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

2016-07-28 Thread Jose Abreu
Hi,


On 24-06-2016 03:40, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
>
> Current dw-hdmi is supporting sound via AHB bus, but it has
> I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
> This HDMI I2S is supported by using ALSA SoC common HDMI encoder
> driver.
>
> Signed-off-by: Kuninori Morimoto 
> ---
>

I just tested this patch and everything seems ok. Should I give
my tested-by?

Best regards,
Jose Miguel Abreu


[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

2016-07-28 Thread Matt Roper
This is completely untested (and probably horribly broken/buggy), but
here's a quick mockup of the general approach I was thinking for
ensuring DDB & WM's can be updated together while ensuring the
three-step pipe flushing process is honored:

https://github.com/mattrope/kernel/commits/experimental/lyude_ddb

Basically the idea is to take note of what's happening to the pipe's DDB
allocation (shrinking, growing, unchanged, etc.) during the atomic check
phase; then during the commit phase, we loop over the CRTC's three times
instead of just once, but only operate on a subset of the CRTC's in each
loop.  While operating on each CRTC, the plane, WM, and DDB all get
programmed together and have a single flush for all three.



Matt

On Tue, Jul 26, 2016 at 01:34:36PM -0400, Lyude wrote:
> Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the whole
> thing to keep it in one place.
> 
> Lyude (5):
>   drm/i915/skl: Add support for the SAGV, fix underrun hangs
>   drm/i915/skl: Only flush pipes when we change the ddb allocation
>   drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()
>   drm/i915/skl: Update plane watermarks atomically during plane updates
>   drm/i915/skl: Always wait for pipes to update after a flush
> 
> Matt Roper (1):
>   drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
> 
>  drivers/gpu/drm/i915/i915_drv.h  |   3 +
>  drivers/gpu/drm/i915/i915_reg.h  |   5 +
>  drivers/gpu/drm/i915/intel_display.c |  24 
>  drivers/gpu/drm/i915/intel_drv.h |   4 +
>  drivers/gpu/drm/i915/intel_pm.c  | 240 
> +++
>  drivers/gpu/drm/i915/intel_sprite.c  |   2 +
>  6 files changed, 255 insertions(+), 23 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795


[Bug 97116] mpv needs VAAPI_DISABLE_INTERLACE=1 for swdecode -vo vaapi since st/va: add conversion for yv12 to nv12in putimage v2

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97116

Bug ID: 97116
   Summary: mpv needs VAAPI_DISABLE_INTERLACE=1 for swdecode  -vo
vaapi since st/va: add conversion for yv12 to nv12in
putimage v2
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

since 

mesa commit 34f46348438b29e20d06cca312616cfba8ee05f6

For putimage call, if image format is yv12 (or IYUV with U V field swap) and
surface format is nv12, then we need to convert yv12 to nv12 and then copy the
converted data from image to surface. We can't use the existing logic where
surface is destroyed and re-created with yv12 format.

v2 (chk): fix some compiler warnings and commit message 

mpv --vo=vaapi will produce corrupted output without the new env
VAAPI_DISABLE_INTERLACE=1

This only applies to s/w decode as hwdec uses nv12 and avoids the conversion.

Gstreamer vaapisink is not affected as (from what little debugging I did) it
doesn't seem to use interlaced buffers doing putimage.

-- 
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/20160728/e62cba4f/attachment.html>


[PATCH v2 05/13] gpu: ipu-v3: Add IDMA channel linking support

2016-07-28 Thread Steve Longerbeam


On 07/26/2016 03:06 AM, Philipp Zabel wrote:
> Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam:
>> Adds functions to link and unlink IDMAC source channels to sink
>> channels.
>>
>> So far the following links are supported:
>>
>> IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
>> PUV3_CHANNEL_IC_PRP_VF_MEM   -> IPUV3_CHANNEL_MEM_ROT_VF
>> IPUV3_CHANNEL_IC_PP_MEM  -> IPUV3_CHANNEL_MEM_ROT_PP
>>
>> More links can be added to the idmac_link_info[] array.
>>
>> Signed-off-by: Steve Longerbeam 
> This patch looks good to me, but the Frame Synchronisation Unit supports
> also linking the internal channels, not only the IDMAC channels.
>
> [...]
>> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> [...]
>> +static const struct idmac_link_info idmac_link_info[] = {
>> +{
>> +.src  = { IPUV3_CHANNEL_IC_PRP_ENC_MEM, IPU_FS_PROC_FLOW1,
>> +  0, 4, 7 },
>> +.sink = { IPUV3_CHANNEL_MEM_ROT_ENC, IPU_FS_PROC_FLOW2,
>> +  0, 4, 1 },
>> +}, {
>> +.src =  { IPUV3_CHANNEL_IC_PRP_VF_MEM, IPU_FS_PROC_FLOW1,
>> +  8, 4, 8 },
>> +.sink = { IPUV3_CHANNEL_MEM_ROT_VF, IPU_FS_PROC_FLOW2,
>> +  4, 4, 1 },
>> +}, {
>> +.src =  { IPUV3_CHANNEL_IC_PP_MEM, IPU_FS_PROC_FLOW1,
>> +  16, 4, 5 },
>> +.sink = { IPUV3_CHANNEL_MEM_ROT_PP, IPU_FS_PROC_FLOW2,
>> +  12, 4, 3 },
>> +},
>> +};
> How about adding new (internal) channel numbers for the CSI->VDI link
> and having something like:
>
>   {
>   .src =  { IPUV3_CHANNEL_CSI_DIRECT, IPU_FS_PROC_FLOW1,
> FS_VDI_SRC_SEL_OFFSET, 2, 1 },
>   .sink = { IPUV3_CHANNEL_VDI_CUR, 0, 0, 0 },
>   },
>
> instead of ipu_set_vdi_src_mux? Then in addition to
>
> [...]
>> +int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink)
> We could have a lower level
>
> ipu_fsu_link(int channel1, int channel2)
>
> which could be called like
>
> ipu_fsu_link(IPUV3_CHANNEL_CSI_DIRECT, IPUV3_CHANNEL_VDI_CUR);
>
> Come to think of it, could we replace shift,bits,sel with mask,value and
> add #defines for the FSU bit fields and values? I'm thinking:
>
> /* FS_PROC_FLOW1 */
> #define FS_PRPENC_ROT_SRC_SEL_MASK(0xf << 0)
> #define FS_PRPENC_ROT_SRC_SEL_ENC (0x7 << 0)
> #define FS_PRPVF_ROT_SRC_SEL_MASK (0xf << 8)
> #define FS_PRPVF_ROT_SRC_SEL_VF   (0x8 << 8)
> #define FS_PP_SRC_SEL_MASK(0xf << 12)
> #define FS_PP_ROT_SRC_SEL_MASK(0xf << 16)
> #define FS_PP_ROT_SRC_SEL_PP  (0x5 << 16)
> #define FS_VDI1_SRC_SEL_MASK  (0x3 << 20)
> #define FS_VDI3_SRC_SEL_MASK  (0x3 << 20)
> #define FS_PRP_SRC_SEL_MASK   (0xf << 24)
> #define FS_VDI_SRC_SEL_MASK   (0x3 << 28)
>
> /* FS_PROC_FLOW2 */
> #define FS_PRP_ENC_DEST_SEL_MASK  (0xf << 0)
> #define FS_PRP_ENC_DEST_SEL_IRT_ENC   (0x1 << 0)
> #define FS_PRPVF_DEST_SEL_MASK(0xf << 4)
> #define FS_PRPVF_DEST_SEL_IRT_VF  (0x1 << 4)
> #define FS_PRPVF_ROT_DEST_SEL_MASK(0xf << 8)
> #define FS_PP_DEST_SEL_MASK   (0xf << 12)
> #define FS_PP_DEST_SEL_IRT_PP (0x3 << 12)
> #define FS_PP_ROT_DEST_SEL_MASK   (0xf << 16)
> #define FS_PRPENC_ROT_DEST_SEL_MASK   (0xf << 20)
> #define FS_PRP_DEST_SEL_MASK  (0xf << 24)
>
> struct idmac_link_reg_info {
>   int chno;
>   u32 reg;
>   u32 mask;
>   u32 val;
> };
>
> static const struct idmac_link_info idmac_link_info[] = {
>   {
>   .src  = { IPUV3_CHANNEL_IC_PRP_ENC_MEM, IPU_FS_PROC_FLOW1,
> FS_PRPENC_ROT_SRC_SEL_MASK, FS_PRPENC_ROT_SRC_SEL_ENC 
> },
>   .sink = { IPUV3_CHANNEL_MEM_ROT_ENC, IPU_FS_PROC_FLOW2,
> FS_PRP_ENC_DEST_SEL_MASK, FS_PRP_ENC_DEST_SEL_IRT_ENC 
> },
>   }, {
> .src =  { IPUV3_CHANNEL_IC_PRP_VF_MEM, IPU_FS_PROC_FLOW1,
>   FS_PRPVF_ROT_SRC_SEL_MASK, FS_PRPVF_ROT_SRC_SEL_VF 
> },
> .sink = { IPUV3_CHANNEL_MEM_ROT_VF, IPU_FS_PROC_FLOW2,
>   FS_PRPVF_DEST_SEL_MASK, FS_PRPVF_DEST_SEL_IRT_VF },
>   }, {
> .src =  { IPUV3_CHANNEL_IC_PP_MEM, IPU_FS_PROC_FLOW1,
>   FS_PP_ROT_SRC_SEL_MASK, FS_PP_ROT_SRC_SEL_PP },
> .sink = { IPUV3_CHANNEL_MEM_ROT_PP, IPU_FS_PROC_FLOW2,
>   FS_PP_DEST_SEL_MASK, FS_PP_DEST_SEL_IRT_PP },
>   },
> };

Hi Philipp,

Great ideas. I'll work on this for next version, or shall I let you? 
Should we create an
ipu-fsu.c ?

Steve



[PATCH v4 2/5] dma-buf/sync_file: refactor fence storage in struct sync_file

2016-07-28 Thread Sumit Semwal
Hi Greg,

On 19 July 2016 at 17:51, Sumit Semwal  wrote:
> (Adding Greg KH)
>
> Hi Greg,
>
> On 19 July 2016 at 17:45, Sumit Semwal  wrote:
>> Hi Greg,
>>
>>
>> On 12 July 2016 at 23:38, Gustavo Padovan  wrote:
>>> From: Gustavo Padovan 
>>>
>>> Create sync_file->fence to abstract the type of fence we are using for
>>> each sync_file. If only one fence is present we use a normal struct fence
>>> but if there is more fences to be added to the sync_file a fence_array
>>> is created.
>>>
>>> This change cleans up sync_file a bit. We don't need to have sync_file_cb
>>> array anymore. Instead, as we always have  one fence, only one fence
>>> callback is registered per sync_file.
>>>
>> Since this is a simple change in sync_debug,c, may I request for your
>> Ack so I could take it along with the other dma-buf patches?
>>
> Missed the fact that you weren't CCed; for this simple update to
> sync_debug,c, may I request for your Ack so I can take it with dam-buf
> patches?

Gentle reminder please: since it's a small change, if you could Ack
it, I'd be happy to take it along with the dma-buf patches and queue
it up.

>>> v4: fixes checkpatch warnings
>>>
>>> v4: Comments from Chris Wilson
>>> - use sizeof(*fence) to reallocate array
>>> - fix typo in comments
>>> - protect num_fences sum against overflows
>>> - use array->base instead of casting the to struct fence
>>>
>>> v3: Comments from Chris Wilson and Christian König
>>> - struct sync_file lost status member in favor of 
>>> fence_is_signaled()
>>> - drop use of fence_array_teardown()
>>> - use sizeof(*fence) to allocate only an array on fence pointers
>>>
>>> v2: Comments from Chris Wilson and Christian König
>>> - Not using fence_ops anymore
>>> - fence_is_array() was created to differentiate fence from 
>>> fence_array
>>> - fence_array_teardown() is now exported and used under 
>>> fence_is_array()
>>> - struct sync_file lost num_fences member
>>>
>>> Cc: Chris Wilson 
>>> Cc: Christian König 
>>> Signed-off-by: Gustavo Padovan 
>>> Reviewed-by: Chris Wilson 
>>> Acked-by: Christian König 
>>> ---
>>>  drivers/dma-buf/sync_file.c  | 169 
>>> +++
>>>  drivers/staging/android/sync_debug.c |  12 ++-
>>>  include/linux/sync_file.h|  17 ++--
>>>  3 files changed, 124 insertions(+), 74 deletions(-)
>>>
>> 
>>
>>> diff --git a/drivers/staging/android/sync_debug.c 
>>> b/drivers/staging/android/sync_debug.c
>>> index 5f57499..e07958c 100644
>>> --- a/drivers/staging/android/sync_debug.c
>>> +++ b/drivers/staging/android/sync_debug.c
>>> @@ -159,10 +159,16 @@ static void sync_print_sync_file(struct seq_file *s,
>>> int i;
>>>
>>> seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
>>> -  sync_status_str(atomic_read(_file->status)));
>>> +  sync_status_str(!fence_is_signaled(sync_file->fence)));
>>>
>>> -   for (i = 0; i < sync_file->num_fences; ++i)
>>> -   sync_print_fence(s, sync_file->cbs[i].fence, true);
>>> +   if (fence_is_array(sync_file->fence)) {
>>> +   struct fence_array *array = 
>>> to_fence_array(sync_file->fence);
>>> +
>>> +   for (i = 0; i < array->num_fences; ++i)
>>> +   sync_print_fence(s, array->fences[i], true);
>>> +   } else {
>>> +   sync_print_fence(s, sync_file->fence, true);
>>> +   }
>>>  }
>>>
>>>  static int sync_debugfs_show(struct seq_file *s, void *unused)
>>> diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
>>> index c6ffe8b..2efc5ec 100644
>>> --- a/include/linux/sync_file.h
>>> +++ b/include/linux/sync_file.h
>>> @@ -19,12 +19,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -
>>> -struct sync_file_cb {
>>> -   struct fence_cb cb;
>>> -   struct fence *fence;
>>> -   struct sync_file *sync_file;
>>> -};
>>> +#include 
>>>
>>>  /**
>>>   * struct sync_file - sync file to export to the userspace
>>> @@ -32,10 +27,9 @@ struct sync_file_cb {
>>>   * @kref:  reference count on fence.
>>>   * @name:  name of sync_file.  Useful for debugging
>>>   * @sync_file_list:membership in global file list
>>> - * @num_fences:number of sync_pts in the fence
>>>   * @wq:wait queue for fence signaling
>>> - * @status:0: signaled, >0:active, <0: error
>>> - * @cbs:   sync_pts callback information
>>> + * @fence: fence with the fences in the sync_file
>>> + * @cb:fence callback information
>>>   */
>>>  struct sync_file {
>>> struct file *file;
>>> @@ -44,12 +38,11 @@ struct sync_file {
>>>  #ifdef CONFIG_DEBUG_FS
>>> struct list_headsync_file_list;
>>>  #endif
>>> -   int num_fences;
>>>
>>> wait_queue_head_t   wq;
>>> -   atomic_tstatus;

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=87682

--- Comment #25 from Thom  ---
AFAIK the patch is in since 4.7-RC4.
Could it be that your version is older ?

see also:
https://github.com/torvalds/linux/commit/9ef8537e68941d858924a3eacee5a1945767cbab

-- 
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/20160728/9045cc5b/attachment.html>


[PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation

2016-07-28 Thread Wei Yongjun
Use kmemdup rather than duplicating its implementation.

Generated by: scripts/coccinelle/api/memdup.cocci

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index a46a64c..b779b5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
size = amdgpu_bo_size(adev->uvd.vcpu_bo);
ptr = adev->uvd.cpu_addr;

-   adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL);
+   adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL);
if (!adev->uvd.saved_bo)
return -ENOMEM;

-   memcpy(adev->uvd.saved_bo, ptr, size);
-
return 0;
 }






[RFC 3/3] drm/text: Add VT console support

2016-07-28 Thread Noralf Trønnes
This adds VT console support.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm-text/Makefile  |   1 +
 drivers/gpu/drm/drm-text/drm-text-buffer.c |   2 +
 drivers/gpu/drm/drm-text/drm-text-vt.c | 197 +
 drivers/gpu/drm/drm-text/drm-text.h|  14 ++
 4 files changed, 214 insertions(+)
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c

diff --git a/drivers/gpu/drm/drm-text/Makefile 
b/drivers/gpu/drm/drm-text/Makefile
index be042b0..4427522 100644
--- a/drivers/gpu/drm/drm-text/Makefile
+++ b/drivers/gpu/drm/drm-text/Makefile
@@ -1,4 +1,5 @@
 drm-text-y := drm-text-console.o drm-text-buffer.o
+drm-text-$(CONFIG_VT) += drm-text-vt.o
 drm-text-$(CONFIG_DEBUG_FS) += drm-text-debugfs.o

 obj-m += drm-text.o
diff --git a/drivers/gpu/drm/drm-text/drm-text-buffer.c 
b/drivers/gpu/drm/drm-text/drm-text-buffer.c
index 91beb48..0f995d3 100644
--- a/drivers/gpu/drm/drm-text/drm-text-buffer.c
+++ b/drivers/gpu/drm/drm-text/drm-text-buffer.c
@@ -317,6 +317,7 @@ static int __init drm_text_init(void)
drm_text_scan_fbdev();

ret = drm_text_console_init();
+   ret = drm_text_vt_init();

return ret;
 }
@@ -327,6 +328,7 @@ static void __exit drm_text_exit(void)
unsigned int i;

drm_text_console_exit();
+   drm_text_vt_exit();
drm_text_debugfs_exit();

for (i = 0; i < MAX_DRM_TEXT_BUFFERS; i++)
diff --git a/drivers/gpu/drm/drm-text/drm-text-vt.c 
b/drivers/gpu/drm/drm-text/drm-text-vt.c
new file mode 100644
index 000..a999a41
--- /dev/null
+++ b/drivers/gpu/drm/drm-text/drm-text-vt.c
@@ -0,0 +1,197 @@
+#define DEBUG
+/*
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "drm-text.h"
+
+static unsigned int drm_text_vt_map[MAX_DRM_TEXT_BUFFERS];
+
+/* TODO: Some kind of mapping might be needed */
+static inline struct drm_text_buffer *drm_text_vt_get(unsigned int index)
+{
+   return drm_text_get(drm_text_vt_map[index]);
+}
+
+static const char *drm_text_con_startup(void)
+{
+   drm_text_debug("%s\n", __func__);
+   return "drm-vt";
+}
+
+static void drm_text_con_init(struct vc_data *vc, int init)
+{
+   struct drm_text_buffer *text = drm_text_vt_get(vc->vc_num);
+
+   drm_text_log("%s[%u](init=%d)\n", __func__, vc->vc_num, init);
+
+   vc->vc_can_do_color = 1;
+
+   if (!text) {
+   drm_text_log("%s[%u] no DRM device\n", __func__, vc->vc_num);
+   return;
+   }
+
+   if (init) {
+   vc->vc_cols = text->cols;
+   vc->vc_rows = text->rows;
+   } else {
+   vc_resize(vc, text->cols, text->rows);
+   }
+
+   drm_text_enable(text);
+}
+
+static void drm_text_con_deinit(struct vc_data *vc)
+{
+   drm_text_debug("%s[%u]\n", __func__, vc->vc_num);
+   pr_info("%s\n", __func__);
+}
+
+static void drm_text_con_putcs(struct vc_data *vc, const unsigned short *s,
+  int count, int y, int x)
+{
+   struct drm_text_buffer *text = drm_text_vt_get(vc->vc_num);
+   u16 *dest;
+
+   if (!text)
+   return;
+
+   dest = >text_buf[x + (y * text->cols)];
+
+   for (; count > 0; count--) {
+   scr_writew(scr_readw(s++), dest++);
+   }
+   drm_text_flush(text, false);
+}
+
+static void drm_text_con_putc(struct vc_data *vc, int ch, int y, int x)
+{
+   struct drm_text_buffer *text = drm_text_vt_get(vc->vc_num);
+   unsigned short chr;
+
+   if (!text)
+   return;
+
+   scr_writew(ch, );
+   drm_text_con_putcs(vc, , 1, y, x);
+}
+
+/* TODO: How do I actually test this? */
+static void drm_text_con_clear(struct vc_data *vc, int y, int x,
+  int height, int width)
+{
+   struct drm_text_buffer *text = drm_text_vt_get(vc->vc_num);
+
+   drm_text_debug("%s[%u]\n", __func__, vc->vc_num);
+
+   if (!text)
+   return;
+
+   scr_memcpyw(text->text_buf, (unsigned short *)vc->vc_pos,
+   vc->vc_cols * vc->vc_rows);
+   drm_text_flush(text, false);
+}
+
+static int drm_text_con_switch(struct vc_data *vc)
+{
+   drm_text_debug("%s[%u] %ux%u\n", __func__, vc->vc_num, vc->vc_cols, 
vc->vc_rows);
+
+   return 1; /* redrawing needed */
+}
+
+static void drm_text_con_set_palette(struct vc_data *vc, const unsigned char 
*table)
+{
+   drm_text_debug("%s[%u]\n", __func__, vc->vc_num);
+}
+
+static int drm_text_con_blank(struct vc_data *vc, int blank, int mode_switch)
+{
+   struct drm_text_buffer *text = drm_text_vt_get(vc->vc_num);
+   int ret;
+
+   drm_text_debug("%s[%u](blank=%d, mode_switch=%d)\n", __func__, 

[RFC 2/3] drm/text: Add panic and boot console support

2016-07-28 Thread Noralf Trønnes
This adds support for panic and boot console.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm-text/Makefile   |   2 +-
 drivers/gpu/drm/drm-text/drm-text-buffer.c  |   4 +-
 drivers/gpu/drm/drm-text/drm-text-console.c | 205 
 drivers/gpu/drm/drm-text/drm-text-debugfs.c |  89 
 drivers/gpu/drm/drm-text/drm-text.h |   4 +
 5 files changed, 302 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c

diff --git a/drivers/gpu/drm/drm-text/Makefile 
b/drivers/gpu/drm/drm-text/Makefile
index 48f55bc..be042b0 100644
--- a/drivers/gpu/drm/drm-text/Makefile
+++ b/drivers/gpu/drm/drm-text/Makefile
@@ -1,4 +1,4 @@
-drm-text-y := drm-text-buffer.o
+drm-text-y := drm-text-console.o drm-text-buffer.o
 drm-text-$(CONFIG_DEBUG_FS) += drm-text-debugfs.o

 obj-m += drm-text.o
diff --git a/drivers/gpu/drm/drm-text/drm-text-buffer.c 
b/drivers/gpu/drm/drm-text/drm-text-buffer.c
index 187dd4b..91beb48 100644
--- a/drivers/gpu/drm/drm-text/drm-text-buffer.c
+++ b/drivers/gpu/drm/drm-text/drm-text-buffer.c
@@ -308,7 +308,7 @@ static void drm_text_free(struct drm_text_buffer *text)

 static int __init drm_text_init(void)
 {
-   int ret = 0;
+   int ret;

ret = drm_text_debugfs_init();
if (ret)
@@ -316,6 +316,7 @@ static int __init drm_text_init(void)

drm_text_scan_fbdev();

+   ret = drm_text_console_init();

return ret;
 }
@@ -325,6 +326,7 @@ static void __exit drm_text_exit(void)
 {
unsigned int i;

+   drm_text_console_exit();
drm_text_debugfs_exit();

for (i = 0; i < MAX_DRM_TEXT_BUFFERS; i++)
diff --git a/drivers/gpu/drm/drm-text/drm-text-console.c 
b/drivers/gpu/drm/drm-text/drm-text-console.c
new file mode 100644
index 000..e7ef244
--- /dev/null
+++ b/drivers/gpu/drm/drm-text/drm-text-console.c
@@ -0,0 +1,205 @@
+#define DEBUG
+/*
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include "drm-text.h"
+
+static bool drm_text_console_panic;
+
+/**
+ * DOC: message/boot console
+ *
+ * The kernel message  is enabled by using console=drm[n] where n is
+ * the primary minor number. Only one console is supported.
+ */
+
+static void drm_text_console_write(struct console *con, const char *str,
+  unsigned int num)
+{
+   struct drm_text_buffer *text;
+
+   drm_text_debug("%s(num=%u)\n", __func__, num);
+   if (drm_text_console_panic)
+   return;
+
+   text = drm_text_get(con->index);
+   if (!text)
+   return;
+
+   drm_text_write(text, str, num);
+   drm_text_flush(text, false);
+}
+
+static int drm_text_console_setup(struct console *con, char *options)
+{
+   struct drm_text_buffer *text;
+
+   drm_text_debug("%s[%u](%s) data=%p\n", __func__, con->index, options, 
con->data);
+
+   text = drm_text_get(con->index);
+   if (text)
+   drm_text_enable(text);
+
+   return 0;
+}
+
+/* TODO: test as a boot console */
+static struct console drm_text_console = {
+   .name = "drm",
+   .write =drm_text_console_write,
+   .setup =drm_text_console_setup,
+   .flags =CON_PRINTBUFFER,
+   .index =-1,
+};
+
+/**
+ * DOC: panic console
+ *
+ * The panic  is always enabled and collects kernel messages in a
+ * buffer as they come in.
+ * When the kernel does panic(), a panic notifier enables all text buffers.
+ * On the next >write it replays the message buffer and starts
+ * writing to all text buffers. Flushing of the text buffer to the pixel
+ * buffer is done inline instead of using the worker.
+ */
+
+#define DRM_TEXT_PANIC_KMSGS_MAX SZ_1K
+
+struct drm_text_panic_console {
+   char kmsgs[DRM_TEXT_PANIC_KMSGS_MAX];
+   size_t kmsg_pos;
+};
+
+static void drm_text_panic_write(const char *str, unsigned int num)
+{
+   unsigned int i;
+
+   drm_text_debug("%s(num=%u)\n", __func__, num);
+
+   for (i = 0; i < MAX_DRM_TEXT_BUFFERS; i++)
+   if (drm_text_buffers[i])
+   drm_text_write(drm_text_buffers[i], str, num);
+}
+
+static void drm_text_panic_flush(void)
+{
+   unsigned int i;
+
+   drm_text_debug("%s()\n", __func__);
+
+   for (i = 0; i < MAX_DRM_TEXT_BUFFERS; i++)
+   if (drm_text_buffers[i])
+   drm_text_flush(drm_text_buffers[i], true);
+}
+
+static void drm_text_panic_console_write(struct console *con, const char *str,
+unsigned int num)
+{
+   struct drm_text_panic_console *pcon = con->data;
+   unsigned int i;
+
+   drm_text_debug("%s(num=%u)\n", __func__, num);
+

[RFC 1/3] drm: Add support for text framebuffer

2016-07-28 Thread Noralf Trønnes
This adds a text representation of a drm_framebuffer with backing object.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm-text/Makefile   |   4 +
 drivers/gpu/drm/drm-text/drm-text-buffer.c  | 336 
 drivers/gpu/drm/drm-text/drm-text-debugfs.c | 206 +
 drivers/gpu/drm/drm-text/drm-text.h |  81 +++
 5 files changed, 628 insertions(+)
 create mode 100644 drivers/gpu/drm/drm-text/Makefile
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f..94a846d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
 obj-$(CONFIG_DRM_ARCPGU)+= arc/
 obj-y  += hisilicon/
+obj-y += drm-text/
diff --git a/drivers/gpu/drm/drm-text/Makefile 
b/drivers/gpu/drm/drm-text/Makefile
new file mode 100644
index 000..48f55bc
--- /dev/null
+++ b/drivers/gpu/drm/drm-text/Makefile
@@ -0,0 +1,4 @@
+drm-text-y := drm-text-buffer.o
+drm-text-$(CONFIG_DEBUG_FS) += drm-text-debugfs.o
+
+obj-m += drm-text.o
diff --git a/drivers/gpu/drm/drm-text/drm-text-buffer.c 
b/drivers/gpu/drm/drm-text/drm-text-buffer.c
new file mode 100644
index 000..187dd4b
--- /dev/null
+++ b/drivers/gpu/drm/drm-text/drm-text-buffer.c
@@ -0,0 +1,336 @@
+#define DEBUG
+/*
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm-text.h"
+
+struct drm_text_buffer *drm_text_buffers[MAX_DRM_TEXT_BUFFERS];
+
+/**
+ * DOC: overview
+ *
+ * Text buffer format 16-bit: 4-bit bg color, 4-bit fg color, 8-bit character
+ * The CGA color palette is used: 4-bit RGBI: intense red green blue
+ *
+ * drm_text_get(): get a text buffer for a dev->primary->index
+ * Clients can write directly to the text buffer
+ * drm_text_write(): write string to text buffer (handles wrapping)
+ * drm_text_scroll(): scroll text buffer
+ * drm_text_flush(): flush text buffer to pixel buffer (uses worker unless 
panic)
+ * drm_text_enable/disable(): enabled/disable text buffer (mode setting)
+ *
+ */
+
+static const u32 drm_text_palette888[] = {
+   0x, /*  0 black */
+   0x00aa, /*  1 blue */
+   0xaa00, /*  2 green */
+   0x, /*  3 cyan */
+   0x00aa, /*  4 red */
+   0x00aa00aa, /*  5 magenta */
+   0x00aa5500, /*  6 brown */
+   0x00aa, /*  7 light gray */
+   0x0055, /*  8 dark gray */
+   0x00ff, /*  9 bright blue */
+   0x0055ff55, /* 10 bright green */
+   0x0055, /* 11 bright cyan */
+   0x00ff, /* 12 bright red */
+   0x00ff55ff, /* 13 bright magenta */
+   0x0055, /* 14 yellow */
+   0x00ff  /* 15 white */
+};
+
+static const u16 drm_text_palette565[] = {
+   0x, /*  0 black */
+   0x0015, /*  1 blue */
+   0x0540, /*  2 green */
+   0x0555, /*  3 cyan */
+   0xa800, /*  4 red */
+   0xa815, /*  5 magenta */
+   0xaaa0, /*  6 brown */
+   0xad55, /*  7 light gray */
+   0x52aa, /*  8 dark gray */
+   0x52bf, /*  9 bright blue */
+   0x57ea, /* 10 bright green */
+   0x57ff, /* 11 bright cyan */
+   0xfaaa, /* 12 bright red */
+   0xfabf, /* 13 bright magenta */
+   0xffea, /* 14 yellow */
+   0x  /* 15 white */
+};
+
+static void drm_text_render_char(struct drm_text_buffer *text, size_t x, 
size_t y)
+{
+   u16 cc = text->text_buf[x + (y * text->cols)];
+   const struct font_desc *font = text->font;
+   u16 *vmem = text->pixel_buf;
+   char c = cc;
+   unsigned int h, w;
+   const u8 *src;
+   u16 fg_col = drm_text_palette565[(cc & 0x0f00) >> 8];
+   u16 bg_col = drm_text_palette565[cc >> 12];
+
+   src = font->data + c * font->height;
+
+   for (h = 0; h < font->height; h++) {
+   u8 fontline = *(src + h);
+
+   for (w = 0; w < font->width; w++) {
+   size_t i = ((x * font->width) + w) + (((y * 
font->height) + h) * text->fb->width);
+
+   vmem[i] = fontline & BIT(7 - w) ? fg_col : bg_col;
+   }
+   }
+}
+
+static void drm_text_do_flush(struct drm_text_buffer *text)
+{
+   size_t x, y;
+
+   drm_text_debug("%s - IN\n", __func__);
+
+   for (y = 0; y < text->rows; y++) {
+   for (x = 0; x < text->cols; x++) {
+   /*
+* TODO
+  

[RFC 0/3] drm: Add DRM text mode

2016-07-28 Thread Noralf Trønnes
This patchset explores the idea of adding a DRM text mode
(like VGA text mode) to get an alternative to fbcon/fbdev.

David Hermann has done alot of work on a fbcon replacement:
- drm: add kernel-log renderer (Mar 2014)[1]
- kmscon:
  development started Nov 2011
  added to systemd Oct 2014
  removed from systemd Jul 2015[2]

Since this work seems to have stalled, I propose an alternative solution
to this problem that will also give VT console support while we're waiting
for a userspace console.

The idea is that the driver provides a modeset like with the fbdev emulation
code, and from this a text buffer representation is made. The console code
can now write to this text buffer and ask for the text buffer to be
flushed/rendered to the pixel buffer.

In this hack/implementation of the idea, I have just hijacked a CMA backed
fbdev framebuffer to keep it simple.
I have reused the default buffer format that VT uses.
Getting panic handling to actually work, seems to be a challenge as Daniel
describes on the DRMJanitors page[3].

Is this idea of a DRM text mode worth developing further?


Noralf.

[1] https://lwn.net/Articles/589858/
[2] https://github.com/systemd/systemd/pull/747
[3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork


Noralf Trønnes (3):
  drm: Add support for text framebuffer
  drm/text: Add panic and boot console support
  drm/text: Add VT console support

 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm-text/Makefile   |   5 +
 drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340 
 drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
 drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 
 drivers/gpu/drm/drm-text/drm-text-vt.c  | 197 
 drivers/gpu/drm/drm-text/drm-text.h |  99 
 7 files changed, 1142 insertions(+)
 create mode 100644 drivers/gpu/drm/drm-text/Makefile
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text.h

--
2.8.2



[PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

2016-07-28 Thread Thierry Reding
up their device. Describe the panel timing on device 
> > > tree,
> > > would make customer easy to use and reuse it.
> > Yes, that would perhaps make it easier for them to bring up the device.
> > But soon after they'll notice that there are glitches when turning the
> > panel on and off, and then they'll realize that they can't fix that
> > using their simple device tree.
> About the panel on and off, I don't think the panel-simple do the good
> enough.
> 
> panel-simple only have one gpio and one regulator, and their sequence is
> hard code, Why not a panel have two gpio or two regulator? On our project,
> we find many customer don't use the RC to do panel reset, they directly use
> gpio reset, so they need a gpio to do panel reset.

The driver is called panel-simple for a reason. It's not meant to cover
all possible use-cases, only the simple ones.

> the device tree panel's on and off function is what the next step I want to
> upstream, on our downstream kernel, we do like that:
> 
> panel {
> power_ctrl {
>   power0 {
>   gpios = ;
>   delay,ms = <3>;
>   }
>   power1 {
>   regulator = ;
>   delay,ms = <3>;
>   }
>   power2 {
>   backlight = ;
>   delay,ms = <3>;
>   }
> }
> }
> and on driver, power on sequence with power0->power1->power2, power down
> with power2->power1->power0.
> if user want to swap the power, can easy do that by  adjust dts power
> sequence.
> 
> this method can easy order the gpio, regulator, backlight sequence, judge
> the delay time and add new regulator or gpio.
> I think this panel power on and off method is better than panel-simple
> driver currently using.

That's almost exactly like the power sequences that Alex Courbot had
proposed about three years ago. The concept of such a thing was rejected
by device tree binding maintainers, which is why we ended up with what
we have now. I'm sure you can find a link to the discussion if you want
the details about why it got rejected.

All of that's described in the blog, by the way.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160728/1e412141/attachment-0001.sig>


[PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling

2016-07-28 Thread Steve Longerbeam
Hi Philipp,

On 07/26/2016 03:08 AM, Philipp Zabel wrote:
>
>>   
>> +/*
>> + * The IC Resizer has a restriction that the output frame from the
>> + * resizer must be 1024 or less in both width (pixels) and height
>> + * (lines).
>> + *
>> + * The image conversion support attempts to split up a conversion when
>> + * the desired output (converted) frame resolution exceeds the IC resizer
>> + * limit of 1024 in either dimension.
>> + *
>> + * If either dimension of the output frame exceeds the limit, the
>> + * dimension is split into 1, 2, or 4 equal stripes,
> Imagine converting a 320x200 image up to 1280x800, and consider only the
> x coordinate. The IC upscaler is a simple bilinear scaler.

Right, the upscaling is a simple linear interpolation between two
adjacent input pixels, just paraphrasing you.

> We want target pixel x' = 1279 to sample the source pixel x = 319, so
> the scaling factor rsc is calculated to:
>
> x = x' * (320-1)/(1280-1) = x' * 8192/rsc, with rsc = 32846
>
> That means that the target pixels x' = 639 and x' = 640 should be
> sampled (bilinearly) from x = 639 * 8192/32846. = 159.37 and x = 640 *
> 8192/32846. = 159.62, respectively.

I'm with you so far.

>
> Now split the frame in half and suddenly pixel x' = 640 is the start of
> a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be
> sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over
> the edge of the source image.

Here's where we part.

The 320x200 --> 1280x800 conversion is split into two 160x200 -->
640x800 conversions. The DMA controller and ipu_ic_task_init() are given
those width/height dimensions, not the dimensions of the original images.
So this is simply two separate 160x200 --> 640x800 conversions. The only
difference from a true 160x200 --> 640x800 image conversion is that the DMA
controller must be given the stride lengths of the original 320x200 and 
1280x800
images.

The rsc for the 160x200 --> 640x800 conversions is

x = x' * (160-1)/(640-1) = x' * 8192/rsc, so rsc = 32923


So original horizontal position 640 is really x' = 0 of the second 
conversion,
which is sampled at x = 0 of the second conversion. And the pixel at x' 
= 1279
is really x' = 639 of the second conversion, which is sampled at x = 639 
* 8192/32923
= 158.98, which does not read over the edge of the source tile.


> This problem gets worse if you start using arbitrary frame sizes and YUV
> planar images and consider that tile start addresses are (currently)
> limited to 8 byte boundaries, to the point that there are very visible
> seams in the center of the image, depending on scaling factor and image
> sizes.

Indeed there could be other parameters that would cause the resizer to
read past the edge of the source tiles, I will need to try and find such 
cases.
But not in the above case.

That said, I _have_ noticed seams, but I have always attributed them to the
fact that we have a discontinuity in color-space conversion and/or resize
interpolation at the boundary between tiles.

I've also found that the seams are quite noticeable when rendered to a
display overlay, but become significantly less pronounced if the images are
converted to a back buffer, and then page-flipped to front buffer when the
conversion (all tiles) completes.

Steve

> I wonder how much effort it would be to remove the tiling code for now
> and add it back in a second step once it is fixed? Otherwise we could
> just disallow scaled tiling for now, but I'd like this to be prepared
> for tiles with different sizes at least, before merging.
>
> regards
> Philipp
>



[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=87682

--- Comment #24 from Gilbert Smith  ---
(In reply to Thom from comment #21)
> Gilbert, same with me, also ubuntu 14.04 -> 16.04.
> 
> The patch is already in the 4.7+ kernel tree so it should be in the first
> 4.7 kernel (pre) release.
> 
> I'm not familiar with ubuntu's kernel policy and I also don't know anyone
> who does but I guess that the 4.7 kernel will land in  16.10 or 17.04.
> Best to ask the Ubuntu Kernelteam.

I just installed the new kernel 4.7.0-040700-generic but it didn't fix the
display problem. Reverting back to 3.13.0-92-generic. :(

-- 
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/20160728/ef76a3a4/attachment-0001.html>


ATPX changes in drm-next-4.8 and D3cold handling

2016-07-28 Thread Deucher, Alexander
> -Original Message-
> From: Peter Wu [mailto:peter at lekensteyn.nl]
> Sent: Thursday, July 21, 2016 6:43 AM
> To: Deucher, Alexander
> Cc: amd-gfx at lists.freedesktop.org; Zhang, Hawking; Koenig, Christian; dri-
> devel at lists.freedesktop.org; Christoph Haag
> Subject: ATPX changes in drm-next-4.8 and D3cold handling
> 
> Hi Alex,
> 
> There are a couple of changes for 4.8 that try to detect whether the
> "power_cntl" flag is present. Originally attributed to a firmware bug,
> it seems that the detection is performed too late resulting in flags
> that are always zero
> (https://bugzilla.kernel.org/show_bug.cgi?id=115321).  What PX platform
> are these patches tested with, did they have the same issue?
> 
> 
> In case you missed it, Dave's D3cold patches were succeeded by changes
> in PCI core. Relevant commits in the pci/pm branch:
> 
> 006d44e PCI: Add runtime PM support for PCIe ports
> 16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan
> d963f65 PCI: Power on bridges before scanning new devices
> 9d26d3a PCI: Put PCIe ports into D3 during suspend
> 43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports

Did those get merged yet?

> 
> With these changes, the nouveau driver had to disable use of the _DSM
> ACPI method (comparable to ATPX), otherwise both interfaces are used
> which could cause issues like being unable to resume the device.
> Also note that pcieport currently only handles D3cold for devices with a
> BIOS date in 2015 (or newer), you need to detect this with an approach
> like http://www.spinics.net/lists/linux-pci/msg52602.html
> 

My latest PX patches should handle this correctly.  We have flags in the ATPX 
interface to know what sort of system we are.  See:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8=b8c9fd5ad4b478ec1a5482177833e1a7082e48bd
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8=31764c1e3b2bd6e9c8eaea1318a215afb6a8bad9
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8=8491999285a3e5a5395ac87098bb1f26c465b62b

I just need to revert this commit once the d3cold patches land:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8=bdfb76040068d960cb9e226876be8a508d741c4a


> We also found that the Nvidia HDMI audio device (function 1) would
> prevent the pcieport from sleeping. For modern Nvidia hardware this is
> apparently not an issue because these somehow hide the audio device, but
> it might be an issue for AMD hardware. See also
> https://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html

Thanks for the heads up.

Alex

> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl


[PATCH v4 4/8] drm/mediatek: add support for Mediatek SoC MT2701

2016-07-28 Thread YT Shen
Hi Philipp, CK,

On Thu, 2016-07-28 at 10:07 +0800, CK Hu wrote:
> Hi, YT:
> 
> On Wed, 2016-07-27 at 12:03 +0200, Philipp Zabel wrote:
> > Am Dienstag, den 26.07.2016, 18:42 +0800 schrieb YT Shen:
> > > Hi CK,
> > > 
> > > On Wed, 2016-07-20 at 14:53 +0800, CK Hu wrote:
> > > > Hi, YT:
> > > > 
> > > > Some comments inline.
> > > > 
> > > > On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> > > > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > > > There is only one OVL engine in MT2701.
> > > > > 
> > > > > Signed-off-by: YT Shen 
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 
> > > > >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   41 
> > > > > +++
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 +
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
> > > > >  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   31 
> > > > > 
> > > > >  6 files changed, 92 insertions(+)
> > > > > 
> > > > 
> > > > [snip...]
> > > > 
> > > > >  
> > > > >  static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > > > > + { .compatible = "mediatek,mt2701-disp-ovl",   .data = (void 
> > > > > *)MTK_DISP_OVL },
> > > > >   { .compatible = "mediatek,mt8173-disp-ovl",   .data = (void 
> > > > > *)MTK_DISP_OVL },
> > > > > + { .compatible = "mediatek,mt2701-disp-rdma",  .data = (void 
> > > > > *)MTK_DISP_RDMA },
> > > > >   { .compatible = "mediatek,mt8173-disp-rdma",  .data = (void 
> > > > > *)MTK_DISP_RDMA },
> > > > > + { .compatible = "mediatek,mt2701-disp-wdma",  .data = (void 
> > > > > *)MTK_DISP_WDMA },
> > > > 
> > > > Is WDMA different from MT8173 to MT2701. If they are the same, you need
> > > > not to add compatible of 'mediatek,mt2701-disp-wdma' because use
> > > > 'mediatek,mt8173-disp-wdma' is enough.
> > > Yes, the hardware has differences, so we need add new compatible
> > > 'mt2701-disp-wdma'
> > 
> > It would be nice if you could add a short paragraph to the patch
> > description about what the hardware differences are (probably just
> > changed register layout in most cases).
Thanks for the suggestions, we will add more descriptions in the future.

> 
> If you don't want to add description, you may separate the modification
> of OVL, RDMA, WDMA, PWM to different patch. And you send patch of OVL
> and RDMA first because you have related code modification for these two.
> You temporarily treat WDMA and PWM as MT8173 and it works. And one day
> you need to modify code of WDMA and PWM for MT2701, then you send the
> patch of WDMA and PWM and you need not to add any description because we
> can find out the difference from source code.

The display module connections is shown in mt2701_mtk_ddp_main[] and
mt2701_mtk_ddp_ext[].
OVL -> RDMA -> COLOR -> BLS(pwm) -> DSI
RDMA -> DPI

This patch series mainly focus on DSI support for MT2701 SoC and the
basic functions.  The BLS(pwm) and DPI parts are not included here.

We will remove 'mt2701-disp-wdma'. We didn't implement its driver and it
is unused now.

For the pwm part, we need the device node to establish the display
module connections.  The pwm compatible string is described in
"dt-bindings: pwm: Add MediaTek display PWM bindings" [1] and the
control is implemented in "pwm: Add MediaTek MT2701 display PWM driver
support" [2].

For the dpi part, we need the device node to establish the display
module connections.  The dpi patch will be in another patch series,
split out from "drm/mediatek: fix the wrong pixel clock when resolution
is 4K" [3].


[1] https://patchwork.kernel.org/patch/9222997/
[2] https://patchwork.kernel.org/patch/9223001/
[3] https://patchwork.kernel.org/patch/9249471/ 

Regards,
yt.shen

> 
> > 
> > regards
> > Philipp
> > 
> 
> Regards,
> CK
> 




[PATCH 2/2] drm/amdgpu: enable UVD context buffer for older HW

2016-07-28 Thread Deucher, Alexander
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Leo Liu
> Sent: Thursday, July 28, 2016 10:13 AM
> To: amd-gfx at lists.freedesktop.org
> Cc: Koenig, Christian; dri-devel at lists.freedesktop.org
> Subject: [PATCH 2/2] drm/amdgpu: enable UVD context buffer for older HW
> 
> From: Christian König 
> 
> Supported starting on certain FW versions.
> 
> Signed-off-by: Christian König 
> Reviewed-by: Leo Liu 

Series is:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 28
> ++--
>  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index d406ec7..9c07e38 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1688,6 +1688,7 @@ struct amdgpu_uvd {
>   struct amdgpu_ring  ring;
>   struct amdgpu_irq_src   irq;
>   booladdress_64_bit;
> + booluse_ctx_buf;
>   struct amd_sched_entity entity;
>   uint32_tsrbm_soft_reset;
>  };
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 28c1b62..c22b64e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -41,8 +41,15 @@
> 
>  /* 1 second timeout */
>  #define UVD_IDLE_TIMEOUT msecs_to_jiffies(1000)
> +
> +/* Firmware versions for VI */
> +#define FW_1_65_10   ((1 << 24) | (65 << 16) | (10 << 8))
> +#define FW_1_87_11   ((1 << 24) | (87 << 16) | (11 << 8))
> +#define FW_1_87_12   ((1 << 24) | (87 << 16) | (12 << 8))
> +#define FW_1_37_15   ((1 << 24) | (37 << 16) | (15 << 8))
> +
>  /* Polaris10/11 firmware version */
> -#define FW_1_66_16 ((1 << 24) | (66 << 16) | (16 << 8))
> +#define FW_1_66_16   ((1 << 24) | (66 << 16) | (16 << 8))
> 
>  /* Firmware Names */
>  #ifdef CONFIG_DRM_AMDGPU_CIK
> @@ -220,6 +227,23 @@ int amdgpu_uvd_sw_init(struct amdgpu_device
> *adev)
>   if (!amdgpu_ip_block_version_cmp(adev,
> AMD_IP_BLOCK_TYPE_UVD, 5, 0))
>   adev->uvd.address_64_bit = true;
> 
> + switch (adev->asic_type) {
> + case CHIP_TONGA:
> + adev->uvd.use_ctx_buf = adev->uvd.fw_version >=
> FW_1_65_10;
> + break;
> + case CHIP_CARRIZO:
> + adev->uvd.use_ctx_buf = adev->uvd.fw_version >=
> FW_1_87_11;
> + break;
> + case CHIP_FIJI:
> + adev->uvd.use_ctx_buf = adev->uvd.fw_version >=
> FW_1_87_12;
> + break;
> + case CHIP_STONEY:
> + adev->uvd.use_ctx_buf = adev->uvd.fw_version >=
> FW_1_37_15;
> + break;
> + default:
> + adev->uvd.use_ctx_buf = adev->asic_type >=
> CHIP_POLARIS10;
> + }
> +
>   return 0;
>  }
> 
> @@ -529,7 +553,7 @@ static int amdgpu_uvd_cs_msg_decode(struct
> amdgpu_device *adev, uint32_t *msg,
>   /* reference picture buffer */
>   min_dpb_size = image_size * num_dpb_buffer;
> 
> - if (adev->asic_type < CHIP_POLARIS10){
> + if (!adev->uvd.use_ctx_buf){
>   /* macroblock context buffer */
>   min_dpb_size +=
>   width_in_mb * height_in_mb *
> num_dpb_buffer * 192;
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PULL] topic/drm-misc

2016-07-28 Thread Daniel Vetter
Hi Dave,

A few more simple fixes that Sean collected. There's a bunch of bigger
things on dri-devel, but I think those are all too late for 4.8 really.
I'll try and go collect them after -rc1 for 4.9.

Cheers, Daniel


The following changes since commit e8d3ef02787fc72996cfb423180dc79764c239fa:

  GPU-DRM-Exynos: Delete an unnecessary check before the function call "vunmap" 
(2016-07-21 14:06:33 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-07-28

for you to fetch changes up to 12ae57aab43880eac500c43590e26d9d4411961b:

  drm/arm: mali-dp: Fix error return code in malidp_bind() (2016-07-28 12:59:56 
+0200)


Brian Starkey (1):
  drm/arm: mali-dp: Set crtc.port to the port instead of the endpoint

Lee Jones (1):
  drm/sti: use new Reset API

Lukas Wunner (1):
  apple-gmux: Sphinxify docs

Markus Elfring (8):
  GPU-DRM-OMAP: Delete unnecessary checks before two function calls
  GPU-DRM-GMA500: Delete unnecessary checks before two function calls
  drm/bridge: ps8622: Delete an unnecessary check before 
backlight_device_unregister()
  drm/mgag200: Delete an unnecessary check before 
drm_gem_object_unreference_unlocked()
  drm/qxl: Delete an unnecessary check before 
drm_gem_object_unreference_unlocked()
  drm/vmwgfx: Delete an unnecessary check before the function call "vfree"
  drm/etnaviv: Delete unnecessary checks before two function calls
  drm/etnaviv: Optimize error handling in etnaviv_gem_new_userptr()

Stefan Christ (1):
  drm/gma500: remove unnecessary stub for fb_ioctl()

Wei Yongjun (2):
  drm/arm: mali-dp: Remove redundant dev_err call in malidp_bind()
  drm/arm: mali-dp: Fix error return code in malidp_bind()

 drivers/gpu/drm/arm/malidp_drv.c| 19 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c  |  4 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 16 +++
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |  9 ++--
 drivers/gpu/drm/gma500/framebuffer.c|  9 
 drivers/gpu/drm/gma500/psb_drv.c|  6 +--
 drivers/gpu/drm/gma500/psb_intel_lvds.c |  9 ++--
 drivers/gpu/drm/mgag200/mgag200_main.c  |  4 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c |  3 +-
 drivers/gpu/drm/omapdrm/omap_fb.c   |  4 +-
 drivers/gpu/drm/qxl/qxl_display.c   |  3 +-
 drivers/gpu/drm/sti/sti_compositor.c|  4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |  4 +-
 drivers/platform/x86/apple-gmux.c   | 55 +
 15 files changed, 66 insertions(+), 86 deletions(-)

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


[PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

2016-07-28 Thread Rob Herring
On Tue, Jul 26, 2016 at 4:02 AM, Thierry Reding
 wrote:
> On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote:
>> On 2016年07月25日 23:21, Thierry Reding wrote:
>>
>> On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote:
>>
>> Allow user add display timing on device tree with simple-panel-dsi
>> or simple-panel.
>>
>> Cc: Thierry Reding 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>>
>> Signed-off-by: Mark Yao 
>> ---
>>  .../bindings/display/panel/simple-panel.txt| 48 
>> ++
>>  1 file changed, 48 insertions(+)
>>
>> Sorry, not going to happen. Read this for an explanation of why not:
>>
>> 
>> https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html
>>
>> Thierry
>>
>>
>> Hi Thierry
>>
>> The blog actually not persuade me why can't use display timing on
>> device tree.
>
> Okay, perhaps read it again, it addresses most of your points below.
>
>> 1, Binding panel as a simple string on device tree seems simple on device 
>> tree,
>> but it's complex on kernel code, and kernel code would became bigger and
>> bigger.
>
> I don't think the video timings in the simple-panel driver are very
> complex. They also don't use very much space. And if you're really
> concerned about space you can always use conditional compilation and
> Kconfig symbols to remove timings for panels that you don't use.
>
> Also, panels are characterized by much more than just video timings.
> There were attempts, way back, to fully describe panels in device tree
> and that failed. What you propose here is a partial solution to a much
> more complex problem.
>
> This is all explained in the blog post.

While I agree with everything Thierry has said in this thread, there
is an argument to be made for timing information in DT.

Maybe most vendors have now learned that flexible clock frequencies
are needed to generate the correct timings, but I have worked on parts
without fine resolution (i.e. a dedicated pll). Even HiKey with HDMI
suffers from this. In that case you can be tuning the timings
(increasing the h and/or v blanks) to get the desired refresh rates.
So in that case, the panel compatible would not determine the display
timings and you could have the same panel with different timings on
different boards. That's maybe rare enough that putting timing info in
DT still wouldn't make sense.

But that is not the problem here, and everything else about this is wrong.

Rob


[PATCH v7 1/4] drm: add generic zpos property

2016-07-28 Thread Emil Velikov
Hi Benjamin,

Just spotted a couple of small bits which, imho, should be fine with
squashing with follow up patch(es).

On 28 July 2016 at 09:07, Benjamin Gaignard
 wrote:

> +EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos);
The symbols is internal only thus the EXPORT_SYMBOL notation isn't needed.
Rule of thumb - interfaces used by other modules are declared in
include/drm and the symbol(s) should be annotated with EXPORT_SYMBOL*

> +
> +int drm_plane_atomic_set_zpos_property(struct drm_plane *plane,
> +  struct drm_plane_state *state,
> +  struct drm_property *property,
> +  uint64_t val);
> +
> +int drm_plane_atomic_get_zpos_property(struct drm_plane *plane,
> +  const struct drm_plane_state *state,
> +  struct drm_property *property,
> +  uint64_t *val);
> +
Dead code/declarations ?

Cheers,
Emil


[PATCH -next] drm/arm: mali-dp: Fix error return code in malidp_bind()

2016-07-28 Thread Daniel Vetter
On Thu, Jul 28, 2016 at 09:22:21AM +0100, Brian Starkey wrote:
> Hi Wei,
> 
> On Thu, Jul 28, 2016 at 02:14:26AM +, Wei Yongjun wrote:
> > Fix to return error code -EINVAL from the error handling
> > case instead of 0, as done elsewhere in this function.
> > 
> > Fixes: 3c31760e760c ('drm/arm: mali-dp: Set crtc.port to the port
> > instead of the endpoint')
> > Signed-off-by: Wei Yongjun 
> > ---
> 
> Thanks for cleaning up after me! :-)
> 
> Acked-by: Brian Starkey 

Applied to drm-misc, thanks.
-Daniel

> 
> @Sean, can you pick this up on top of 3c31760e760c?
> 
> Cheers,
> Brian
> 
> > drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 4e61ea5..44b24cb 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -362,8 +362,10 @@ static int malidp_bind(struct device *dev)
> > 
> > /* Set the CRTC's port so that the encoder component can find it */
> > ep = of_graph_get_next_endpoint(dev->of_node, NULL);
> > -   if (!ep)
> > +   if (!ep) {
> > +   ret = -EINVAL;
> > goto port_fail;
> > +   }
> > malidp->crtc.port = of_get_next_parent(ep);
> > 
> > ret = component_bind_all(dev, drm);
> > 
> ___
> 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 -next] drm/arm: mali-dp: Remove redundant dev_err call in malidp_bind()

2016-07-28 Thread Daniel Vetter
On Thu, Jul 28, 2016 at 09:11:43AM +0100, Liviu Dudau wrote:
> On Thu, Jul 28, 2016 at 02:09:13AM +, Wei Yongjun wrote:
> > There is a error message within devm_ioremap_resource
> > already, so remove the DRM_ERROR call to avoid redundant
> > error message.
> 
> Yeah, good catch!
> 
> > 
> > Signed-off-by: Wei Yongjun 
> 
> Acked-by: Liviu Dudau 

Applied to drm-misc, thanks.
-Daniel

> 
> 
> Thanks for the cleanup!
> Liviu
> 
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 4e61ea5..1160322 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -285,10 +285,8 @@ static int malidp_bind(struct device *dev)
> >  
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > hwdev->regs = devm_ioremap_resource(dev, res);
> > -   if (IS_ERR(hwdev->regs)) {
> > -   DRM_ERROR("Failed to map control registers area\n");
> > +   if (IS_ERR(hwdev->regs))
> > return PTR_ERR(hwdev->regs);
> > -   }
> >  
> > hwdev->pclk = devm_clk_get(dev, "pclk");
> > if (IS_ERR(hwdev->pclk))
> > 
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯
> ___
> 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 2/2] drm/amd/powerplay: Delete unused functions in ppevvmath.h

2016-07-28 Thread Alex Deucher
On Tue, Jul 19, 2016 at 12:22 PM, Nils Wallménius
 wrote:
> Hi,
>
> This patch applies cleanly for me on top of the first patch in this series
> [1] on top of your drm-next-4.8 tree.
>
> The series was held up to figure out what to do about the unused functions
> as patch 1 introduced warnings. I can still respin if you'd like as now that
> i know the functions should be removed, doing that first makes a bit more
> sense I guess.

Sorry, I missed the first patch.  Applied the series.  Sorry for the delay.

Alex

>
> Nils
>
> [1]: https://lists.freedesktop.org/archives/dri-devel/2016-April/105648.html
>
> On Sat, Jul 16, 2016 at 5:51 AM, Nils Wallménius  gmail.com>
> wrote:
>>
>> Ok, cool. I will probably be able to do that on monday.
>>
>> Nils
>>
>>
>> Den 15 juli 2016 11:06 em skrev "Alex Deucher" :
>>>
>>> On Fri, Jul 15, 2016 at 4:09 PM, Nils Wallménius
>>>  wrote:
>>> > Ping?
>>>
>>> We don't seem to be using them.  Can you respin?  It doesn't seem to
>>> apply any longer.
>>>
>>> Alex
>>>
>>>
>>> >
>>> >
>>> > Den 6 juni 2016 21:32 skrev "Nils Wallménius"
>>> > :
>>> >>
>>> >> Hi Alex,
>>> >>
>>> >> Any response from the powerplay team?
>>> >>
>>> >> If they are unresponsive, would you prefer to #IF 0 the code instead
>>> >> of
>>> >> deleting?
>>> >>
>>> >> Regards
>>> >> Nils
>>> >>
>>> >> On Mon, Apr 25, 2016 at 10:08 PM, Alex Deucher 
>>> >> wrote:
>>> >>>
>>> >>> On Sun, Apr 24, 2016 at 7:22 AM, Nils Wallménius
>>> >>>  wrote:
>>> >>> > Signed-off-by: Nils Wallménius 
>>> >>>
>>> >>> Let me check with the powerplay team and make sure they are planning
>>> >>> to use these in the near future.
>>> >>>
>>> >>> Alex
>>> >>>
>>> >>>
>>> >>> > ---
>>> >>> >  drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h | 59
>>> >>> > +
>>> >>> >  1 file changed, 1 insertion(+), 58 deletions(-)
>>> >>> >
>>> >>> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
>>> >>> > b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
>>> >>> > index a9b40eb..8f50a03 100644
>>> >>> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
>>> >>> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
>>> >>> > @@ -64,7 +64,6 @@ static fInt fGetSquare(fInt);
>>> >>> > /* Returns the square
>>> >>> >  static fInt fSqrt(fInt);  /*
>>> >>> > Returns
>>> >>> > the Square Root of a fInt number */
>>> >>> >
>>> >>> >  static int uAbs(int); /*
>>> >>> > Returns
>>> >>> > the Absolute value of the Int */
>>> >>> > -static fInt fAbs(fInt);   /*
>>> >>> > Returns
>>> >>> > the Absolute value of the fInt */
>>> >>> >  static int uPow(int base, int exponent);  /*
>>> >>> > Returns
>>> >>> > base^exponent an INT */
>>> >>> >
>>> >>> >  static void SolveQuadracticEqn(fInt, fInt, fInt, fInt[]); /*
>>> >>> > Returns
>>> >>> > the 2 roots via the array */
>>> >>> > @@ -85,21 +84,12 @@ static fInt fDecodeLeakageID (uint32_t
>>> >>> > leakageID_fuse, fInt ln_max_div_min, fInt
>>> >>> >   *
>>> >>> >
>>> >>> > -
>>> >>> >   * Some of the following functions take two INTs as their input -
>>> >>> > This
>>> >>> > is unsafe for a variety of reasons.
>>> >>> >   */
>>> >>> > -static fInt Add (int, int);   /* Add
>>> >>> > two
>>> >>> > INTs and return Sum as FINT */
>>> >>> > -static fInt Multiply (int, int);  /*
>>> >>> > Multiply
>>> >>> > two INTs and return Product as FINT */
>>> >>> > -static fInt Divide (int, int);/* You
>>> >>> > get
>>> >>> > the idea... */
>>> >>> > +static fInt Divide (int, int);/*
>>> >>> > Divide
>>> >>> > two INTs and return result as FINT */
>>> >>> >  static fInt fNegate(fInt);
>>> >>> >
>>> >>> >  static int uGetScaledDecimal (fInt);  /*
>>> >>> > Internal
>>> >>> > function */
>>> >>> >  static int GetReal (fInt A);  /*
>>> >>> > Internal
>>> >>> > function */
>>> >>> >
>>> >>> > -/* Future Additions and Incomplete Functions
>>> >>> > - *
>>> >>> >
>>> >>> > -
>>> >>> > - */
>>> >>> > -static int GetRoundedValue(fInt); /*
>>> >>> > Incomplete function - Useful only when Precision is lacking */
>>> >>> > -  /* Let
>>> >>> > us
>>> >>> > say we have 2.126 but can only handle 2 decimal points. We could */
>>> >>> > -  /*
>>> >>> > either
>>> >>> > chop of 6 and keep 2.12 or use this function to get 2.13, which is
>>> >>> > more
>>> >>> > accurate */
>>> >>> > -
>>> >>> >  /*
>>> >>> >
>>> >>> > -
>>> >>> >   * TROUBLESHOOTING 

[PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-28 Thread Alex Deucher
On Mon, Jul 18, 2016 at 8:48 PM, Tejun Heo  wrote:
> On Sat, Jul 16, 2016 at 05:00:44PM +0530, Bhaktipriya Shridhar wrote:
>>
>> alloc_workqueue replaces deprecated create_singlethread_workqueue().
>>
>> Each hardware CRTC has a single flip work queue.
>> When a radeon_flip_work_func item is queued, it needs to be executed
>> ASAP because even a slight delay may cause the flip to be delayed by
>> one refresh cycle.
>>
>> Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
>> since a delay can cause the outcome to miss the refresh cycle.
>>
>> Since there are only a fixed number of work items, explicit concurrency
>> limit is unnecessary here.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>
> Acked-by: Tejun Heo 
>

Applied.  thanks!

Alex

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


[PATCH 0/8] drm/amdgpu: Fine-tuning for three function implementations

2016-07-28 Thread Alex Deucher
On Mon, Jul 18, 2016 at 3:41 AM, Christian König
 wrote:
> Am 16.07.2016 um 16:33 schrieb SF Markus Elfring:
>>
>> From: Markus Elfring 
>> Date: Sat, 16 Jul 2016 16:23:21 +0200
>>
>> Further update suggestions were taken into account after patches
>> were applied from static source code analysis.
>
>
> Small coding style nit pick on patch #7:
>>
>> -   }
>> +   } else
>> +   temp_storage = NULL;
>
> When an "if" has "{" and "}" the else should also use them even when it is
> only one line.
>
> With that fixed the whole series is Reviewed-by: Christian König
> , but as Walter Harms pointed out as well there
> are a couple of other things we could make more as well.

Applied the series except patch 2 was which already fixed by an earlier patch.

Thanks!

Alex

>
> Regards,
> Christian.
>
>>
>> Markus Elfring (8):
>>Delete an unnecessary check before
>> drm_gem_object_unreference_unlocked()
>>Delete unnecessary checks before the function call "kfree"
>>One function call less in amdgpu_cgs_acpi_eval_object() after error
>> detection
>>Delete a variable in amdgpu_cgs_acpi_eval_object()
>>Delete an unnecessary variable initialisation in
>> amdgpu_cgs_acpi_eval_object()
>>Change assignment for a variable in amdgpu_cgs_acpi_eval_object()
>>Change assignment for a buffer variable in phm_dispatch_table()
>>Delete an unnecessary variable initialisation in phm_dispatch_table()
>>
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 28
>> ++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  4 +---
>>   .../gpu/drm/amd/powerplay/hwmgr/functiontables.c   | 12 --
>>   3 files changed, 19 insertions(+), 25 deletions(-)
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] GPU-DRM-Radeon: Delete an unnecessary check before drm_gem_object_unreference_unlocked()

2016-07-28 Thread Alex Deucher
On Tue, Jul 12, 2016 at 4:22 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 12 Jul 2016 22:00:55 +0200
>
> The drm_gem_object_unreference_unlocked() function tests whether
> its argument is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 5f1cd69..1efab5f 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1324,9 +1324,7 @@ static void radeon_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>  {
> struct radeon_framebuffer *radeon_fb = to_radeon_framebuffer(fb);
>
> -   if (radeon_fb->obj) {
> -   drm_gem_object_unreference_unlocked(radeon_fb->obj);
> -   }
> +   drm_gem_object_unreference_unlocked(radeon_fb->obj);
> drm_framebuffer_cleanup(fb);
> kfree(radeon_fb);
>  }
> --
> 2.9.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

2016-07-28 Thread Bibby Hsieh
Hi, Philipp,

Thanks for your comments.

On Wed, 2016-07-27 at 11:23 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > Pixel clock should be 297MHz when resolution is 4K.
> 
> This patch does two different things, please don't conflate them.
> 
> First, it adds support for 16*3 and 2*3 factors between PLL and pixel
> clock. This should be a separate patch and does what this patch
> description says.
> 
> The second part moves the clocks into an array and adds an indirection
> to clock registration depending on of_match_node. This should be a
> separate patch. I suppose this change is in preparation for mt2701
> support, but I'm not sure yet if it is needed at all.
> 

Ok, I will move the change for mt2701 to another patch and send it until
mt2701 start upstream.

> regards
> Philipp
> 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c |  149 
> > +++-
> >  1 file changed, 96 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index d05ca79..fa390e0 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -60,14 +60,25 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> >  };
> >  
> > +enum mtk_dpi_clk_id {
> > +   MTK_DPI_CLK_DPI_ENGINE,
> > +   MTK_DPI_CLK_DPI_PIXEL,
> > +   MTK_DPI_CLK_TVD_PLL,
> > +   MTK_DPI_CLK_COUNT,
> > +};
> > +
> > +static const char * const mtk_dpi_clk_names[MTK_DPI_CLK_COUNT] = {
> > +   [MTK_DPI_CLK_DPI_ENGINE] = "engine",
> > +   [MTK_DPI_CLK_DPI_PIXEL] = "pixel",
> > +   [MTK_DPI_CLK_TVD_PLL] = "pll",
> > +};
> > +
> >  struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > void __iomem *regs;
> > struct device *dev;
> > -   struct clk *engine_clk;
> > -   struct clk *pixel_clk;
> > -   struct clk *tvd_clk;
> > +   struct clk *clk[MTK_DPI_CLK_COUNT];
> > int irq;
> > struct drm_display_mode mode;
> > enum mtk_dpi_out_color_format color_format;
> > @@ -76,6 +87,7 @@ struct mtk_dpi {
> > enum mtk_dpi_out_channel_swap channel_swap;
> > bool power_sta;
> > u8 power_ctl;
> > +   void *data;
> >  };
> >  
> >  static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > @@ -114,6 +126,10 @@ struct mtk_dpi_yc_limit {
> > u16 c_bottom;
> >  };
> >  
> > +struct mtk_dpi_conf {
> > +   int (*clk_config)(struct mtk_dpi *dpi, struct drm_display_mode *mode);
> > +};
> > +
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 
> > mask)
> >  {
> > u32 tmp = readl(dpi->regs + offset) & ~mask;
> > @@ -377,8 +393,8 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return;
> >  
> > mtk_dpi_disable(dpi);
> > -   clk_disable_unprepare(dpi->pixel_clk);
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > dpi->power_sta = false;
> >  }
> >  
> > @@ -395,13 +411,13 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > if (dpi->power_sta)
> > return 0;
> >  
> > -   ret = clk_prepare_enable(dpi->engine_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable engine clock: %d\n", ret);
> > goto err_eng;
> > }
> >  
> > -   ret = clk_prepare_enable(dpi->pixel_clk);
> > +   ret = clk_prepare_enable(dpi->clk[MTK_DPI_CLK_DPI_PIXEL]);
> > if (ret) {
> > dev_err(dpi->dev, "Failed to enable pixel clock: %d\n", ret);
> > goto err_pixel;
> > @@ -412,7 +428,7 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
> > mtk_dpi_power_ctl pctl)
> > return 0;
> >  
> >  err_pixel:
> > -   clk_disable_unprepare(dpi->engine_clk);
> > +   clk_disable_unprepare(dpi->clk[MTK_DPI_CLK_DPI_ENGINE]);
> >  err_eng:
> > dpi->power_ctl &= ~pctl;
> > return ret;
> > @@ -428,34 +444,18 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi 
> > *dpi,
> > struct mtk_dpi_sync_param vsync_leven = { 0 };
> > struct mtk_dpi_sync_param vsync_rodd = { 0 };
> > struct mtk_dpi_sync_param vsync_reven = { 0 };
> > -   unsigned long pix_rate;
> > -   unsigned long pll_rate;
> > -   unsigned int factor;
> > +   struct mtk_dpi_conf *conf;
> > +   int ret;
> >  
> > if (!dpi) {
> > dev_err(dpi->dev, "invalid argument\n");
> > return -EINVAL;
> > }
> >  
> > -   pix_rate = 1000UL * mode->clock;
> > -   if (mode->clock <= 74000)
> > -   factor = 8 * 3;
> > -   else
> > -   factor = 4 * 3;
> > -   pll_rate = pix_rate * factor;
> > -
> > -   dev_dbg(dpi->dev, "Want PLL 

[PATCH v2 2/3] drm/mediatek: enhance the HDMI driving current

2016-07-28 Thread Bibby Hsieh
Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:25 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > In order to improve 4K resolution performance,
> > we have to enhance the HDMI driving currend
>^
> Typo, s/currend/current/
> 
> Besides that, this patch looks good to me.
> 
Ok, I will fix that, thanks.
> regards
> Philipp
> 
> > when clock rate is greater than 165MHz.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |   42 
> > +---
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index 8a24754..51cb9cf 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -265,6 +265,9 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > unsigned int pre_div;
> > unsigned int div;
> > +   unsigned int pre_ibias;
> > +   unsigned int hdmi_ibias;
> > +   unsigned int imp_en;
> >  
> > dev_dbg(hdmi_phy->dev, "%s: %lu Hz, parent: %lu Hz\n", __func__,
> > rate, parent_rate);
> > @@ -298,18 +301,31 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   (0x1 << PLL_BR_SHIFT),
> >   RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
> >   RG_HDMITX_PLL_BR);
> > -   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
> > +   if (rate < 16500) {
> > +   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
> > +   RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x3;
> > +   imp_en = 0x0;
> > +   hdmi_ibias = hdmi_phy->ibias;
> > +   } else {
> > +   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
> > + RG_HDMITX_PRD_IMP_EN);
> > +   pre_ibias = 0x6;
> > +   imp_en = 0xf;
> > +   hdmi_ibias = hdmi_phy->ibias_up;
> > +   }
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
> > - (0x3 << PRD_IBIAS_CLK_SHIFT) |
> > - (0x3 << PRD_IBIAS_D2_SHIFT) |
> > - (0x3 << PRD_IBIAS_D1_SHIFT) |
> > - (0x3 << PRD_IBIAS_D0_SHIFT),
> > + (pre_ibias << PRD_IBIAS_CLK_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D2_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D1_SHIFT) |
> > + (pre_ibias << PRD_IBIAS_D0_SHIFT),
> >   RG_HDMITX_PRD_IBIAS_CLK |
> >   RG_HDMITX_PRD_IBIAS_D2 |
> >   RG_HDMITX_PRD_IBIAS_D1 |
> >   RG_HDMITX_PRD_IBIAS_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
> > - (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
> > + (imp_en << DRV_IMP_EN_SHIFT),
> > + RG_HDMITX_DRV_IMP_EN);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
> >   (hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
> >   (hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
> > @@ -318,12 +334,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> >   RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
> >   RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
> > mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
> > - (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
> > - (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
> > - RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
> > - RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
> > + (hdmi_ibias << DRV_IBIAS_CLK_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D2_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D1_SHIFT) |
> > + (hdmi_ibias << DRV_IBIAS_D0_SHIFT),
> > + RG_HDMITX_DRV_IBIAS_CLK |
> > + RG_HDMITX_DRV_IBIAS_D2 |
> > + RG_HDMITX_DRV_IBIAS_D1 |
> > + RG_HDMITX_DRV_IBIAS_D0);
> > return 0;
> >  }
> >  
> 
> 

-- 
Bibby



[PATCH v2 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

2016-07-28 Thread Bibby Hsieh
Hi, Philipp,

Thanks for your review.

On Wed, 2016-07-27 at 11:27 +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh:
> > From: Junzhi Zhao 
> > 
> > The mtk_hdmi_send_infoframe have to
> > be run after PLL and PIXEL clock of HDMI enable.
> > Make sure that HDMI inforframes can be sent
> > successfully.
> > 
> > Signed-off-by: Junzhi Zhao 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c |   19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index ba812ef..d8609f5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1133,12 +1133,6 @@ static int mtk_hdmi_output_set_display_mode(struct 
> > mtk_hdmi *hdmi,
> > phy_power_on(hdmi->phy);
> > mtk_hdmi_aud_output_config(hdmi, mode);
> >  
> > -   mtk_hdmi_setup_audio_infoframe(hdmi);
> > -   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > -   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > -   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > -   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > -
> > mtk_hdmi_hw_vid_black(hdmi, false);
> > mtk_hdmi_hw_aud_unmute(hdmi);
> > mtk_hdmi_hw_send_av_unmute(hdmi);
> > @@ -1401,14 +1395,25 @@ static void mtk_hdmi_bridge_pre_enable(struct 
> > drm_bridge *bridge)
> > hdmi->powered = true;
> >  }
> >  
> > +static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
> > +   struct drm_display_mode *mode)
> > +{
> > +   mtk_hdmi_setup_audio_infoframe(hdmi);
> > +   mtk_hdmi_setup_avi_infoframe(hdmi, mode);
> > +   mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
> > +   if (mode->flags & DRM_MODE_FLAG_3D_MASK)
> > +   mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
> > +}
> > +
> >  static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
> >  {
> > struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
> >  
> > +   phy_power_on(hdmi->phy);
> > mtk_hdmi_output_set_display_mode(hdmi, >mode);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
> > clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
> > -   phy_power_on(hdmi->phy);
> 
> This change is not described in the patch description. Why is the phy
> power on moved after the pixel clock enable?
> 
Ok, will rollback it.
> > +   mtk_hdmi_send_infoframe(hdmi, >mode);
> >  
> > hdmi->enabled = true;
> >  }
> 
> regards
> Philipp
> 

-- 
Bibby



[PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

2016-07-28 Thread Yakir Yang
Sean,

Oops, sorry about miss your suggest :(

On 07/22/2016 11:03 PM, Sean Paul wrote:
> On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang  wrote:
>> Sean,
>>
>> Thanks for your fast respond :-)
>>
>> But this patch is not the latest one, I have upgraded this to "v1.1" version
>> to fix the eDP can't be disabled problem:
>>  [PATCH v1.1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP
>> need to disable
>>  Changes in v1.1: - unprepare the panel at the end of
>> bridge->disable() function
>>
>> In spite of this, I would take your comments with my "v1.1" patch.
>>
>> On 07/21/2016 10:28 PM, Sean Paul wrote:
>>
>> On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:
>>
>> Some panels (like Sharp LQ123P1JX31) need to be turn off when eDP
>> controller stop to send valid video signal, otherwhise panel would
>> go burn in, and keep flicker and flicker.
>>
>> So it's better to turn off the panel when eDP need to disable, and
>> we need to turn on the panel in connector->detect() callback, so
>> that driver would detect panel status rightly.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
>>   1 file changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 32715da..ea059b3 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -961,6 +961,14 @@ analogix_dp_detect(struct drm_connector *connector,
>> bool force)
>>   {
>>  struct analogix_dp_device *dp = to_dp(connector);
>>
>> +   /*
>> +* Panle would prepare for several times here, but don't worry it
>>
>> s/Panle/Panel/
>>
>>
>> Done
>>
>> +* would only enable the hardware at the first prepare time.
>>
>> Errr, this shouldn't go in detect. How about putting this in
>> bridge_enable instead?
>>
>>
>> Nope, if we put this in bridge_enable, then eDP would never be enabled.
>> Here're the calling flow.
>>
>> --> analogix_dp_probe
>>--> analogix_dp_bind  # we still haven't prepared the panel here, that
>> means panel have been powered up
>>  --> analogix_dp_detect  # Oops, losing panel valid hotplug signal, cause
>> panel have been powered up
>>  --> ** Keep detecting **
>
> Yeah, after playing around with the patch yesterday I discovered this
> for myself. I still don't think detect() should be changing hardware
> state. Perhaps you could add a matching unprepare() after you attempt
> to detect the panel?

Hmm, I don't understand the meaning of "add a matching unprepare()".

I didn't see there is an unprepare() callback in drm_crtc_helper.h, would
you like to share some simple code :-D

Thanks,
- Yakir

> Sean
>
>> +*/
>> +   if (dp->plat_data->panel)
>> +   if (drm_panel_prepare(dp->plat_data->panel))
>>
>> Personally, I don't like doing work in a conditional since you're
>> throwing the return code away. Could you break this out into:
>>
>> ret = drm_panel_prepare(dp->plat_data->panel);
>> if (ret)
>>DRM_ERROR("failed to setup the panel ret=%d\n", ret);
>>
>>
>> Okay
>>
>>
>> +   DRM_ERROR("failed to setup the panel\n");
>> +
>>  if (analogix_dp_detect_hpd(dp))
>>  return connector_status_disconnected;
>>
>> @@ -1063,7 +1071,8 @@ static void analogix_dp_bridge_disable(struct
>> drm_bridge *bridge)
>>  return;
>>
>>  if (dp->plat_data->panel) {
>> -   if (drm_panel_disable(dp->plat_data->panel)) {
>> +   if (drm_panel_disable(dp->plat_data->panel) ||
>> +   drm_panel_unprepare(dp->plat_data->panel)) {
>>
>> Same comment here, please break this out into separate statements for
>> better readability/logging.
>>
>>
>> Okay,
>>
>>
>> Thanks,
>> - Yakir
>>
>>
>>  DRM_ERROR("failed to disable the panel\n");
>>  return;
>>  }
>> @@ -1333,13 +1342,6 @@ int analogix_dp_bind(struct device *dev, struct
>> drm_device *drm_dev,
>>
>>  phy_power_on(dp->phy);
>>
>> -   if (dp->plat_data->panel) {
>> -   if (drm_panel_prepare(dp->plat_data->panel)) {
>> -   DRM_ERROR("failed to setup the panel\n");
>> -   return -EBUSY;
>> -   }
>> -   }
>> -
>>  analogix_dp_init_dp(dp);
>>
>>  ret = devm_request_threaded_irq(>dev, dp->irq,
>> --
>> 1.9.1
>>
>>
>>
>>
>>
>
>




[PATCH 1/3] drm: introduce share plane

2016-07-28 Thread Mark yao
Any ideas for the share planes?

This function is important for our series of vop full design.
 The series of vop is:
 IP versionchipname
 3.1   rk3288
 3.2   rk3368
 3.4   rk3366
 3.5   rk3399 big
 3.6   rk3399 lit
 3.7   rk322x

example on rk3288:  if not support share plane, each vop only support 
four planes, but if support this function, each vop can support ten planes.

On 2016年07月26日 17:51, Mark yao wrote:
> On 2016年07月26日 16:26, Daniel Vetter wrote:
>> On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
>>> >What is share plane:
>>> >Plane hardware only be used when the display scanout run into plane 
>>> active
>>> >scanout, that means we can reuse the plane hardware resources on plane
>>> >non-active scanout.
>>> >
>>> >  --
>>> > |  scanout   |
>>> > | -- |
>>> > | | parent plane   | |
>>> > | | active scanout | |
>>> > | ||   - |
>>> > | --   | share plane 1 | |
>>> > |  -   |active scanout | |
>>> > |  | share plane 0 |   |   | |
>>> > |  |active scanout |   - |
>>> > |  |   | |
>>> > |  - |
>>> > --
>>> >One plane hardware can be reuse for multi-planes, we assume the first
>>> >plane is parent plane, other planes share the resource with first one.
>>> > parent plane
>>> > |---share plane 0
>>> > |---share plane 1
>>> > ...
>>> >
>>> >Because resource share, There are some limit on share plane: one group
>>> >of share planes need use same zpos, can not overlap, etc.
>>> >
>>> >We assume share plane is a universal plane with some limit flags.
>>> >people who use the share plane need know the limit, should call the 
>>> ioctl
>>> >DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
>>> >
>>> >A group of share planes would has same shard id, so userspace can
>>> >group them, judge share plane's limit.
>>> >
>>> >Signed-off-by: Mark Yao
>> This seems extremely hw specific, why exactly do we need to add a new
>> relationship on planes? What does this buy on_other_  drivers?
> Yes, now it's plane hardware specific, maybe others have same design, 
> because this design
> would save hardware resource to support multi-planes.
>
>> Imo this should be solved by virtualizing planes in the driver. Start 
>> out
>> by assigning planes, and if you can reuse one for sharing then do that,
>> otherwise allocate a new one. If there's not enough real planes, fail 
>> the
>> atomic_check.
> I think that is too complex, trying with atomic_check I think it's not 
> a good idea, userspace try planes every commit would be a heavy work.
>
> Userspace need  know all planes relationship, group them, some display 
> windows can put together, some can't,
> too many permutation and combination, I think can't just commit with try.
>
> example:
> userspace:
> windows 1: pos(0, 0)  size(1024, 100)
> windows 2: pos(0, 50) size(400, 500)
> windows 3: pos(0, 200) size(800, 300)
>
> drm plane resources:
> plane 0 and plane 1 is a group of share planes
> plane 2 is common plane.
>
> if userspace know the relationship, then they can assign windows 1 and 
> window 3 to plane0 and plane 1. that would be success.
> but if they don't know, assign window 1/2 to plane 0/1, failed, assign 
> window 2/3 to plane 0/1, failed. mostly would get failed.
>
>>
>> This seems way to hw specific to be useful as a generic concept.
>
> We want to change the drm_mode_getplane_res behavior, if userspace 
> call DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware 
> limit,
> then we return full planes support to userspace, if don't, just make a 
> group of share planes as one plane.
> this work is on generic place.
>
>> -Daniel
>>
>>
>


-- 
ï¼­ark Yao




[PATCH v4 4/4] drm/mediatek: set mt8173 dithering function

2016-07-28 Thread Bibby Hsieh
Some panels only accept bpc (bit per color) 6-bit.
But, the default bpc in mt8173 display data path is 8-bit.
If we didn't enable dithering function to convert bpc,
display cannot show the smooth grayscale image.

In mt8173, the dithering function in OD (OverDrive) and
GAMMA module, we have to config them with
connector->display_mode.bpc when CRTC initial.

1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   21 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   72 ++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |8 +--
 6 files changed, 89 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8f62671f..019b7ca 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
 }

 static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
-  unsigned int h, unsigned int vrefresh)
+  unsigned int h, unsigned int vrefresh,
+  unsigned int bpc)
 {
if (w != 0 && h != 0)
writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 5fb80cb..0df05f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
 }

 static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
-   unsigned int height, unsigned int vrefresh)
+   unsigned int height, unsigned int vrefresh,
+   unsigned int bpc)
 {
unsigned int threshold;
unsigned int reg;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index cbb460a5..e51176e8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -222,7 +222,9 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc 
*mtk_crtc)
 static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 {
struct drm_crtc *crtc = _crtc->base;
-   unsigned int width, height, vrefresh;
+   struct drm_connector *connector;
+   struct drm_encoder *encoder;
+   unsigned int width, height, vrefresh, bpc = MTK_MAX_BPC;
int ret;
int i;

@@ -234,6 +236,19 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
height = crtc->state->adjusted_mode.vdisplay;
vrefresh = crtc->state->adjusted_mode.vrefresh;

+   drm_for_each_encoder(encoder, crtc->dev) {
+   if (encoder->crtc != crtc)
+   continue;
+
+   drm_for_each_connector(connector, crtc->dev) {
+   if (connector->encoder != encoder)
+   continue;
+   if (connector->display_info.bpc != 0 &&
+   bpc > connector->display_info.bpc)
+   bpc = connector->display_info.bpc;
+   }
+   }
+
ret = pm_runtime_get_sync(crtc->dev->dev);
if (ret < 0) {
DRM_ERROR("Failed to enable power domain: %d\n", ret);
@@ -266,7 +281,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];

-   mtk_ddp_comp_config(comp, width, height, vrefresh);
+   mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
mtk_ddp_comp_start(comp);
}

@@ -468,7 +483,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct 
mtk_ddp_comp *ovl)
if (state->pending_config) {
mtk_ddp_comp_config(ovl, state->pending_width,
state->pending_height,
-   state->pending_vrefresh);
+   state->pending_vrefresh, 0);

state->pending_config = false;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index d332564..33f6ab6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ 

[PATCH v4 3/4] drm/mediatek: Add gamma correction.

2016-07-28 Thread Bibby Hsieh
Add gamma set function to correct brightness values.
It applies arbitrary mapping curve to compensate the
incorrect transfer function of the panel.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   31 +++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   10 +
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..cbb460a5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
}
if (pending_planes)
mtk_crtc->pending_planes = true;
+   if (crtc->state->color_mgmt_changed)
+   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
+   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
 }

 static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
.reset  = mtk_drm_crtc_reset,
.atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
.atomic_destroy_state   = mtk_drm_crtc_destroy_state,
+   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
 };

 static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
_crtc->planes[1].base, pipe);
if (ret < 0)
goto unprepare;
-
+   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
+   drm_helper_crtc_enable_color_mgmt(_crtc->base, MTK_LUT_SIZE,
+ MTK_LUT_SIZE);
priv->crtc[pipe] = _crtc->base;
priv->num_pipes++;

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 81e5566..d332564 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,6 +19,7 @@
 #include "mtk_drm_plane.h"

 #define OVL_LAYER_NR   4
+#define MTK_LUT_SIZE   512

 int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
 void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index ba895c8..42cd587 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -24,6 +24,7 @@
 #include "mtk_drm_drv.h"
 #include "mtk_drm_plane.h"
 #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_crtc.h"

 #define DISP_OD_EN 0x
 #define DISP_OD_INTEN  0x0008
@@ -42,7 +43,11 @@
 #define DISP_AAL_SIZE  0x0030

 #define DISP_GAMMA_EN  0x
+#define DISP_GAMMA_CFG 0x0020
 #define DISP_GAMMA_SIZE0x0030
+#define DISP_GAMMA_LUT 0x0700
+
+#define LUT_10BIT_MASK 0x03ff

 #defineOD_RELAY_MODE   BIT(0)

@@ -54,6 +59,7 @@
 #define AAL_EN BIT(0)

 #define GAMMA_EN   BIT(0)
+#define GAMMA_LUT_EN   BIT(1)

 static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
 unsigned int h, unsigned int vrefresh)
@@ -118,13 +124,38 @@ static void mtk_gamma_stop(struct mtk_ddp_comp *comp)
writel_relaxed(0x0, comp->regs  + DISP_GAMMA_EN);
 }

+static void mtk_gamma_set(struct mtk_ddp_comp *comp,
+ struct drm_crtc_state *state)
+{
+   unsigned int i, reg;
+   struct drm_color_lut *lut;
+   void __iomem *lut_base;
+   u32 word;
+
+   if (state->gamma_lut) {
+   reg = readl(comp->regs + DISP_GAMMA_CFG);
+   reg = reg | GAMMA_LUT_EN;
+   writel(reg, comp->regs + DISP_GAMMA_CFG);
+   lut_base = comp->regs + DISP_GAMMA_LUT;
+   lut = (struct drm_color_lut *)state->gamma_lut->data;
+   for (i = 0; i < MTK_LUT_SIZE; i++) {
+   word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
+   (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
+   ((lut[i].blue >> 6) & LUT_10BIT_MASK);
+   writel(word, (lut_base + i * 4));
+   }
+   }
+}
+
 static const struct mtk_ddp_comp_funcs ddp_aal = {
+   .gamma_set = mtk_gamma_set,
.config = mtk_aal_config,
.start = mtk_aal_start,
.stop = mtk_aal_stop,
 };

 static const struct mtk_ddp_comp_funcs ddp_gamma = {
+   .gamma_set = mtk_gamma_set,
.config = mtk_gamma_config,
.start = 

[PATCH v4 2/4] drm/mediatek: Add GAMMA engine basic function

2016-07-28 Thread Bibby Hsieh
In order to correct brightness values, we have
to support gamma funciton on MT8173. In MT8173,
we have two engines for supporting gamma function:
AAL and GAMMA. This patch add some GAMMA engine
basic function, include config, start and stop
function.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   29 ++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 5fc9671..ba895c8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -41,6 +41,9 @@
 #define DISP_AAL_EN0x
 #define DISP_AAL_SIZE  0x0030

+#define DISP_GAMMA_EN  0x
+#define DISP_GAMMA_SIZE0x0030
+
 #defineOD_RELAY_MODE   BIT(0)

 #defineUFO_BYPASS  BIT(2)
@@ -50,6 +53,8 @@

 #define AAL_EN BIT(0)

+#define GAMMA_EN   BIT(0)
+
 static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
 unsigned int h, unsigned int vrefresh)
 {
@@ -97,12 +102,34 @@ static void mtk_aal_stop(struct mtk_ddp_comp *comp)
writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
 }

+static void mtk_gamma_config(struct mtk_ddp_comp *comp, unsigned int w,
+unsigned int h, unsigned int vrefresh)
+{
+   writel(h << 16 | w, comp->regs + DISP_GAMMA_SIZE);
+}
+
+static void mtk_gamma_start(struct mtk_ddp_comp *comp)
+{
+   writel(GAMMA_EN, comp->regs  + DISP_GAMMA_EN);
+}
+
+static void mtk_gamma_stop(struct mtk_ddp_comp *comp)
+{
+   writel_relaxed(0x0, comp->regs  + DISP_GAMMA_EN);
+}
+
 static const struct mtk_ddp_comp_funcs ddp_aal = {
.config = mtk_aal_config,
.start = mtk_aal_start,
.stop = mtk_aal_stop,
 };

+static const struct mtk_ddp_comp_funcs ddp_gamma = {
+   .config = mtk_gamma_config,
+   .start = mtk_gamma_start,
+   .stop = mtk_gamma_stop,
+};
+
 static const struct mtk_ddp_comp_funcs ddp_color = {
.config = mtk_color_config,
.start = mtk_color_start,
@@ -145,7 +172,7 @@ static const struct mtk_ddp_comp_match 
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
[DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
[DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
-   [DDP_COMPONENT_GAMMA]   = { MTK_DISP_GAMMA, 0, NULL },
+   [DDP_COMPONENT_GAMMA]   = { MTK_DISP_GAMMA, 0, _gamma },
[DDP_COMPONENT_OD]  = { MTK_DISP_OD,0, _od },
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL,   0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL,   1, NULL },
-- 
1.7.9.5



[PATCH v4 1/4] drm/mediatek: Add AAL engine basic function

2016-07-28 Thread Bibby Hsieh
In order to correct brightness values, we have
to support gamma funciton on MT8173. In MT8173,
we have two engines for supporting gamma function:
AAL and GAMMA. This patch add some AAL engine
basic function, include config, start and stop
function.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   29 ++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3970fcf..5fc9671 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -38,6 +38,9 @@
 #define DISP_COLOR_WIDTH   0x0c50
 #define DISP_COLOR_HEIGHT  0x0c54

+#define DISP_AAL_EN0x
+#define DISP_AAL_SIZE  0x0030
+
 #defineOD_RELAY_MODE   BIT(0)

 #defineUFO_BYPASS  BIT(2)
@@ -45,6 +48,8 @@
 #defineCOLOR_BYPASS_ALLBIT(7)
 #defineCOLOR_SEQ_SEL   BIT(13)

+#define AAL_EN BIT(0)
+
 static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
 unsigned int h, unsigned int vrefresh)
 {
@@ -76,6 +81,28 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
 }

+static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
+  unsigned int h, unsigned int vrefresh)
+{
+   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
+}
+
+static void mtk_aal_start(struct mtk_ddp_comp *comp)
+{
+   writel(AAL_EN, comp->regs + DISP_AAL_EN);
+}
+
+static void mtk_aal_stop(struct mtk_ddp_comp *comp)
+{
+   writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
+}
+
+static const struct mtk_ddp_comp_funcs ddp_aal = {
+   .config = mtk_aal_config,
+   .start = mtk_aal_start,
+   .stop = mtk_aal_stop,
+};
+
 static const struct mtk_ddp_comp_funcs ddp_color = {
.config = mtk_color_config,
.start = mtk_color_start,
@@ -112,7 +139,7 @@ struct mtk_ddp_comp_match {
 };

 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = 
{
-   [DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, NULL },
+   [DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, _aal },
[DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
[DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
-- 
1.7.9.5



[PATCH v4 0/4] drm/mediatek: MT8173 gamma & dither support

2016-07-28 Thread Bibby Hsieh
This is MT8173 gamma & dither support PATCH v4, based on 4.7-rc1.

Changes since v3:
 -Split the GAMMA patch into 3 patches.
   --AAL engine basic function
   --GAMMA engine basic function
   --GAMMA correction config function
 -Align the all definition to 4 digits.
 -Remove HW constrain check from calculate bpc.
 -Use symbol to replace magic number.
 -Add a function "mtk_dither_set".

Changes since v2:
 -Modify defines to match the register field names in the MT8173 datasheet
 -Made dithering function support hardware mirroring well on two monitor.

Changes since v1:
 -According to the suggestion from Daniel,
  we used the new atomic color management.
 -Applied gamma function at GAMMA engine (path 2).
 -Made dithering function support hardware mirroring well.
 -Removed the bpc variable from mtk_drm_crtc struct.

Bibby Hsieh (4):
  drm/mediatek: Add AAL engine basic function
  drm/mediatek: Add GAMMA engine basic function
  drm/mediatek: Add gamma correction.
  drm/mediatek: set mt8173 dithering function

 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   29 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |3 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  151 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   18 +++-
 6 files changed, 189 insertions(+), 18 deletions(-)

-- 
1.7.9.5



[PATCH 2/2] drm/amdgpu: enable UVD context buffer for older HW

2016-07-28 Thread Leo Liu
From: Christian König 

Supported starting on certain FW versions.

Signed-off-by: Christian König 
Reviewed-by: Leo Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 28 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d406ec7..9c07e38 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1688,6 +1688,7 @@ struct amdgpu_uvd {
struct amdgpu_ring  ring;
struct amdgpu_irq_src   irq;
booladdress_64_bit;
+   booluse_ctx_buf;
struct amd_sched_entity entity;
uint32_tsrbm_soft_reset;
 };
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 28c1b62..c22b64e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -41,8 +41,15 @@

 /* 1 second timeout */
 #define UVD_IDLE_TIMEOUT   msecs_to_jiffies(1000)
+
+/* Firmware versions for VI */
+#define FW_1_65_10 ((1 << 24) | (65 << 16) | (10 << 8))
+#define FW_1_87_11 ((1 << 24) | (87 << 16) | (11 << 8))
+#define FW_1_87_12 ((1 << 24) | (87 << 16) | (12 << 8))
+#define FW_1_37_15 ((1 << 24) | (37 << 16) | (15 << 8))
+
 /* Polaris10/11 firmware version */
-#define FW_1_66_16 ((1 << 24) | (66 << 16) | (16 << 8))
+#define FW_1_66_16 ((1 << 24) | (66 << 16) | (16 << 8))

 /* Firmware Names */
 #ifdef CONFIG_DRM_AMDGPU_CIK
@@ -220,6 +227,23 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
if (!amdgpu_ip_block_version_cmp(adev, AMD_IP_BLOCK_TYPE_UVD, 5, 0))
adev->uvd.address_64_bit = true;

+   switch (adev->asic_type) {
+   case CHIP_TONGA:
+   adev->uvd.use_ctx_buf = adev->uvd.fw_version >= FW_1_65_10;
+   break;
+   case CHIP_CARRIZO:
+   adev->uvd.use_ctx_buf = adev->uvd.fw_version >= FW_1_87_11;
+   break;
+   case CHIP_FIJI:
+   adev->uvd.use_ctx_buf = adev->uvd.fw_version >= FW_1_87_12;
+   break;
+   case CHIP_STONEY:
+   adev->uvd.use_ctx_buf = adev->uvd.fw_version >= FW_1_37_15;
+   break;
+   default:
+   adev->uvd.use_ctx_buf = adev->asic_type >= CHIP_POLARIS10;
+   }
+
return 0;
 }

@@ -529,7 +553,7 @@ static int amdgpu_uvd_cs_msg_decode(struct amdgpu_device 
*adev, uint32_t *msg,
/* reference picture buffer */
min_dpb_size = image_size * num_dpb_buffer;

-   if (adev->asic_type < CHIP_POLARIS10){
+   if (!adev->uvd.use_ctx_buf){
/* macroblock context buffer */
min_dpb_size +=
width_in_mb * height_in_mb * num_dpb_buffer * 
192;
-- 
2.7.4



[PATCH 1/2] drm/amdgpu: fix default UVD context size

2016-07-28 Thread Leo Liu
From: Christian König 

Context buffers should be denied by default, not allowed.

Signed-off-by: Christian König 
Reviewed-by: Leo Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index b39238a..28c1b62 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -410,7 +410,7 @@ static int amdgpu_uvd_cs_msg_decode(struct amdgpu_device 
*adev, uint32_t *msg,
unsigned fs_in_mb = width_in_mb * height_in_mb;

unsigned image_size, tmp, min_dpb_size, num_dpb_buffer;
-   unsigned min_ctx_size = 0;
+   unsigned min_ctx_size = ~0;

image_size = width * height;
image_size += image_size / 2;
-- 
2.7.4



[PATCH v7 4/4] drm: rcar: use generic code for managing zpos plane property

2016-07-28 Thread Benjamin Gaignard
version 6:
rebased patch on top rcar-du changes for zpos

version 4:
fix null pointer issue while setting zpos in plane reset function

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 --
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 14 +-
 6 files changed, 8 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index e39fcef..7316fc7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 6bb032d..f03eb55 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca..a74f8ed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 6ac717f..83ebd16 

[PATCH v7 3/4] drm/exynos: use generic code for managing zpos plane property

2016-07-28 Thread Benjamin Gaignard
From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b39d521..7f1a49d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
void *mapping;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 77f12c0..7f32419 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private *dev_priv = 

[PATCH v7 2/4] drm: sti: use generic zpos for plane

2016-07-28 Thread Benjamin Gaignard
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_cursor.c |  4 +--
 drivers/gpu/drm/sti/sti_gdp.c|  4 +--
 drivers/gpu/drm/sti/sti_hqvdp.c  |  4 +--
 drivers/gpu/drm/sti/sti_mixer.c  |  9 ++---
 drivers/gpu/drm/sti/sti_plane.c  | 78 +++-
 drivers/gpu/drm/sti/sti_plane.h  |  7 +---
 6 files changed, 38 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index a263bbb..3b53f7f 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -349,8 +349,8 @@ struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_cursor_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_cursor_late_register,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index bf63086..b8d942c 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -886,8 +886,8 @@ struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_gdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_gdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index b032322..b5ee783 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1254,8 +1254,8 @@ struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_hqvdp_destroy,
-   .set_property = sti_plane_set_property,
-   .reset = drm_atomic_helper_plane_reset,
+   .set_property = drm_atomic_helper_plane_set_property,
+   .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_hqvdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 1885c7a..7d9aea8 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -239,13 +239,10 @@ static void sti_mixer_set_background_area(struct 
sti_mixer *mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;

-   if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
-   return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -278,8 +275,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer, 
struct sti_plane *plane)
break;
}

-   mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
-   plane_id = plane_id << (3 * (depth - 1));
+   mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+   plane_id = plane_id << (3 * depth);

DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
 sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 0cf3335..ca4b371 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -96,59 +87,46 @@ 

[PATCH v7 1/4] drm: add generic zpos property

2016-07-28 Thread Benjamin Gaignard
From: Marek Szyprowski 

version 7:
remove useless EXPORT_SYMBOL()
better z-order wording in Documentation

version 6:
- add zpos in gpu documentation file
- merge Ville patch about zpos initial value and API improvement.
  I have split Ville patch between zpos core and drivers

version 5:
- remove zpos range check and comeback to 0 to N-1
  normalization algorithm

version 4:
- make sure that normalized zpos value is stay
  in the defined property range and warn user if not

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Ville Syrjälä 
Acked-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 Documentation/gpu/kms-properties.csv |   1 +
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c |   4 +
 drivers/gpu/drm/drm_atomic_helper.c  |   7 +
 drivers/gpu/drm/drm_blend.c  | 239 +++
 drivers/gpu/drm/drm_crtc_internal.h  |   4 +
 include/drm/drm_crtc.h   |  30 +
 7 files changed, 286 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index b6fcaf6..4c5ce3e 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ DRM,Generic,“rotation”,BITMASK,"{ 0, ""rotate-0"" }, { 1, 
""rotate-90"" }, {
 ,,“CRTC_H”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination) 
height (atomic)
 ,,“FB_ID”,OBJECT,DRM_MODE_OBJECT_FB,Plane,Scanout framebuffer (atomic)
 ,,“CRTC_ID”,OBJECT,DRM_MODE_OBJECT_CRTC,Plane,CRTC that plane is attached 
to (atomic)
+,,“zpos”,RANGE,"Min=0, Max=UINT_MAX","Plane,Z-order of the plane.Planes 
with higher Z-order values are displayed on top, planes with identical Z-order 
values are display in an undefined order"
 ,DVI-I,“subconnector”,ENUM,"{ “Unknown”, “DVI-D”, “DVI-A” 
}",Connector,TBD
 ,,“select subconnector”,ENUM,"{ “Automatic”, “DVI-D”, “DVI-A” 
}",Connector,TBD
 ,TV,“subconnector”,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", 
""Component"", ""SCART"" }",Connector,TBD
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f..7fbcf3f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9359be4..8ddd8bc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -712,6 +712,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == plane->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -768,6 +770,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == plane->zpos_property) {
+   *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff 

[PATCH v7 0/4] Generic zpos property

2016-07-28 Thread Benjamin Gaignard
version 7:
remove useless EXPORT_SYMBOL()
better z-order wording in Documentation
rebased code on drm-next + merge of git://linuxtv.org/media_tree.git vsp1 
branch.
vsp1 branch might be merged into 4.8-rc1 so conflits between rcar-du and zpos 
patches should be avoid in this version 7.

version 6:
add zpos in Documentation/gpu/kms-properties.csv
merge Ville's patch (splitted between all the commits)
it simplify the API and fix bug. Thanks

version 5:
rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't
exist anymore.
rework sti patch because some plane functions have changed since v4

version 4:
make sure that normalized zpos value is stay in the defined property 
range and warn user if not.
Fix NULL pointer bug in rcar-du while setting zpos value.
No changes in the other drivers.

version 3:
use kmalloc_array instead of kmalloc.
Correct normalize_zpos computation (comeback to Mareck original code)

version 2:
add a zpos property into drm_plane structure to simplify code.
This allow to get/set zpos value in core and not in drivers code.
Fix various remarks.

version 1:
refactor Marek's patches to have per plane zpos property instead of only
one in core.

Benjamin Gaignard (2):
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 Documentation/gpu/kms-properties.csv  |   1 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   4 +
 drivers/gpu/drm/drm_atomic_helper.c   |   7 +
 drivers/gpu/drm/drm_blend.c   | 239 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  14 +-
 drivers/gpu/drm/sti/sti_cursor.c  |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c |   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   |   4 +-
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  78 --
 drivers/gpu/drm/sti/sti_plane.h   |   7 +-
 include/drm/drm_crtc.h|  30 
 22 files changed, 345 insertions(+), 156 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

-- 
1.9.1



[PATCH v4 4/8] drm/mediatek: add support for Mediatek SoC MT2701

2016-07-28 Thread CK Hu
Hi, YT:

On Wed, 2016-07-27 at 12:03 +0200, Philipp Zabel wrote:
> Am Dienstag, den 26.07.2016, 18:42 +0800 schrieb YT Shen:
> > Hi CK,
> > 
> > On Wed, 2016-07-20 at 14:53 +0800, CK Hu wrote:
> > > Hi, YT:
> > > 
> > > Some comments inline.
> > > 
> > > On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> > > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > > There is only one OVL engine in MT2701.
> > > > 
> > > > Signed-off-by: YT Shen 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 
> > > >  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   41 
> > > > +++
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 +
> > > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
> > > >  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   31 
> > > >  6 files changed, 92 insertions(+)
> > > > 
> > > 
> > > [snip...]
> > > 
> > > >  
> > > >  static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > > > +   { .compatible = "mediatek,mt2701-disp-ovl",   .data = (void 
> > > > *)MTK_DISP_OVL },
> > > > { .compatible = "mediatek,mt8173-disp-ovl",   .data = (void 
> > > > *)MTK_DISP_OVL },
> > > > +   { .compatible = "mediatek,mt2701-disp-rdma",  .data = (void 
> > > > *)MTK_DISP_RDMA },
> > > > { .compatible = "mediatek,mt8173-disp-rdma",  .data = (void 
> > > > *)MTK_DISP_RDMA },
> > > > +   { .compatible = "mediatek,mt2701-disp-wdma",  .data = (void 
> > > > *)MTK_DISP_WDMA },
> > > 
> > > Is WDMA different from MT8173 to MT2701. If they are the same, you need
> > > not to add compatible of 'mediatek,mt2701-disp-wdma' because use
> > > 'mediatek,mt8173-disp-wdma' is enough.
> > Yes, the hardware has differences, so we need add new compatible
> > 'mt2701-disp-wdma'
> 
> It would be nice if you could add a short paragraph to the patch
> description about what the hardware differences are (probably just
> changed register layout in most cases).

If you don't want to add description, you may separate the modification
of OVL, RDMA, WDMA, PWM to different patch. And you send patch of OVL
and RDMA first because you have related code modification for these two.
You temporarily treat WDMA and PWM as MT8173 and it works. And one day
you need to modify code of WDMA and PWM for MT2701, then you send the
patch of WDMA and PWM and you need not to add any description because we
can find out the difference from source code.

> 
> regards
> Philipp
> 

Regards,
CK



[PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

2016-07-28 Thread Sean Paul
On Wed, Jul 27, 2016 at 11:28 PM, Yakir Yang  wrote:
> Sean,
>
> Oops, sorry about miss your suggest :(
>
>
> On 07/22/2016 11:03 PM, Sean Paul wrote:
>>
>> On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang  wrote:
>>>
>>> Sean,
>>>
>>> Thanks for your fast respond :-)
>>>
>>> But this patch is not the latest one, I have upgraded this to "v1.1"
>>> version
>>> to fix the eDP can't be disabled problem:
>>>  [PATCH v1.1 2/2] drm/bridge: analogix_dp: turn off the panel when
>>> eDP
>>> need to disable
>>>  Changes in v1.1: - unprepare the panel at the end of
>>> bridge->disable() function
>>>
>>> In spite of this, I would take your comments with my "v1.1" patch.
>>>
>>> On 07/21/2016 10:28 PM, Sean Paul wrote:
>>>
>>> On Thu, Jul 21, 2016 at 9:14 AM, Yakir Yang  wrote:
>>>
>>> Some panels (like Sharp LQ123P1JX31) need to be turn off when eDP
>>> controller stop to send valid video signal, otherwhise panel would
>>> go burn in, and keep flicker and flicker.
>>>
>>> So it's better to turn off the panel when eDP need to disable, and
>>> we need to turn on the panel in connector->detect() callback, so
>>> that driver would detect panel status rightly.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18
>>> ++
>>>   1 file changed, 10 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index 32715da..ea059b3 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -961,6 +961,14 @@ analogix_dp_detect(struct drm_connector *connector,
>>> bool force)
>>>   {
>>>  struct analogix_dp_device *dp = to_dp(connector);
>>>
>>> +   /*
>>> +* Panle would prepare for several times here, but don't worry it
>>>
>>> s/Panle/Panel/
>>>
>>>
>>> Done
>>>
>>> +* would only enable the hardware at the first prepare time.
>>>
>>> Errr, this shouldn't go in detect. How about putting this in
>>> bridge_enable instead?
>>>
>>>
>>> Nope, if we put this in bridge_enable, then eDP would never be enabled.
>>> Here're the calling flow.
>>>
>>> --> analogix_dp_probe
>>>--> analogix_dp_bind  # we still haven't prepared the panel here, that
>>> means panel have been powered up
>>>  --> analogix_dp_detect  # Oops, losing panel valid hotplug signal,
>>> cause
>>> panel have been powered up
>>>  --> ** Keep detecting **
>>
>>
>> Yeah, after playing around with the patch yesterday I discovered this
>> for myself. I still don't think detect() should be changing hardware
>> state. Perhaps you could add a matching unprepare() after you attempt
>> to detect the panel?
>
>
> Hmm, I don't understand the meaning of "add a matching unprepare()".
>
> I didn't see there is an unprepare() callback in drm_crtc_helper.h, would
> you like to share some simple code :-D
>

In other words, make sure the hardware is in the same state at the
beginning and end of detect(). You shouldn't have the panel in a
different state when you exit detect().

Sean



> Thanks,
> - Yakir
>
>
>> Sean
>>
>>> +*/
>>> +   if (dp->plat_data->panel)
>>> +   if (drm_panel_prepare(dp->plat_data->panel))
>>>
>>> Personally, I don't like doing work in a conditional since you're
>>> throwing the return code away. Could you break this out into:
>>>
>>> ret = drm_panel_prepare(dp->plat_data->panel);
>>> if (ret)
>>>DRM_ERROR("failed to setup the panel ret=%d\n", ret);
>>>
>>>
>>> Okay
>>>
>>>
>>> +   DRM_ERROR("failed to setup the panel\n");
>>> +
>>>  if (analogix_dp_detect_hpd(dp))
>>>  return connector_status_disconnected;
>>>
>>> @@ -1063,7 +1071,8 @@ static void analogix_dp_bridge_disable(struct
>>> drm_bridge *bridge)
>>>  return;
>>>
>>>  if (dp->plat_data->panel) {
>>> -   if (drm_panel_disable(dp->plat_data->panel)) {
>>> +   if (drm_panel_disable(dp->plat_data->panel) ||
>>> +   drm_panel_unprepare(dp->plat_data->panel)) {
>>>
>>> Same comment here, please break this out into separate statements for
>>> better readability/logging.
>>>
>>>
>>> Okay,
>>>
>>>
>>> Thanks,
>>> - Yakir
>>>
>>>
>>>  DRM_ERROR("failed to disable the panel\n");
>>>  return;
>>>  }
>>> @@ -1333,13 +1342,6 @@ int analogix_dp_bind(struct device *dev, struct
>>> drm_device *drm_dev,
>>>
>>>  phy_power_on(dp->phy);
>>>
>>> -   if (dp->plat_data->panel) {
>>> -   if (drm_panel_prepare(dp->plat_data->panel)) {
>>> -   DRM_ERROR("failed to setup the panel\n");
>>> -   return -EBUSY;
>>> -   }
>>> -   }
>>> -
>>>  analogix_dp_init_dp(dp);
>>>
>>>  ret = devm_request_threaded_irq(>dev, dp->irq,
>>> --
>>> 1.9.1
>>>
>>>
>>>
>>>
>>>

[Bug 96762] [radeonsi,apitrace] Firewatch: nothing rendered in scrollable (text) areas

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96762

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #10 from Nicolai Hähnle  ---
The fix has been pushed to Mesa master.

-- 
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/20160728/5d19bf11/attachment-0001.html>


[PATCH] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?

2016-07-28 Thread Sean Paul
On Thu, Jul 28, 2016 at 2:44 AM, Joonas Lahtinen
 wrote:
> On ti, 2016-07-26 at 10:49 -0400, Sean Paul wrote:
>> On Mon, Jul 25, 2016 at 3:00 AM, Joonas Lahtinen
>>  wrote:
>> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> > index 3edeaf8..57bbc61 100644
>> > --- a/include/drm/drm_crtc.h
>> > +++ b/include/drm/drm_crtc.h
>> > @@ -84,13 +84,13 @@ static inline uint64_t I642U64(int64_t val)
>> >   * DRM_REFLECT_Y reflects the image along the specified axis prior to 
>> > rotation
>> >   */
>> >  #define DRM_ROTATE_MASK 0x0f
>> > -#define DRM_ROTATE_0   0
>> > -#define DRM_ROTATE_90  1
>> > -#define DRM_ROTATE_180 2
>> > -#define DRM_ROTATE_270 3
>> > +#define DRM_ROTATE_0   BIT(0)
>> > +#define DRM_ROTATE_90  BIT(1)
>> > +#define DRM_ROTATE_180 BIT(2)
>> > +#define DRM_ROTATE_270 BIT(3)
>> >  #define DRM_REFLECT_MASK (~DRM_ROTATE_MASK)
>> It's probably a good time to give these masks a little love. Could we
>> just generate them (both ROTATE and REFLECT) from the ROTATE and
>> REFLECT values now?
>
> I was consider it too, so I think it would be an OK change. Fine with
> the patch otherwise? I can send a revised version with that changed.
>

Yeah, everything else looks good to me. Please resend.

Sean

> Regards, Joonas
>
>>
>> Sean
>>
>> >
>> > -#define DRM_REFLECT_X  4
>> > -#define DRM_REFLECT_Y  5
>> > +#define DRM_REFLECT_X  BIT(4)
>> > +#define DRM_REFLECT_Y  BIT(5)
>> >
>> >  enum drm_connector_force {
>> > DRM_FORCE_UNSPECIFIED,
>> > --
>> > 2.5.5
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation


[PATCH] drm/gma500: remove unnecessary stub for fb_ioctl()

2016-07-28 Thread Daniel Vetter
On Wed, Jul 27, 2016 at 02:24:30PM +0200, Stefan Christ wrote:
> Stub implementation of fb_ioctl can be omitted, because function
> do_fb_ioctl already returns -ENOTTY when fb_ioctl is not assigned.
> 
> Signed-off-by: Stefan Christ 

Applied to drm-misc, thanks.
-Daniel
> ---
>  drivers/gpu/drm/gma500/framebuffer.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 7440bf9..0fcdce0 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -184,12 +184,6 @@ static int psbfb_mmap(struct fb_info *info, struct 
> vm_area_struct *vma)
>   return 0;
>  }
>  
> -static int psbfb_ioctl(struct fb_info *info, unsigned int cmd,
> - unsigned long arg)
> -{
> - return -ENOTTY;
> -}
> -
>  static struct fb_ops psbfb_ops = {
>   .owner = THIS_MODULE,
>   .fb_check_var = drm_fb_helper_check_var,
> @@ -201,7 +195,6 @@ static struct fb_ops psbfb_ops = {
>   .fb_imageblit = drm_fb_helper_cfb_imageblit,
>   .fb_mmap = psbfb_mmap,
>   .fb_sync = psbfb_sync,
> - .fb_ioctl = psbfb_ioctl,
>  };
>  
>  static struct fb_ops psbfb_roll_ops = {
> @@ -215,7 +208,6 @@ static struct fb_ops psbfb_roll_ops = {
>   .fb_imageblit = drm_fb_helper_cfb_imageblit,
>   .fb_pan_display = psbfb_pan,
>   .fb_mmap = psbfb_mmap,
> - .fb_ioctl = psbfb_ioctl,
>  };
>  
>  static struct fb_ops psbfb_unaccel_ops = {
> @@ -228,7 +220,6 @@ static struct fb_ops psbfb_unaccel_ops = {
>   .fb_copyarea = drm_fb_helper_cfb_copyarea,
>   .fb_imageblit = drm_fb_helper_cfb_imageblit,
>   .fb_mmap = psbfb_mmap,
> - .fb_ioctl = psbfb_ioctl,
>  };
>  
>  /**
> -- 
> 1.9.1
> 
> ___
> 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 1/3] drm: introduce share plane

2016-07-28 Thread Daniel Vetter
On Thu, Jul 28, 2016 at 11:01:04AM +0800, Mark yao wrote:
> Any ideas for the share planes?
> 
> This function is important for our series of vop full design.
> The series of vop is:
> IP versionchipname
> 3.1   rk3288
> 3.2   rk3368
> 3.4   rk3366
> 3.5   rk3399 big
> 3.6   rk3399 lit
> 3.7   rk322x
> 
> example on rk3288:  if not support share plane, each vop only support four
> planes, but if support this function, each vop can support ten planes.

Like I said, register 10 planes in the kernel driver, figure out a good
way to actually allocate them to hw resources. We have a similar issue on
skl/bxt in the i915 driver where there's only a limited amount of
scalers, and we need to dynamically allocate them to drm_plane. Here you
have fancy amount of scanout engines which you need to dynamically
allocate.

> On 2016年07月26日 17:51, Mark yao wrote:
> > On 2016年07月26日 16:26, Daniel Vetter wrote:
> > > On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
> > > > >What is share plane:
> > > > >Plane hardware only be used when the display scanout run into
> > > > plane active
> > > > >scanout, that means we can reuse the plane hardware resources on plane
> > > > >non-active scanout.
> > > > >
> > > > >  --
> > > > > |  scanout   |
> > > > > | -- |
> > > > > | | parent plane   | |
> > > > > | | active scanout | |
> > > > > | ||   - |
> > > > > | --   | share plane 1 | |
> > > > > |  -   |active scanout | |
> > > > > |  | share plane 0 |   |   | |
> > > > > |  |active scanout |   - |
> > > > > |  |   | |
> > > > > |  - |
> > > > > --
> > > > >One plane hardware can be reuse for multi-planes, we assume the first
> > > > >plane is parent plane, other planes share the resource with first one.
> > > > > parent plane
> > > > > |---share plane 0
> > > > > |---share plane 1
> > > > > ...
> > > > >
> > > > >Because resource share, There are some limit on share plane: one group
> > > > >of share planes need use same zpos, can not overlap, etc.
> > > > >
> > > > >We assume share plane is a universal plane with some limit flags.
> > > > >people who use the share plane need know the limit, should call
> > > > the ioctl
> > > > >DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
> > > > >
> > > > >A group of share planes would has same shard id, so userspace can
> > > > >group them, judge share plane's limit.
> > > > >
> > > > >Signed-off-by: Mark Yao
> > > This seems extremely hw specific, why exactly do we need to add a new
> > > relationship on planes? What does this buy on_other_  drivers?
> > Yes, now it's plane hardware specific, maybe others have same design,
> > because this design
> > would save hardware resource to support multi-planes.
> > 
> > > Imo this should be solved by virtualizing planes in the driver.
> > > Start out
> > > by assigning planes, and if you can reuse one for sharing then do that,
> > > otherwise allocate a new one. If there's not enough real planes,
> > > fail the
> > > atomic_check.
> > I think that is too complex, trying with atomic_check I think it's not a
> > good idea, userspace try planes every commit would be a heavy work.
> > 
> > Userspace need  know all planes relationship, group them, some display
> > windows can put together, some can't,
> > too many permutation and combination, I think can't just commit with try.
> > 
> > example:
> > userspace:
> > windows 1: pos(0, 0)  size(1024, 100)
> > windows 2: pos(0, 50) size(400, 500)
> > windows 3: pos(0, 200) size(800, 300)
> > 
> > drm plane resources:
> > plane 0 and plane 1 is a group of share planes
> > plane 2 is common plane.
> > 
> > if userspace know the relationship, then they can assign windows 1 and
> > window 3 to plane0 and plane 1. that would be success.
> > but if they don't know, assign window 1/2 to plane 0/1, failed, assign
> > window 2/3 to plane 0/1, failed. mostly would get failed.

You can still do this with the design I describe. The only difference is
that you allow generic userspace to make optimal use of your planes, too.

> > > This seems way to hw specific to be useful as a generic concept.
> > 
> > We want to change the drm_mode_getplane_res behavior, if userspace call
> > DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware limit,
> > then we return full planes support to userspace, if don't, just make a
> > group of share planes as one plane.
> > this work is 

[PATCH] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?

2016-07-28 Thread Joonas Lahtinen
On ti, 2016-07-26 at 10:49 -0400, Sean Paul wrote:
> On Mon, Jul 25, 2016 at 3:00 AM, Joonas Lahtinen
>  wrote:
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 3edeaf8..57bbc61 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -84,13 +84,13 @@ static inline uint64_t I642U64(int64_t val)
> >   * DRM_REFLECT_Y reflects the image along the specified axis prior to 
> > rotation
> >   */
> >  #define DRM_ROTATE_MASK 0x0f
> > -#define DRM_ROTATE_0   0
> > -#define DRM_ROTATE_90  1
> > -#define DRM_ROTATE_180 2
> > -#define DRM_ROTATE_270 3
> > +#define DRM_ROTATE_0   BIT(0)
> > +#define DRM_ROTATE_90  BIT(1)
> > +#define DRM_ROTATE_180 BIT(2)
> > +#define DRM_ROTATE_270 BIT(3)
> >  #define DRM_REFLECT_MASK (~DRM_ROTATE_MASK)
> It's probably a good time to give these masks a little love. Could we
> just generate them (both ROTATE and REFLECT) from the ROTATE and
> REFLECT values now?

I was consider it too, so I think it would be an OK change. Fine with
the patch otherwise? I can send a revised version with that changed.

Regards, Joonas

> 
> Sean
> 
> > 
> > -#define DRM_REFLECT_X  4
> > -#define DRM_REFLECT_Y  5
> > +#define DRM_REFLECT_X  BIT(4)
> > +#define DRM_REFLECT_Y  BIT(5)
> > 
> >  enum drm_connector_force {
> >         DRM_FORCE_UNSPECIFIED,
> > --
> > 2.5.5
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation


[PATCH -next] drm/arm: mali-dp: Fix error return code in malidp_bind()

2016-07-28 Thread Brian Starkey
Hi Wei,

On Thu, Jul 28, 2016 at 02:14:26AM +, Wei Yongjun wrote:
>Fix to return error code -EINVAL from the error handling
>case instead of 0, as done elsewhere in this function.
>
>Fixes: 3c31760e760c ('drm/arm: mali-dp: Set crtc.port to the port
>instead of the endpoint')
>Signed-off-by: Wei Yongjun 
>---

Thanks for cleaning up after me! :-)

Acked-by: Brian Starkey 

@Sean, can you pick this up on top of 3c31760e760c?

Cheers,
Brian

> drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
>b/drivers/gpu/drm/arm/malidp_drv.c
>index 4e61ea5..44b24cb 100644
>--- a/drivers/gpu/drm/arm/malidp_drv.c
>+++ b/drivers/gpu/drm/arm/malidp_drv.c
>@@ -362,8 +362,10 @@ static int malidp_bind(struct device *dev)
>
>   /* Set the CRTC's port so that the encoder component can find it */
>   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
>-  if (!ep)
>+  if (!ep) {
>+  ret = -EINVAL;
>   goto port_fail;
>+  }
>   malidp->crtc.port = of_get_next_parent(ep);
>
>   ret = component_bind_all(dev, drm);
>


[PATCH -next] drm/arm: mali-dp: Remove redundant dev_err call in malidp_bind()

2016-07-28 Thread Liviu Dudau
On Thu, Jul 28, 2016 at 02:09:13AM +, Wei Yongjun wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the DRM_ERROR call to avoid redundant
> error message.

Yeah, good catch!

> 
> Signed-off-by: Wei Yongjun 

Acked-by: Liviu Dudau 


Thanks for the cleanup!
Liviu

> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 4e61ea5..1160322 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -285,10 +285,8 @@ static int malidp_bind(struct device *dev)
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   hwdev->regs = devm_ioremap_resource(dev, res);
> - if (IS_ERR(hwdev->regs)) {
> - DRM_ERROR("Failed to map control registers area\n");
> + if (IS_ERR(hwdev->regs))
>   return PTR_ERR(hwdev->regs);
> - }
>  
>   hwdev->pclk = devm_clk_get(dev, "pclk");
>   if (IS_ERR(hwdev->pclk))
> 

-- 

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


[PATCH v4 2/5] dma-buf/sync_file: refactor fence storage in struct sync_file

2016-07-28 Thread Greg Kroah-Hartman
On Thu, Jul 28, 2016 at 04:30:36PM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> On 19 July 2016 at 17:51, Sumit Semwal  wrote:
> > (Adding Greg KH)
> >
> > Hi Greg,
> >
> > On 19 July 2016 at 17:45, Sumit Semwal  wrote:
> >> Hi Greg,
> >>
> >>
> >> On 12 July 2016 at 23:38, Gustavo Padovan  wrote:
> >>> From: Gustavo Padovan 
> >>>
> >>> Create sync_file->fence to abstract the type of fence we are using for
> >>> each sync_file. If only one fence is present we use a normal struct fence
> >>> but if there is more fences to be added to the sync_file a fence_array
> >>> is created.
> >>>
> >>> This change cleans up sync_file a bit. We don't need to have sync_file_cb
> >>> array anymore. Instead, as we always have  one fence, only one fence
> >>> callback is registered per sync_file.
> >>>
> >> Since this is a simple change in sync_debug,c, may I request for your
> >> Ack so I could take it along with the other dma-buf patches?
> >>
> > Missed the fact that you weren't CCed; for this simple update to
> > sync_debug,c, may I request for your Ack so I can take it with dam-buf
> > patches?
> 
> Gentle reminder please: since it's a small change, if you could Ack
> it, I'd be happy to take it along with the dma-buf patches and queue
> it up.

Ugh, sorry, vacation and travel and merge window hasn't been good to me
this cycle...

This is fine with me, please take it through your tree if you want to,
and again, sorry for the delay in responding.  Usually, for staging
bits, if you want/need to merge something due to an api change, no need
to wait for me, I can handle any merge conflicts / issues that might
come up after the fact.

Acked-by: Greg Kroah-Hartman 

thanks,

greg k-h


[PATCH v4 5/6] drm/i915/skl: Update plane watermarks atomically during plane updates

2016-07-28 Thread Matt Roper
On Tue, Jul 26, 2016 at 01:34:41PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
> 
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
> 
> With this in mind, up until now we've been updating watermarks on skl
> like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
>   or
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
> Now we update watermarks atomically like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks() (wm values aren't written yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
>   }
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks() (actual wm values aren't written
>   yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
>   - write new wm values
> - end vblank evasion
>   }
> 
> So this patch moves all of the watermark writes into the right place;
> inside of the vblank evasion where we update all of the registers for
> each plane. While this patch doesn't fix everything, it does allow us to
> update the watermark values in the way the hardware expects us to.
> 
> Changes since original patch series:
>  - Remove mutex_lock/mutex_unlock since they don't do anything and we're
>not touching global state
>  - Move skl_write_cursor_wm/skl_write_plane_wm functions into
>intel_pm.c, make externally visible
>  - Add skl_write_plane_wm calls to skl_update_plane
>  - Fix conditional for for loop in skl_write_plane_wm (level < max_level
>should be level <= max_level)
>  - Make diagram in commit more accurate to what's actually happening
>  - Add Fixes:
> 
> Changes since v1:
>  - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
>then just Skylake
>  - Update description to make it clear this patch doesn't fix everything
>  - Check if pipes were actually changed before writing watermarks
> 
> Changes since v2:
>  - Write PIPE_WM_LINETIME during vblank evasion
> 
> Changes since v3:
>  - Rebase against new SAGV patch changes
> 
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude 
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  5 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 58 
> ++--
>  drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
>  4 files changed, 51 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b80c051..cd67945 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   intel_crtc->adjusted_x = x_offset;
>   intel_crtc->adjusted_y = y_offset;
>  
> + skl_write_plane_wm(intel_crtc, 0);
> +
>   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
>   I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
>   I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
> @@ -10261,6 +10263,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
> u32 base,
>   int pipe = intel_crtc->pipe;
>   uint32_t cntl = 0;
>  
> + if (IS_GEN9(dev_priv))
> + skl_write_cursor_wm(intel_crtc);
> +
>   if (plane_state && plane_state->visible) {
>   cntl = MCURSOR_GAMMA_ENABLE;
>   switch (plane_state->base.crtc_w) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> 

[PATCH v4 3/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

2016-07-28 Thread Matt Roper
On Tue, Jul 26, 2016 at 01:34:39PM -0400, Lyude wrote:
> Manual pipe flushes are only necessary in order to make sure that we prevent
> pipes with changed ddb allocations from overlapping from one another at
> any point in time. Additionally, forcing us to wait for the next vblank
> every time we have to update the watermark values because the cursor was
> moving between screens will introduce a rather noticable lag for users.
> 
> Signed-off-by: Lyude 
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c | 31 +--
>  2 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1f6fe8c..d65e897 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1597,6 +1597,7 @@ struct skl_ddb_allocation {
>  
>  struct skl_wm_values {
>   unsigned dirty_pipes;
> + bool ddb_changed;
>   struct skl_ddb_allocation ddb;
>   uint32_t wm_linetime[I915_MAX_PIPES];
>   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ae3f2b..cda4196 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3892,6 +3892,12 @@ static void skl_flush_wm_values(struct 
> drm_i915_private *dev_priv,
>   new_ddb = _values->ddb;
>   cur_ddb = _priv->wm.skl_hw.ddb;
>  
> + /* We only ever need to flush when the ddb allocations change */
> + if (!new_values->ddb_changed)
> + return;
> +
> + new_values->ddb_changed = false;
> +
>   /*
>* First pass: flush the pipes with the new allocation contained into
>* the old space.
> @@ -3996,6 +4002,22 @@ pipes_modified(struct drm_atomic_state *state)
>   return ret;
>  }
>  
> +static bool
> +skl_pipe_ddb_changed(struct skl_ddb_allocation *old,
> +  struct skl_ddb_allocation *new,
> +  enum pipe pipe)
> +{
> + if (memcmp(>pipe[pipe], >pipe[pipe],
> +sizeof(old->pipe[pipe])) != 0 ||
> + memcmp(>plane[pipe], >plane[pipe],
> +sizeof(old->plane[pipe])) != 0 ||
> + memcmp(>y_plane[pipe], >y_plane[pipe],
> +sizeof(old->y_plane[pipe])) != 0)
> + return true;
> +
> + return false;
> +}
> +
>  static int
>  skl_compute_ddb(struct drm_atomic_state *state)
>  {
> @@ -4003,7 +4025,8 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   struct intel_crtc *intel_crtc;
> - struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
> + struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
> + struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
>   uint32_t realloc_pipes = pipes_modified(state);
>   int ret;
>  
> @@ -4041,9 +4064,13 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   if (IS_ERR(cstate))
>   return PTR_ERR(cstate);
>  
> - ret = skl_allocate_pipe_ddb(cstate, ddb);
> + ret = skl_allocate_pipe_ddb(cstate, new_ddb);
>   if (ret)
>   return ret;
> +
> + if (!intel_state->wm_results.ddb_changed &&

I think you can simplify and drop the first part of this condition here,
but in general,

Reviewed-by: Matt Roper 


> + skl_pipe_ddb_changed(old_ddb, new_ddb, intel_crtc->pipe))
> + intel_state->wm_results.ddb_changed = true;
>   }
>  
>   return 0;
> -- 
> 2.7.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795


[PATCH v4 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-07-28 Thread Matt Roper
On Tue, Jul 26, 2016 at 01:34:37PM -0400, Lyude wrote:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however, is the mysterious issue of
> underruns causing full system hangs. An easy way to reproduce this with
> a skylake system:
> 
> - Get a laptop with a skylake GPU, and hook up two external monitors to
>   it
> - Move the cursor from the built-in LCD to one of the external displays
>   as quickly as you can
> - You'll get a few pipe underruns, and eventually the entire system will
>   just freeze.
> 
> After doing a lot of investigation and reading through the bspec, I
> found the existence of the SAGV, which is responsible for adjusting the
> system agent voltage and clock frequencies depending on how much power
> we need. According to the bspec:
> 
> "The display engine access to system memory is blocked during the
>  adjustment time. SAGV defaults to enabled. Software must use the
>  GT-driver pcode mailbox to disable SAGV when the display engine is not
>  able to tolerate the blocking time."
> 
> The rest of the bspec goes on to explain that software can simply leave
> the SAGV enabled, and disable it when we use interlaced pipes/have more
> then one pipe active.
> 
> Sure enough, with this patchset the system hangs resulting from pipe
> underruns on Skylake have completely vanished on my T460s. Additionally,
> the bspec mentions turning off the SAGV   with more then one pipe enabled
> as a workaround for display underruns. While this patch doesn't entirely
> fix that, it looks like it does improve the situation a little bit so
> it's likely this is going to be required to make watermarks on Skylake
> fully functional.
> 
> Changes since v4:
>  - Use is_power_of_2 against active_crtcs to check whether we have > 1
>pipe enabled
>  - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
>enabled
>  - Call skl_sagv_enable/disable() from pre/post-plane updates
> Changes since v3:
>  - Use time_before() to compare timeout to jiffies
> Changes since v2:
>  - Really apply minor style nitpicks to patch this time
> Changes since v1:
>  - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
>  - Minor style nitpicks from Matt Roper
>  - Disable these functions on Broxton, since it doesn't have an SAGV
> 
> Reviewed-by: Matt Roper 
> Signed-off-by: Lyude 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>  drivers/gpu/drm/i915/i915_reg.h  |   5 ++
>  drivers/gpu/drm/i915/intel_display.c |  19 +++
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_pm.c  | 105 
> +++
>  5 files changed, 133 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9f655e2..1f6fe8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1962,6 +1962,8 @@ struct drm_i915_private {
>   struct i915_suspend_saved_registers regfile;
>   struct vlv_s0ix_state vlv_s0ix_state;
>  
> + bool skl_sagv_enabled;
> +
>   struct {
>   /*
>* Raw watermark latency values:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9397dde..89d146f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7166,6 +7166,11 @@ enum {
>  #define   HSW_PCODE_DE_WRITE_FREQ_REQ0x17
>  #define   DISPLAY_IPS_CONTROL0x19
>  #defineHSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
> +#define   GEN9_PCODE_SAGV_CONTROL0x21
> +#define GEN9_SAGV_DISABLE0x0
> +#define GEN9_SAGV_LOW_FREQ   0x1
> +#define GEN9_SAGV_HIGH_FREQ  0x2
> +#define GEN9_SAGV_DYNAMIC_FREQ  0x3
>  #define GEN6_PCODE_DATA  _MMIO(0x138128)
>  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
>  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT   16
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 78beb7e..b80c051 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4562,9 +4562,12 @@ static void intel_post_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
>   struct drm_atomic_state *old_state = old_crtc_state->base.state;
> + struct intel_atomic_state *old_intel_state =
> + to_intel_atomic_state(old_state);
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc->base.state);
>  

[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94860

--- Comment #10 from Laurent carlier  ---
I can't reproduce this anymore.

-- 
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/20160728/6e3c8d1d/attachment.html>


[Bug 91221] UVD: GPU lockup with BARTS

2016-07-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91221

--- Comment #2 from Chí-Thanh Christopher Nguyễn  ---
Created attachment 125358
  --> https://bugs.freedesktop.org/attachment.cgi?id=125358=edit
dmesg from kernel 4.7.0

The problem still happens with kernel 4.7.0

Sometimes, but not always, it seems that the driver is able to recover on its
own. But even in that case, the video will hang until I stop and restart it,
and after a few minutes the problem will show up again.

-- 
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/20160728/a8ea9729/attachment.html>


[PATCH -next] drm/arm: mali-dp: Fix error return code in malidp_bind()

2016-07-28 Thread Wei Yongjun
Fix to return error code -EINVAL from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 3c31760e760c ('drm/arm: mali-dp: Set crtc.port to the port
instead of the endpoint')
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4e61ea5..44b24cb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -362,8 +362,10 @@ static int malidp_bind(struct device *dev)

/* Set the CRTC's port so that the encoder component can find it */
ep = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (!ep)
+   if (!ep) {
+   ret = -EINVAL;
goto port_fail;
+   }
malidp->crtc.port = of_get_next_parent(ep);

ret = component_bind_all(dev, drm);



[PATCH -next] drm/arm: mali-dp: Remove redundant dev_err call in malidp_bind()

2016-07-28 Thread Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the DRM_ERROR call to avoid redundant
error message.

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

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4e61ea5..1160322 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -285,10 +285,8 @@ static int malidp_bind(struct device *dev)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hwdev->regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(hwdev->regs)) {
-   DRM_ERROR("Failed to map control registers area\n");
+   if (IS_ERR(hwdev->regs))
return PTR_ERR(hwdev->regs);
-   }

hwdev->pclk = devm_clk_get(dev, "pclk");
if (IS_ERR(hwdev->pclk))



[benjamin.gaignard:generic-zpos-v7 2/5] ERROR: "drm_atomic_helper_normalize_zpos" [drivers/gpu/drm/drm_kms_helper.ko] undefined!

2016-07-28 Thread kbuild test robot
tree:   https://git.linaro.org/people/benjamin.gaignard/kernel generic-zpos-v7
head:   8298ff6fe0b5241f7d4012901ae5bdbcb253051d
commit: 8f2efe1cee8fa2dca73eeb440aa993c434b43fe6 [2/5] drm: add generic zpos 
property
config: x86_64-randconfig-i0-201630 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
git checkout 8f2efe1cee8fa2dca73eeb440aa993c434b43fe6
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "drm_atomic_helper_normalize_zpos" 
>> [drivers/gpu/drm/drm_kms_helper.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24421 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160728/ccc5fc53/attachment-0001.obj>