[linux-sunxi] [PATCH v2 4/9] drm/sun4i: Add a DRC driver

2016-09-06 Thread Peter Korsgaard
> "Maxime" == Maxime Ripard  writes:

 > The A33 pipeline also has a component called DRC. Even though its exact
 > features and programming model is not known (or documented), it needs to
 > be clocked for the pipeline to carry the video signal all the way.

 > Add a minimal driver for it that just claim the needed resources for the
 > pipeline to operate properly.

 > Signed-off-by: Maxime Ripard 

Acked-by: Peter Korsgaard 

-- 
Bye, Peter Korsgaard


[Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

2016-09-06 Thread Nicolas Iooss
On 06/09/16 12:21, Dave Gordon wrote:
> On 04/09/16 19:58, Nicolas Iooss wrote:
>> When building the kernel with clang and some warning flags, the compiler
>> reports that the return value of dcs_get_backlight() may be
>> uninitialized:
>>
>> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable
>> 'data' is used uninitialized whenever 'for' loop exits because its
>> condition is false [-Werror,-Wsometimes-uninitialized]
>> for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
>> ^~~
>> drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
>> 'for_each_dsi_port'
>> #define for_each_dsi_port(__port, __ports_mask)
>> for_each_port_masked(__port,
>> __ports_mask)
>>
>> ^~
>> drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
>> 'for_each_port_masked'
>> for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
>> ^
>> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
>> uninitialized use occurs here
>> return data;
>>^~~~
>>
>> As intel_dsi->dcs_backlight_ports seems to be always initialized to a
>> non-null value, the content of the for loop is always executed and there
>> is no bug in the current code. Nevertheless the compiler has no way of
>> knowing that assumption, so initialize variable 'data' to silence the
>> warning here.
>>
>> Signed-off-by: Nicolas Iooss 
> 
> Interesting ... there are two things that could lead to this (possibly)
> incorrect analysis. Either it thinks the loop could be executed zero
> times, which would be a deficiency in the compiler, as the initialiser
> and loop bound are both known (different) constants:
> 
> enum port {
> PORT_A = 0,
> PORT_B,
> PORT_C,
> PORT_D,
> PORT_E,
> I915_MAX_PORTS
> };
> 
> or, it doesn't understand that because we've passed  to another
> function, it can have been set by the callee. It may be extra confusing
> that the callee takes (void *); or it may be being ultra-sophisticated
> in its analysis and noted that in one error path data is *not* set (and
> we then discard the error and use data anyway). As an experiment, you
> could try:

The code that the compiler sees is not a simple loop other enum 'port'
but "for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {", which
is expanded [1] to:

for ((port) = PORT_A; (port) < I915_MAX_PORTS; (port)++)
  if (!((intel_dsi->dcs_backlight_ports) & (1 << (port {} else {

This is why I spoke of intel_dsi->dcs_backlight_ports in my description:
if it is zero, the body of the loop is never run.

As for the analyses of calls using , clang does not warn about the
variable being maybe uninitialized following a call. This is quite
expected as this would lead to too many false positives, even though it
may miss some bugs.

> 
> static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
> {
> u8 data = 0;
> 
> mipi_dsi_dcs_read(dsi_device, cmd, , sizeof(data));
> 
> return data;
> }
> 
> static u32 dcs_get_backlight(struct intel_connector *connector)
> {
> struct intel_encoder *encoder = connector->encoder;
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> struct mipi_dsi_device *dsi_device;
> enum port port;
> u8 data;
> 
> /* FIXME: Need to take care of 16 bit brightness level */
> for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
> dsi_device = intel_dsi->dsi_hosts[port]->device;
> data = mipi_dsi_dcs_read1(dsi_device,
> MIPI_DCS_GET_DISPLAY_BRIGHTNESS);
> break;
> }
> 
> return data;
> }
> 
> If it complains about that then it's a shortcoming in the loop analysis.

It complains (in dcs_get_backlight), because for_each_dsi_port() still
hides an 'if' condition.

> If not you could try:
> 
> static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
> {
> u8 data;
> ssize_t nbytes = sizeof(data);
> 
> nbytes = mipi_dsi_dcs_read(dsi_device, cmd, , nbytes);
> return nbytes == sizeof(data) ? data : 0;
> }
> 
> and if complains about that then it doesn't understand that passing
>  allows it to be set. If it doesn't complain about this version,
> then the original error was actually correct, in the sense that data can
> indeed be used uninitialised if certain error paths can be taken.

clang did not complain with this last case.

> Here's an R-b for your fix anyway ...
> 
> Reviewed-by: Dave Gordon 

Thanks!

Nicolas


[1] I used "make drivers/gpu/drm/i915/intel_dsi_dcs_backlight.i" to see
the output of the preprocessor.



[RFC] drm/gma500: add virtual mapping support for fbdev.

2016-09-06 Thread Alan Cox
On Tue, 2016-09-06 at 19:28 +0800, jiang.biao2 at zte.com.cn wrote:
> Hi, 
> 
> I found current gma500 fbdev driver does not support the virtual 
> mapping for the fb pages, instead it only uses stolen pages and 
> supports high resolution console by reducing the color depth. It 
> works well with fbcon for high resolution envirnment. 

The text mode console code can't support a non-linear mapping and
trying to grab one used most or all of the vmalloc address space on a
32bit box (and most of those systems are only able to run 32bit).

For the sake of a bootscreen loader (which could use DRM directly
instead if it needed high resolution) it didn't seem worht it.

Either way it's not IMHO a good idea for 32bit, 64bit maybe.

Alan



[Bug 97618] W600 (Cape Verde PRO): reproducible hang on piglit test spec@ext_texture_lod_bias@lodbias in drmCommandWrite()

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97618

--- Comment #1 from Dan Kegel  ---
Sorry, there was a bit of garbage at the start of that /var/log/kern.log
output, ignore everything before second 6000.

-- 
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/20160906/57865f9f/attachment.html>


[Bug 97618] W600 (Cape Verde PRO): reproducible hang on piglit test spec@ext_texture_lod_bias@lodbias in drmCommandWrite()

2016-09-06 Thread bugzilla-dae...@freedesktop.org
rm_ioctl+0x4c/0x80 [radeon]
[ 6000.669110]  [] do_vfs_ioctl+0x29f/0x490
[ 6000.669113]  [] ? __do_page_fault+0x1b4/0x400
[ 6000.669115]  [] SyS_ioctl+0x79/0x90
[ 6000.669118]  [] entry_SYSCALL_64_fastpath+0x16/0x71

-- 
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/20160906/7b26cbd0/attachment-0001.html>


[Bug 97594] [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various SI functions" breaks amdgpu support for SI

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97594

--- Comment #4 from Arek Ruśniak  ---
Could you share config and patchset for your preempt kernel. If I will have
some time I could build it. I'm just curious.

I know nothing about what preempt is. I think I should rather call my kernel -
"generic" but "uname -a" gives me:
Linux darkfruit 4.8.0-rc1-20160904 #10 SMP PREEMPT Tue Sep 6 23:01:48 CEST 2016
x86_64 GNU/Linux
So I'm confused about it

-- 
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/20160906/f71eeca6/attachment.html>


[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-09-06 Thread Ville Syrjälä
On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 06, 2016 at 12:20:51PM +0300, Ville Syrjälä wrote:
> > On Sun, Aug 28, 2016 at 05:28:46PM +0200, Andrea Arcangeli wrote:
> > > Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> > > model which is based on IvyBridge.
> > > 
> > > The commit that introduced the regression is
> > > 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > 
> > > The Skylake workaround for the regression was introduced in commit
> > > aeddda06c1a704bb97c8a7bfe7a472120193bd56
> > > 
> > > Signed-off-by: Andrea Arcangeli 
> > > ---
> > >  drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> > > b/drivers/gpu/drm/i915/intel_opregion.c
> > > index adca262..ca17ab6 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct 
> > > drm_i915_private *dev_priv)
> > >   }
> > >  
> > >   /*
> > > -  * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> > > -  * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> > > -  * vswing instead. Low vswing results in some display flickers, so
> > > -  * let's simply ignore the OpRegion panel type on SKL for now.
> > > +  * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> > > +  * OpRegion panel type (0) gives us low vswing for eDP,
> > > +  * whereas the VBT panel type (2) gives us normal vswing
> > > +  * instead. Low vswing results in some display flickers, so
> > > +  * let's simply ignore the OpRegion panel type on SKL and
> > > +  * IVYBRIDGE for now.
> > >*/
> > > - if (IS_SKYLAKE(dev_priv)) {
> > > + if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
> > >   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> > >   return -ENODEV;
> > >   }
> > 
> > Argh. I guess we'll just have to revert the whole opregion panel type thing
> > and ty to figure out some way to do this only for the system(s) that need 
> > it.
> > 
> > Hmm. Can someone test the top commit from [1] on top of the broken kernel?
> > If we can get an EDID somehow for the panel then the panel type shouldn't
> > matter that much any more.
> > 
> > [1] git://github.com/vsyrjala/linux.git acpi_edid
> 
> Actually I just cooked up another branch [2]. It just throws in some
> memory barriers to the opregion code, and adds a a new debug print so
> to show the response from the BIOS. I'm not too optimistic that the
> memory barriers would fix it, but at least we'd get to see the full
> response from the BIOS. Can you give this a try?
> 
> [2] git://github.com/vsyrjala/linux.git opregion_panel_type_stuff

And I've gone an pushed a potential fix to the same branch. So pleas try
it and let me know how it goes. And I still would like to see the dmesg
with drm.debug=0xe from that attempt.

-- 
Ville Syrjälä
Intel OTC


[PATCH 0/7] drm/sun4i: Introduce A33 display driver

2016-09-06 Thread Maxime Ripard
On Tue, Sep 06, 2016 at 10:50:09AM +0800, Chen-Yu Tsai wrote:
> >> The implementation might be along the lines of
> >>
> >>   1. having multiple output ports, each for a different interface type.
> >>  (Some platforms go this route)
> >>
> >> Or
> >>
> >>   2. having a DT property describe what the output interface is.
> >>
> >> The RGB/TCON driver would then setup the registers accordingly.
> >
> > Hmmm, yeah, we would need to adjust the bindings too...
> >
> > I guess I'd prefer 1), but that would also be the most invasive
> > solution. I'm not sure how the DT maintainers feel about that.
> 
> I wonder if the TCON could use its 2 channels simultaneously?

No, it's mutually exclusive.

> Like output to one LCD, then mirror through HDMI/VGA?
> The first option would be able to cover this better?

Even if it wasn't exclusive, that wouldn't be possible
unfortunately. Or rather, this would be possible if the LCD and the
HDMI screen had the same timings, which is very unlikely.

> And you still need to add outgoing endpoints for the HDMI block.

Indeed.

> In addition we'll have to rework the TV encoder binding as well.
> 
> The 2 TV encoders (on the A20) each have four DACs, which map
> onto 4 external pins. The address space includes a not so easy
> to use mux. More importantly, the binding needs to specify which
> pin is used for what signal (RGB, YUV, S/Video, composite).
> There seems to be an implicit rule that 1 pin is always used
> for composite, and the 3 others RGB, though.

I'm not sure why we would need to rework this one though. We have no
way to detect whether the screen is connected or not on either
connectors, and we can't have both output running at the same time for
the same reason than mention above.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- 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/20160906/906fe9ee/attachment.sig>


[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97593

--- Comment #8 from Arek Ruśniak  ---
*Michel
it's embarrassing

-- 
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/20160906/88d63d41/attachment.html>


[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97593

--- Comment #7 from Arek Ruśniak  ---
Michael yes, it fix the problem. VM-errors are still making some noise but i
think it's another problem.
thx

-- 
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/20160906/0d780927/attachment.html>


[question]Implemention of drm_driver.dumb_create

2016-09-06 Thread Rongrong Zou
Hi, all

 I want to implement memory management for my new drm driver,
it is for a display controller attached to PCIe bus of our SOC,
however, I found two kind of implementions in existing kernel drivers:

one is implemented with gem + ttm, such as bochs/cirrus/amdgpu,
the other is implemented with gem only, such as intel i915/exynos;
so which way should i choose, can someone give me some advice?
thanks!

-- 
Regards, Rongrong


[RFC] drm/gma500: add virtual mapping support for fbdev.

2016-09-06 Thread jiang.bi...@zte.com.cn
fb_create(struct psb_fbdev *fbdev,
return -ENOMEM;
}

-   memset(dev_priv->vram_addr + backing->offset, 0, size);
+   if (backing->stolen)
+   memset(dev_priv->vram_addr + backing->offset, 0, size);

info = drm_fb_helper_alloc_fbi(>psb_fb_helper);
if (IS_ERR(info)) {
@@ -434,8 +454,20 @@ static int psbfb_create(struct psb_fbdev *fbdev,
info->fix.ywrapstep = gtt_roll;
info->fix.ypanstep = 0;

-   /* Accessed stolen memory directly */
-   info->screen_base = dev_priv->vram_addr + backing->offset;
+   if (backing->stolen) {
+   info->screen_base = dev_priv->vram_addr + backing->offset;
+   } else {
+   psb_gtt_pin(backing);
+   backing->mapping = 1;
+   info->screen_base = vm_map_ram(backing->pages, 
backing->npage, -1, PAGE_KERNEL);
+   if (info->screen_base == NULL) {
+   ret = -ENOMEM;
+   goto err_free_range;
+   }
+   psbfb->vm_map = 1;
+ 
+   }
+
info->screen_size = size;

if (dev_priv->gtt.stolen_size) {
@@ -458,7 +490,10 @@ static int psbfb_create(struct psb_fbdev *fbdev,
 err_release:
drm_fb_helper_release_fbi(>psb_fb_helper);
 err_free_range:
-   psb_gtt_free_range(dev, backing);
+   if (backing->stolen)
+   psb_gtt_free_range(dev, backing);
+   else if(psbfb->vm_map)
+   vm_unmap_ram(info->screen_base, backing->npage);
return ret;
 }

@@ -523,15 +558,6 @@ static int psbfb_probe(struct drm_fb_helper *helper,
if (bytespp == 3)   /* no 24bit packed */
bytespp = 4;

-   /* If the mode will not fit in 32bit then switch to 16bit to get
-  a console on full resolution. The X mode setting server will
-  allocate its own 32bit GEM framebuffer */
-   if (ALIGN(sizes->fb_width * bytespp, 64) * sizes->fb_height >
-   dev_priv->vram_stolen_size) {
-sizes->surface_bpp = 16;
-sizes->surface_depth = 16;
-}
-
return psbfb_create(psb_fbdev, sizes);
 }

@@ -545,6 +571,12 @@ static int psb_fbdev_destroy(struct drm_device *dev, 
struct psb_fbdev *fbdev)
 {
struct psb_framebuffer *psbfb = >pfb;

+   info = fbdev->psb_fb_helper.fbdev;
+   if (psbfb->vm_map) {
+   vm_unmap_ram(info->screen_base, psbfb->gtt->npage);
+   psb_gtt_unpin(psbfb->gtt);
+   }
+
drm_fb_helper_unregister_fbi(>psb_fb_helper);
drm_fb_helper_release_fbi(>psb_fb_helper);

diff --git a/drivers/gpu/drm/gma500/framebuffer.h 
b/drivers/gpu/drm/gma500/framebuffer.h
index 395f20b..50b384e 100644
--- a/drivers/gpu/drm/gma500/framebuffer.h
+++ b/drivers/gpu/drm/gma500/framebuffer.h
@@ -32,6 +32,8 @@ struct psb_framebuffer {
struct address_space *addr_space;
struct fb_info *fbdev;
struct gtt_range *gtt;
+   bool vm_map;
+
 };

 struct psb_fbdev {
-- 
2.1.0
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160906/c5754d69/attachment-0001.html>


[Bug 97594] [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various SI functions" breaks amdgpu support for SI

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97594

--- Comment #3 from Konstantin A. Lepikhov  ---
(In reply to Arek Ruśniak from comment #0)
> Created attachment 126204 [details]
> dmesg for first bad commit
> 
> With this commit displays off during loading amdgpu, sysrq don't work, boot
> is stopped. 
> When i reverted it, amdgpu works as always.
> 
> dmesg is silent

Same behavior but on PREEMPT kernel even without mentioned patch. Just to
clarify that it could be more general problem than locking in this particular
place.

-- 
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/20160906/6ddcf253/attachment.html>


[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97593

--- Comment #6 from Konstantin A. Lepikhov  ---
(In reply to Michel Dänzer from comment #5)
> Created attachment 126237 [details] [review]
> Update active VRAM size when turning DMA on/off
> 
> Does this patch fix the problem?

It helped in my case - FPS in Heaven increased from 1 to 15 and VRAM usage was
optimal.

-- 
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/20160906/180b49b5/attachment-0001.html>


[PATCH v2 2/2] libdrm: add etnaviv tests

2016-09-06 Thread Christian Gmeiner
From: The etnaviv authors 

This adds the following basic unit tests:

- etnaviv_2d_test
  Let the 2D core render a defined pattern into a bo
  and store it as bmp.

- etnaviv_bo_cache_test
  Basic tests to validate the bo-cache behavior.

- etnaviv_cmd_stream_test
  Tests for the etna_cmd_stream API.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
---
 .gitignore  |3 +
 configure.ac|1 +
 tests/Makefile.am   |4 +
 tests/etnaviv/Makefile.am   |   41 +
 tests/etnaviv/cmdstream.xml.h   |  242 +
 tests/etnaviv/etnaviv_2d_test.c |  240 +
 tests/etnaviv/etnaviv_bo_cache_test.c   |  121 +++
 tests/etnaviv/etnaviv_cmd_stream_test.c |  123 +++
 tests/etnaviv/state.xml.h   |  375 
 tests/etnaviv/state_2d.xml.h| 1497 +++
 tests/etnaviv/write_bmp.c   |  152 
 tests/etnaviv/write_bmp.h   |   34 +
 12 files changed, 2833 insertions(+)
 create mode 100644 tests/etnaviv/Makefile.am
 create mode 100644 tests/etnaviv/cmdstream.xml.h
 create mode 100644 tests/etnaviv/etnaviv_2d_test.c
 create mode 100644 tests/etnaviv/etnaviv_bo_cache_test.c
 create mode 100644 tests/etnaviv/etnaviv_cmd_stream_test.c
 create mode 100644 tests/etnaviv/state.xml.h
 create mode 100644 tests/etnaviv/state_2d.xml.h
 create mode 100644 tests/etnaviv/write_bmp.c
 create mode 100644 tests/etnaviv/write_bmp.h

diff --git a/.gitignore b/.gitignore
index 3226b3a..d51e619 100644
--- a/.gitignore
+++ b/.gitignore
@@ -102,4 +102,7 @@ tests/radeon/radeon_ttm
 tests/exynos/exynos_fimg2d_event
 tests/exynos/exynos_fimg2d_perf
 tests/exynos/exynos_fimg2d_test
+tests/etnaviv/etnaviv_2d_test
+tests/etnaviv/etnaviv_cmd_stream_test
+tests/etnaviv/etnaviv_bo_cache_test
 man/*.3
diff --git a/configure.ac b/configure.ac
index 64f3e6c..330358a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -551,6 +551,7 @@ AC_CONFIG_FILES([
tests/exynos/Makefile
tests/tegra/Makefile
tests/nouveau/Makefile
+   tests/etnaviv/Makefile
tests/util/Makefile
man/Makefile
libdrm.pc])
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 58feb12..4a499e4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -22,6 +22,10 @@ if HAVE_TEGRA
 SUBDIRS += tegra
 endif

+if HAVE_ETNAVIV
+SUBDIRS += etnaviv
+endif
+
 AM_CFLAGS = \
$(WARN_CFLAGS)\
-I $(top_srcdir)/include/drm \
diff --git a/tests/etnaviv/Makefile.am b/tests/etnaviv/Makefile.am
new file mode 100644
index 000..0631864
--- /dev/null
+++ b/tests/etnaviv/Makefile.am
@@ -0,0 +1,41 @@
+AM_CFLAGS = \
+   -I $(top_srcdir)/include/drm \
+   -I $(top_srcdir)/etnaviv \
+   -I $(top_srcdir)
+
+if HAVE_INSTALL_TESTS
+bin_PROGRAMS = \
+   etnaviv_2d_test \
+   etnaviv_cmd_stream_test \
+   etnaviv_bo_cache_test
+else
+noinst_PROGRAMS = \
+   etnaviv_2d_test \
+   etnaviv_cmd_stream_test \
+   etnaviv_bo_cache_test
+endif
+
+etnaviv_2d_test_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_2d_test_SOURCES = \
+   cmdstream.xml.h \
+   etnaviv_2d_test.c \
+   state.xml.h \
+   state_2d.xml.h \
+   write_bmp.c \
+   write_bmp.h
+
+etnaviv_cmd_stream_test_LDADD = \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_cmd_stream_test_SOURCES = \
+   etnaviv_cmd_stream_test.c
+
+etnaviv_bo_cache_test_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_bo_cache_test_SOURCES = \
+   etnaviv_bo_cache_test.c
diff --git a/tests/etnaviv/cmdstream.xml.h b/tests/etnaviv/cmdstream.xml.h
new file mode 100644
index 000..109285c
--- /dev/null
+++ b/tests/etnaviv/cmdstream.xml.h
@@ -0,0 +1,242 @@
+#ifndef CMDSTREAM_XML
+#define CMDSTREAM_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://0x04.net/cgit/index.cgi/rules-ng-ng
+git clone git://0x04.net/rules-ng-ng
+
+The rules-ng-ng source files this header was generated from are:
+- cmdstream.xml (  12621 bytes, from 2016-09-06 14:44:16)
+- copyright.xml (   1597 bytes, from 2016-09-06 14:44:16)
+- common.xml(  20583 bytes, from 2016-09-06 14:14:12)
+
+Copyright (C) 2012-2016 by the following authors:
+- Wladimir J. van der Laan 
+- Christian Gmeiner 
+- Lucas Stach 
+- Russell King 
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sub license,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the 

[PATCH v2 1/2] libdrm: add etnaviv drm support

2016-09-06 Thread Christian Gmeiner
From: The etnaviv authors 

Add the libdrm_etnaviv helper library to encapsulate etnaviv-specific 
interfaces to the DRM.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
---
 .gitignore   |   1 +
 Makefile.am  |   6 +
 configure.ac |  16 ++
 etnaviv/Android.mk   |  18 +++
 etnaviv/Makefile.am  |  26 
 etnaviv/Makefile.sources |  12 ++
 etnaviv/etnaviv-symbol-check |  45 ++
 etnaviv/etnaviv_bo.c | 347 +++
 etnaviv/etnaviv_bo_cache.c   | 196 
 etnaviv/etnaviv_cmd_stream.c | 243 ++
 etnaviv/etnaviv_device.c |  96 
 etnaviv/etnaviv_drm.h| 233 +
 etnaviv/etnaviv_drmif.h  | 188 +++
 etnaviv/etnaviv_gpu.c| 175 ++
 etnaviv/etnaviv_pipe.c   |  78 ++
 etnaviv/etnaviv_priv.h   | 199 +
 etnaviv/libdrm_etnaviv.pc.in |  11 ++
 17 files changed, 1890 insertions(+)
 create mode 100644 etnaviv/Android.mk
 create mode 100644 etnaviv/Makefile.am
 create mode 100644 etnaviv/Makefile.sources
 create mode 100755 etnaviv/etnaviv-symbol-check
 create mode 100644 etnaviv/etnaviv_bo.c
 create mode 100644 etnaviv/etnaviv_bo_cache.c
 create mode 100644 etnaviv/etnaviv_cmd_stream.c
 create mode 100644 etnaviv/etnaviv_device.c
 create mode 100644 etnaviv/etnaviv_drm.h
 create mode 100644 etnaviv/etnaviv_drmif.h
 create mode 100644 etnaviv/etnaviv_gpu.c
 create mode 100644 etnaviv/etnaviv_pipe.c
 create mode 100644 etnaviv/etnaviv_priv.h
 create mode 100644 etnaviv/libdrm_etnaviv.pc.in

diff --git a/.gitignore b/.gitignore
index a44566f..3226b3a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -57,6 +57,7 @@ libdrm_exynos.pc
 libdrm_freedreno.pc
 libdrm_amdgpu.pc
 libdrm_vc4.pc
+libdrm_etnaviv.pc
 libkms.pc
 libtool
 ltmain.sh
diff --git a/Makefile.am b/Makefile.am
index 2ceb352..630edc4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -36,6 +36,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-freedreno \
--enable-freedreno-kgsl\
--enable-tegra-experimental-api \
+   --enable-etnaviv-experimental-api \
--enable-install-test-programs \
--enable-cairo-tests \
--enable-manpages \
@@ -84,6 +85,10 @@ if HAVE_VC4
 VC4_SUBDIR = vc4
 endif

+if HAVE_ETNAVIV
+ETNAVIV_SUBDIR = etnaviv
+endif
+
 if BUILD_MANPAGES
 if HAVE_MANPAGES_STYLESHEET
 MAN_SUBDIR = man
@@ -102,6 +107,7 @@ SUBDIRS = \
$(FREEDRENO_SUBDIR) \
$(TEGRA_SUBDIR) \
$(VC4_SUBDIR) \
+   $(ETNAVIV_SUBDIR) \
tests \
$(MAN_SUBDIR)

diff --git a/configure.ac b/configure.ac
index e3048c7..64f3e6c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,11 @@ AC_ARG_ENABLE(vc4,
  [Enable support for vc4's API (default: auto, enabled on arm)]),
  [VC4=$enableval], [VC4=auto])

+AC_ARG_ENABLE(etnaviv-experimental-api,
+ AS_HELP_STRING([--enable-etnaviv-experimental-api],
+ [Enable support for etnaviv's experimental API (default: 
disabled)]),
+ [ETNAVIV=$enableval], [ETNAVIV=no])
+
 AC_ARG_ENABLE(install-test-programs,
  AS_HELP_STRING([--enable-install-test-programs],
  [Install test programs (default: no)]),
@@ -274,6 +279,9 @@ if test "x$drm_cv_atomic_primitives" = "xnone"; then

LIBDRM_ATOMICS_NOT_FOUND_MSG($TEGRA, tegra, NVIDIA Tegra, 
tegra-experimental-api)
TEGRA=no
+
+   LIBDRM_ATOMICS_NOT_FOUND_MSG($ETNAVIV, etnaviv, Vivante, 
etnaviv-experimental-api)
+   ETNAVIV=no
 else
if test "x$INTEL" = xauto; then
case $host_cpu in
@@ -413,6 +421,11 @@ if test "x$VC4" = xyes; then
AC_DEFINE(HAVE_VC4, 1, [Have VC4 support])
 fi

+AM_CONDITIONAL(HAVE_ETNAVIV, [test "x$ETNAVIV" = xyes])
+if test "x$ETNAVIV" = xyes; then
+   AC_DEFINE(HAVE_ETNAVIV, 1, [Have etnaviv support])
+fi
+
 AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes])
 if test "x$INSTALL_TESTS" = xyes; then
AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs])
@@ -524,6 +537,8 @@ AC_CONFIG_FILES([
tegra/libdrm_tegra.pc
vc4/Makefile
vc4/libdrm_vc4.pc
+   etnaviv/Makefile
+   etnaviv/libdrm_etnaviv.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -555,4 +570,5 @@ echo "  EXYNOS API $EXYNOS"
 echo "  Freedreno API  $FREEDRENO (kgsl: $FREEDRENO_KGSL)"
 echo "  Tegra API  $TEGRA"
 echo "  VC4 API$VC4"
+echo "  Etnaviv API$ETNAVIV"
 echo ""
diff --git a/etnaviv/Android.mk b/etnaviv/Android.mk
new file mode 100644
index 000..a3a2295
--- /dev/null
+++ b/etnaviv/Android.mk
@@ -0,0 +1,18 @@
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+# Import variables LIBDRM_ETNAVIV_FILES, LIBDRM_ETNAVIV_H_FILES
+include 

[PATCH v2 0/2] etnaviv_libdrm

2016-09-06 Thread Christian Gmeiner
As the original patchstack is now about 80 patches, I have choosen to
squash the patches together into two seperate parts. The libdrm_etnaviv
implementation and tests. All seperate patches can be found here:
https://github.com/austriancoder/libdrm/tree/master

As this work is a collaborative effort of Lucas Stack and myself all of
those patches have a fictive author, but our signoff.

The current state of the gallium driver can be found here:
https://github.com/etnaviv/mesa/tree/12.0_etnaviv

Happy reviewing!

Christian

Changes from v1:
  - remove not needed AUTOMAKE_OPTIONS from Makefile.am
  - set shared library version to 1.0.0
  - fix bad comment in etnaviv-symbol-check
  - remove of a dead comment line
  - correct VIV_FEATURES_WORD_COUNT define
  - use generated file from headers_install
  - use separate labels and drop all the if checks in tests code
  - update header files generated by rnndb
  - remove some empty lines with tabs

The etnaviv authors (2):
  libdrm: add etnaviv drm support
  libdrm: add etnaviv tests

 .gitignore  |4 +
 Makefile.am |6 +
 configure.ac|   17 +
 etnaviv/Android.mk  |   18 +
 etnaviv/Makefile.am |   26 +
 etnaviv/Makefile.sources|   12 +
 etnaviv/etnaviv-symbol-check|   45 +
 etnaviv/etnaviv_bo.c|  347 +++
 etnaviv/etnaviv_bo_cache.c  |  196 
 etnaviv/etnaviv_cmd_stream.c|  243 +
 etnaviv/etnaviv_device.c|   96 ++
 etnaviv/etnaviv_drm.h   |  233 +
 etnaviv/etnaviv_drmif.h |  188 
 etnaviv/etnaviv_gpu.c   |  175 
 etnaviv/etnaviv_pipe.c  |   78 ++
 etnaviv/etnaviv_priv.h  |  199 
 etnaviv/libdrm_etnaviv.pc.in|   11 +
 tests/Makefile.am   |4 +
 tests/etnaviv/Makefile.am   |   41 +
 tests/etnaviv/cmdstream.xml.h   |  242 +
 tests/etnaviv/etnaviv_2d_test.c |  240 +
 tests/etnaviv/etnaviv_bo_cache_test.c   |  121 +++
 tests/etnaviv/etnaviv_cmd_stream_test.c |  123 +++
 tests/etnaviv/state.xml.h   |  375 
 tests/etnaviv/state_2d.xml.h| 1497 +++
 tests/etnaviv/write_bmp.c   |  152 
 tests/etnaviv/write_bmp.h   |   34 +
 27 files changed, 4723 insertions(+)
 create mode 100644 etnaviv/Android.mk
 create mode 100644 etnaviv/Makefile.am
 create mode 100644 etnaviv/Makefile.sources
 create mode 100755 etnaviv/etnaviv-symbol-check
 create mode 100644 etnaviv/etnaviv_bo.c
 create mode 100644 etnaviv/etnaviv_bo_cache.c
 create mode 100644 etnaviv/etnaviv_cmd_stream.c
 create mode 100644 etnaviv/etnaviv_device.c
 create mode 100644 etnaviv/etnaviv_drm.h
 create mode 100644 etnaviv/etnaviv_drmif.h
 create mode 100644 etnaviv/etnaviv_gpu.c
 create mode 100644 etnaviv/etnaviv_pipe.c
 create mode 100644 etnaviv/etnaviv_priv.h
 create mode 100644 etnaviv/libdrm_etnaviv.pc.in
 create mode 100644 tests/etnaviv/Makefile.am
 create mode 100644 tests/etnaviv/cmdstream.xml.h
 create mode 100644 tests/etnaviv/etnaviv_2d_test.c
 create mode 100644 tests/etnaviv/etnaviv_bo_cache_test.c
 create mode 100644 tests/etnaviv/etnaviv_cmd_stream_test.c
 create mode 100644 tests/etnaviv/state.xml.h
 create mode 100644 tests/etnaviv/state_2d.xml.h
 create mode 100644 tests/etnaviv/write_bmp.c
 create mode 100644 tests/etnaviv/write_bmp.h

-- 
2.7.4



[Bug 100871] radeon fails to initialize one DisplayPort monitor

2016-09-06 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100871

--- Comment #16 from Reg  ---
Update: Regarding c14 (comment 14) about the ./display-on.sh. Even though
running this script can turn the display on that was erroneously off during
boot the display will turn itself back off after a few seconds or so so it's
not a usable workaround. I guess there is some status flag during boot in the
kernel that ultimately can't be changed or overridden that eventually reasserts
itself.

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


[PATCH 2/2] libdrm: add etnaviv tests

2016-09-06 Thread Christian Gmeiner
Hi Emil,

again thanks for the review.


2016-08-30 15:15 GMT+02:00 Emil Velikov :
> On 30 August 2016 at 10:08, Daniel Vetter  wrote:
>> On Tue, Aug 30, 2016 at 09:14:51AM +0200, Christian Gmeiner wrote:
>>> From: The etnaviv authors 
>>>
>>> This adds the following basic unit tests:
>>>
>>> - etnaviv_2d_test
>>>   Let the 2D core render a defined pattern into a bo
>>>   and store it as bmp.
>>>
>>> - etnaviv_bo_cache_test
>>>   Basic tests to validate the bo-cache behavior.
>>>
>>> - etnaviv_cmd_stream_test
>>>   Tests for the etna_cmd_stream API.
>>
>> igt (now at a new location at
>> https://cgit.freedesktop.org/drm/igt-gpu-tools/) would be a nice place for
>> these I think, if you want to participate there. vc4 has tests in there,
>> and collabora is porting a lot of the kms tests to be generic (so that
>> they can be run on any kms driver). Then you could just run those tests on
>> any driver and have a reasonable assurance you didn't break the world.
>>
> Having things in IGT might be better indeed. For the moment it might
> be better to land this as-is and move things in due time while add new
> tests directly in IGT ?
>
> Other than that - a couple of trivial questions/suggestions. Similar
> to the patch 1/2 ones - can be done as follow-up if needed.
>

Will send a v2 soon.

>>> --- /dev/null
>>> +++ b/tests/etnaviv/cmdstream.xml.h
>
>>> +The rules-ng-ng source files this header was generated from are:
>>> +- /home/orion/projects/etna_viv/rnndb/cmdstream.xml (  12589 bytes, from 
>>> 2013-09-01 10:53:22)
>>> +- /home/orion/projects/etna_viv/rnndb/common.xml(  18379 bytes, from 
>>> 2014-01-27 15:58:05)
> Always wondered about this - can we fix rnn to not print the full path
> but just files or rnndb/filename.xml ?
>
>>> +Copyright (C) 2013
> There is something funny here - currently we're not 2013 and the
> copyright holders are missing. Guess something went bonkers in rnn ?
>

Good catch - fixed in the source repo and will be corrected in v2.

>>> +int main(int argc, char *argv[])
>>> +{
>
>>> +fail:
>>> + if (stream)
>>> + etna_cmd_stream_del(stream);
>>> +
>>> + if (pipe)
>>> + etna_pipe_del(pipe);
>>> +
>>> + if (gpu)
>>> + etna_gpu_del(gpu);
>>> +
>>> + if (dev)
>>> + etna_device_del(dev);
>>> +
>>> + close(fd);
>>> +
> Feel free to ignore: you can use separate labels and drop all the if
> checks. Also s/fail/out/ since this is not an error path.
> Same comment goes the whole patch.
>

Sure why not.

thanks
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner


[PATCH 2/2] libdrm: add etnaviv tests

2016-09-06 Thread Christian Gmeiner
Hi Daniel,


2016-08-30 11:08 GMT+02:00 Daniel Vetter :
> On Tue, Aug 30, 2016 at 09:14:51AM +0200, Christian Gmeiner wrote:
>> From: The etnaviv authors 
>>
>> This adds the following basic unit tests:
>>
>> - etnaviv_2d_test
>>   Let the 2D core render a defined pattern into a bo
>>   and store it as bmp.
>>
>> - etnaviv_bo_cache_test
>>   Basic tests to validate the bo-cache behavior.
>>
>> - etnaviv_cmd_stream_test
>>   Tests for the etna_cmd_stream API.
>
> igt (now at a new location at
> https://cgit.freedesktop.org/drm/igt-gpu-tools/) would be a nice place for
> these I think, if you want to participate there. vc4 has tests in there,
> and collabora is porting a lot of the kms tests to be generic (so that
> they can be run on any kms driver). Then you could just run those tests on
> any driver and have a reasonable assurance you didn't break the world.
>
> But up to you really.

I will have a look at igt and see what can be done for etnaviv but for the
the moment I want to land the libdrm changes.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner


[PATCH 8/9] drm: Unify handling of blob and object properties

2016-09-06 Thread Ying Liu
On Mon, Aug 29, 2016 at 4:27 PM, Daniel Vetter  
wrote:
> They work exactly the same now, after the refcounting unification a bit
> ago. The only reason they're distinct is backwards compat with existing
> userspace.
>
> Cc: Daniel Stone 
> Reviewed-by: Archit Taneja 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_property.c | 23 +--
>  1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 162cc9032ae5..b5521f705b1c 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -911,20 +911,8 @@ bool drm_property_change_valid_get(struct drm_property 
> *property,
> for (i = 0; i < property->num_values; i++)
> valid_mask |= (1ULL << property->values[i]);
> return !(value & ~valid_mask);
> -   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
> -   struct drm_property_blob *blob;
> -
> -   if (value == 0)
> -   return true;
> -
> -   blob = drm_property_lookup_blob(property->dev, value);

It looks this patch would cause a NULL pointer dereference when we
run kms_atomic test.
Handing property->values[0] over to __drm_mode_object_find() for
blob property seems to be questionable.

Regards,
Liu Ying

> -   if (blob) {
> -   *ref = >base;
> -   return true;
> -   } else {
> -   return false;
> -   }
> -   } else if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> +   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB) ||
> +  drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> /* a zero value for an object property translates to null: */
> if (value == 0)
> return true;
> @@ -941,13 +929,12 @@ bool drm_property_change_valid_get(struct drm_property 
> *property,
>  }
>
>  void drm_property_change_valid_put(struct drm_property *property,
> -   struct drm_mode_object *ref)
> +  struct drm_mode_object *ref)
>  {
> if (!ref)
> return;
>
> -   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> +   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT) ||
> +   drm_property_type_is(property, DRM_MODE_PROP_BLOB))
> drm_mode_object_unreference(ref);
> -   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
> -   drm_property_unreference_blob(obj_to_blob(ref));
>  }
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] gpu/drm: fix signed integer overflow

2016-09-06 Thread Xie XiuQi
Use 1UL for unsigned long, or we'll meet a overflow issue with UBSAN.

[   15.589489] UBSAN: Undefined behaviour in 
drivers/gpu/drm/drm_hashtab.c:145:35
[   15.589500] signed integer overflow:
[   15.58] -2147483648 - 1 cannot be represented in type 'int'
[   15.590434] CPU: 2 PID: 294 Comm: plymouthd Not tainted 
3.10.0-327.28.3.el7.x86_64 #1
[   15.590653] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 01/07/2011
[   15.591001]  11000670fe83 0d6b385e 88003387f3e0 
81ee3140
[   15.591028]  88003387f3f8 81ee31fd a032f460 
88003387f560
[   15.591044]  81ee46e2 002d0009 0001 
41b58ab3
[   15.591059] Call Trace:
[   15.591078]  [] dump_stack+0x1e/0x20
[   15.591093]  [] ubsan_epilogue+0x12/0x55
[   15.591109]  [] handle_overflow+0x1ba/0x215
[   15.591126]  [] ? 
__ubsan_handle_negate_overflow+0x162/0x162
[   15.591146]  [] ? print_context_stack+0x9c/0x160
[   15.591163]  [] ? dump_trace+0x252/0x750
[   15.591181]  [] ? __list_add+0x93/0x160
[   15.591197]  [] __ubsan_handle_sub_overflow+0x2a/0x31
[   15.591261]  [] drm_ht_just_insert_please+0x1e0/0x200 [drm]
[   15.591290]  [] ttm_base_object_init+0x10a/0x270 [ttm]
[   15.591316]  [] ttm_vt_lock+0x28c/0x3a0 [ttm]
[   15.591343]  [] ? ttm_write_lock+0x180/0x180 [ttm]
[   15.591362]  [] ? kasan_unpoison_shadow+0x36/0x50
[   15.591379]  [] ? kasan_unpoison_shadow+0x36/0x50
[   15.591396]  [] ? kasan_unpoison_shadow+0x36/0x50
[   15.591413]  [] ? kasan_unpoison_shadow+0x36/0x50
[   15.591442]  [] vmw_master_set+0x121/0x470 [vmwgfx]
[   15.591459]  [] ? __init_waitqueue_head+0x45/0x70
[   15.591487]  [] ? vmw_master_drop+0x310/0x310 [vmwgfx]
[   15.591535]  [] drm_open+0x92a/0xc00 [drm]
[   15.591563]  [] ? vmw_driver_open+0x170/0x170 [vmwgfx]
[   15.591610]  [] ? drm_poll+0xe0/0xe0 [drm]
[   15.591661]  [] drm_stub_open+0x224/0x330 [drm]
[   15.591711]  [] ? drm_minor_acquire+0x240/0x240 [drm]
[   15.591727]  [] chrdev_open+0x1fa/0x3f0
[   15.591742]  [] ? cdev_put+0x50/0x50
[   15.591761]  [] ? __fsnotify_parent+0x53/0x210
[   15.591778]  [] do_dentry_open+0x351/0x670
[   15.591792]  [] ? cdev_put+0x50/0x50
[   15.591807]  [] vfs_open+0xa2/0x170
[   15.591824]  [] do_last+0xccf/0x2c80
[   15.591842]  [] ? filename_create+0x320/0x320
[   15.591858]  [] ? path_init+0x1b9/0xa90
[   15.591875]  [] ? mountpoint_last+0x9a0/0x9a0
[   15.591894]  [] ? selinux_file_alloc_security+0xcf/0x130
[   15.591911]  [] path_openat+0x1e7/0xcc0
[   15.591927]  [] ? dump_trace+0x252/0x750
[   15.591943]  [] ? do_last+0x2c80/0x2c80
[   15.591959]  [] ? __list_add+0x93/0x160
[   15.591974]  [] ? save_stack_trace+0x7d/0xb0
[   15.591989]  [] do_filp_open+0xa4/0x160
[   15.592004]  [] ? user_path_mountpoint_at+0x50/0x50
[   15.592022]  [] ? __alloc_fd+0x175/0x300
[   15.592039]  [] do_sys_open+0x1b7/0x3f0
[   15.592054]  [] ? filp_open+0x80/0x80
[   15.592070]  [] SyS_open+0x32/0x40
[   15.592088]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Xie XiuQi 
---
 drivers/gpu/drm/drm_hashtab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 7b30b30..dae18e5 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -142,7 +142,7 @@ int drm_ht_just_insert_please(struct drm_open_hash *ht, 
struct drm_hash_item *it
  unsigned long add)
 {
int ret;
-   unsigned long mask = (1 << bits) - 1;
+   unsigned long mask = (1UL << bits) - 1;
unsigned long first, unshifted_key;

unshifted_key = hash_long(seed, bits);
-- 
1.8.3.1



[PATCH v2 9/9] ARM: sun8i: sina33: Enable display

2016-09-06 Thread Maxime Ripard
Enable the display pipeline with the associated 7" panel sold with the
SinA33.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fef6abc0a703..fa8024072025 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -61,6 +61,27 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   panel {
+   compatible = "netron-dy,e231732";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
 };

  {
@@ -207,6 +228,19 @@
regulator-name = "vcc-rtc";
 };

+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgb666_pins>;
+   status = "okay";
+};
+
+_out {
+   tcon0_out_panel: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
-- 
2.9.3



[PATCH v2 8/9] ARM: sun8i: a23/a33: Add RGB666 pins

2016-09-06 Thread Maxime Ripard
The LCD output needs to be muxed. Add the proper pinctrl node.

Signed-off-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 7246663bacdd..7ea6de12040e 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -302,6 +302,16 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   lcd_rgb666_pins: lcd-rgb666 at 0 {
+   allwinner,pins = "PD2", "PD3", "PD4", "PD5", 
"PD6", "PD7",
+"PD10", "PD11", "PD12", 
"PD13", "PD14", "PD15",
+"PD18", "PD19", "PD20", 
"PD21", "PD22", "PD23",
+"PD24", "PD25", "PD26", "PD27";
+   allwinner,function = "lcd0";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};

timer at 01c20c00 {
-- 
2.9.3



[PATCH v2 7/9] ARM: sun8i: a33: Add display pipeline

2016-09-06 Thread Maxime Ripard
Add all the needed blocks to the A33 DTSI.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 152 +++
 1 file changed, 152 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index f3d91d2c96ef..1d21d488cb3e 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -59,11 +59,53 @@
};
};

+   de: display-engine {
+   compatible = "allwinner,sun8i-a33-display-engine";
+   allwinner,pipelines = <>;
+   status = "disabled";
+   };
+
memory {
reg = <0x4000 0x8000>;
};

soc at 01c0 {
+   tcon0: lcd-controller at 01c0c000 {
+   compatible = "allwinner,sun8i-a33-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_LCD>,
+< CLK_LCD_CH0>;
+   clock-names = "ahb",
+ "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_LCD>;
+   reset-names = "lcd";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_drc0: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port at 1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
crypto: crypto-engine at 01c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
@@ -104,6 +146,116 @@
status = "disabled";
#phy-cells = <1>;
};
+
+   fe0: display-frontend at 01e0 {
+   compatible = "allwinner,sun8i-a33-display-frontend";
+   reg = <0x01e0 0x2>;
+   interrupts = ;
+   clocks = < CLK_BUS_DE_FE>, < CLK_DE_FE>,
+< CLK_DRAM_DE_FE>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = < RST_BUS_DE_FE>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   fe0_out: port at 1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   fe0_out_be0: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_in_fe0>;
+   };
+   };
+   };
+   };
+
+   be0: display-backend at 01e6 {
+   compatible = "allwinner,sun8i-a33-display-backend";
+   reg = <0x01e6 0x1>, <0x01e8 0x1000>;
+   reg-names = "be", "sat";
+   interrupts = ;
+   clocks = < CLK_BUS_DE_BE>, < CLK_DE_BE>,
+< CLK_DRAM_DE_BE>, < CLK_BUS_SAT>;
+   clock-names = "ahb", "mod",
+ "ram", "sat";
+   resets = < RST_BUS_DE_BE>, < RST_BUS_SAT>;
+   reset-names = "be", "sat";
+   assigned-clocks = < CLK_DE_BE>;
+   assigned-clock-rates = <3>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   be0_in: port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   

[PATCH v2 6/9] drm/panel: Add Netron DY E231732

2016-09-06 Thread Maxime Ripard
The E231732 is a 7" panel with a resolution of 800x480.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 85143d1b9b31..85e988b51fbe 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1136,6 +1136,29 @@ static const struct panel_desc nec_nl4827hc19_05b = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };

+static const struct drm_display_mode netron_dy_e231732_mode = {
+   .clock = 66000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 160,
+   .hsync_end = 1024 + 160 + 70,
+   .htotal = 1024 + 160 + 70 + 90,
+   .vdisplay = 600,
+   .vsync_start = 600 + 127,
+   .vsync_end = 600 + 127 + 20,
+   .vtotal = 600 + 127 + 20 + 3,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc netron_dy_e231732 = {
+   .modes = _dy_e231732_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 154,
+   .height = 87,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct display_timing okaya_rs800480t_7x0gp_timing = {
.pixelclock = { 3000, 3000, 4000 },
.hactive = { 800, 800, 800 },
@@ -1644,6 +1667,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
}, {
+   .compatible = "netron-dy,e231732",
+   .data = _dy_e231732,
+   }, {
.compatible = "starry,kr122ea0sra",
.data = _kr122ea0sra,
}, {
-- 
2.9.3



[PATCH v2 5/9] of: Add vendor prefix for Netron DY

2016-09-06 Thread Maxime Ripard
Netron DY is a brand of LCD panels found on SBCs and tablets.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa97d45a..9c1ab3c1132b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -176,6 +176,7 @@ nec NEC LCD Technologies, Ltd.
 neonodeNeonode Inc.
 netgearNETGEAR
 netlogic   Broadcom Corporation (formerly NetLogic Microsystems)
+netron-dy  Netron DY
 netxeonShenzhen Netxeon Technology CO., LTD
 newhaven   Newhaven Display International
 nintendo   Nintendo
-- 
2.9.3



[PATCH v2 4/9] drm/sun4i: Add a DRC driver

2016-09-06 Thread Maxime Ripard
The A33 pipeline also has a component called DRC. Even though its exact
features and programming model is not known (or documented), it needs to
be clocked for the pipeline to carry the video signal all the way.

Add a minimal driver for it that just claim the needed resources for the
pipeline to operate properly.

Signed-off-by: Maxime Ripard 
---
 .../bindings/display/sunxi/sun4i-drm.txt   |  24 +
 drivers/gpu/drm/sun4i/Makefile |   2 +-
 drivers/gpu/drm/sun4i/sun6i_drc.c  | 118 +
 3 files changed, 143 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d3529f72ca91..2b8a216790cb 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -51,6 +51,30 @@ Required properties:
   second the block connected to the TCON channel 1 (usually the TV
   encoder)

+DRC
+---
+
+The DRC (Dynamic Range Controller), found in the latest Allwinner SoCs
+(A31, A23, A33), allows to dynamically adjust pixel
+brightness/contrast based on histogram measurements for LCD content
+adaptive backlight control.
+
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun8i-a33-drc
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the DRC
+* ahb: the DRC interface clock
+* mod: the DRC module clock
+* ram: the DRC DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the DRC
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoints, the second one the outputs

 Display Engine Backend
 --
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 58cd55149827..d625a82a6e5f 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,5 +9,5 @@ sun4i-tcon-y += sun4i_dotclock.o

 obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
-
+obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c 
b/drivers/gpu/drm/sun4i/sun6i_drc.c
new file mode 100644
index ..bf6d846d8132
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright (C) 2016 Free Electrons
+ *
+ * Maxime Ripard 
+ *
+ * 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 
+
+struct sun6i_drc {
+   struct clk  *bus_clk;
+   struct clk  *mod_clk;
+   struct reset_control*reset;
+};
+
+static int sun6i_drc_bind(struct device *dev, struct device *master,
+void *data)
+{
+   struct sun6i_drc *drc;
+   int ret;
+
+   drc = devm_kzalloc(dev, sizeof(*drc), GFP_KERNEL);
+   if (!drc)
+   return -ENOMEM;
+   dev_set_drvdata(dev, drc);
+
+   drc->reset = devm_reset_control_get(dev, NULL);
+   if (IS_ERR(drc->reset)) {
+   dev_err(dev, "Couldn't get our reset line\n");
+   return PTR_ERR(drc->reset);
+   }
+
+   ret = reset_control_deassert(drc->reset);
+   if (ret) {
+   dev_err(dev, "Couldn't deassert our reset line\n");
+   return ret;
+   }
+
+   drc->bus_clk = devm_clk_get(dev, "ahb");
+   if (IS_ERR(drc->bus_clk)) {
+   dev_err(dev, "Couldn't get our bus clock\n");
+   ret = PTR_ERR(drc->bus_clk);
+   goto err_assert_reset;
+   }
+   clk_prepare_enable(drc->bus_clk);
+
+   drc->mod_clk = devm_clk_get(dev, "mod");
+   if (IS_ERR(drc->mod_clk)) {
+   dev_err(dev, "Couldn't get our mod clock\n");
+   ret = PTR_ERR(drc->mod_clk);
+   goto err_disable_bus_clk;
+   }
+   clk_prepare_enable(drc->mod_clk);
+
+   return 0;
+
+err_disable_bus_clk:
+   clk_disable_unprepare(drc->bus_clk);
+err_assert_reset:
+   reset_control_assert(drc->reset);
+   return ret;
+}
+
+static void sun6i_drc_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+   struct sun6i_drc *drc = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(drc->mod_clk);
+   clk_disable_unprepare(drc->bus_clk);
+  

[PATCH v2 3/9] drm/sun4i: backend: Handle the SAT

2016-09-06 Thread Maxime Ripard
The A33 has an block called SAT that is part of the backend that needs to
be clocked and out of reset to be able for the backend to operate properly.

Extend the binding to have the SAT resources listed, and claim them when
the backend probes.

Signed-off-by: Maxime Ripard 
---
 .../bindings/display/sunxi/sun4i-drm.txt   |  8 +++
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 60 ++
 drivers/gpu/drm/sun4i/sun4i_backend.h  |  3 ++
 3 files changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index bd3136a5cba5..d3529f72ca91 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -74,6 +74,14 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoints, the second one the output

+On the A33, some additional properties are required:
+  - reg needs to have an additional region corresponding to the SAT
+  - reg-names need to be set, with "be" and "sat"
+  - clocks and clock-names need to have a phandle to the SAT bus
+clocks, whose name will be "sat"
+  - resets and reset-names need to have a phandle to the SAT bus
+resets, whose name will be "sat"
+
 Display Engine Frontend
 ---

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 9bfd2e45fceb..91a702225ded 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -217,6 +217,51 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
 }
 EXPORT_SYMBOL(sun4i_backend_update_layer_buffer);

+static int sun4i_backend_init_sat(struct device *dev) {
+   struct sun4i_backend *backend = dev_get_drvdata(dev);
+   int ret;
+
+   backend->sat_reset = devm_reset_control_get(dev, "sat");
+   if (IS_ERR(backend->sat_reset)) {
+   dev_err(dev, "Couldn't get the SAT reset line\n");
+   return PTR_ERR(backend->sat_reset);
+   }
+
+   ret = reset_control_deassert(backend->sat_reset);
+   if (ret) {
+   dev_err(dev, "Couldn't deassert the SAT reset line\n");
+   return ret;
+   }
+
+   backend->sat_clk = devm_clk_get(dev, "sat");
+   if (IS_ERR(backend->sat_clk)) {
+   dev_err(dev, "Couldn't get our SAT clock\n");
+   ret = PTR_ERR(backend->sat_clk);
+   goto err_assert_reset;
+   }
+
+   ret = clk_prepare_enable(backend->sat_clk);
+   if (ret) {
+   dev_err(dev, "Couldn't enable the SAT clock\n");
+   return ret;
+   }
+
+   return 0;
+
+err_assert_reset:
+   reset_control_assert(backend->sat_reset);
+   return ret;
+}
+
+static int sun4i_backend_free_sat(struct device *dev) {
+   struct sun4i_backend *backend = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(backend->sat_clk);
+   reset_control_assert(backend->sat_reset);
+
+   return 0;
+}
+
 static struct regmap_config sun4i_backend_regmap_config = {
.reg_bits   = 32,
.val_bits   = 32,
@@ -291,6 +336,15 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
}
clk_prepare_enable(backend->ram_clk);

+   if (of_device_is_compatible(dev->of_node,
+   "allwinner,sun8i-a33-display-backend")) {
+   ret = sun4i_backend_init_sat(dev);
+   if (ret) {
+   dev_err(dev, "Couldn't init SAT resources\n");
+   goto err_disable_ram_clk;
+   }
+   }
+
/* Reset the registers */
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->regs, i, 0);
@@ -306,6 +360,8 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,

return 0;

+err_disable_ram_clk:
+   clk_disable_unprepare(backend->ram_clk);
 err_disable_mod_clk:
clk_disable_unprepare(backend->mod_clk);
 err_disable_bus_clk:
@@ -320,6 +376,10 @@ static void sun4i_backend_unbind(struct device *dev, 
struct device *master,
 {
struct sun4i_backend *backend = dev_get_drvdata(dev);

+   if (of_device_is_compatible(dev->of_node,
+   "allwinner,sun8i-a33-display-backend"))
+   sun4i_backend_free_sat(dev);
+
clk_disable_unprepare(backend->ram_clk);
clk_disable_unprepare(backend->mod_clk);
clk_disable_unprepare(backend->bus_clk);
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 7070bb3434e5..e00718627748 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -146,6 +146,9 @@ struct sun4i_backend {
struct clk  *bus_clk;

[PATCH v2 2/9] drm/sun4i: support A33 tcon

2016-09-06 Thread Maxime Ripard
The A33 has a significantly different pipeline, with components that differ
too.

Make sure we had compatible for them.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++-
 drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
 drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +---
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 +++-
 4 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index df8f4aeefe4c..bd3136a5cba5 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -26,7 +26,9 @@ TCON
 The TCON acts as a timing controller for RGB, LVDS and TV interfaces.

 Required properties:
- - compatible: value should be "allwinner,sun5i-a13-tcon".
+ - compatible: value must be either:
+   * allwinner,sun5i-a13-tcon
+   * allwinner,sun8i-a33-tcon
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
  - clocks: phandles to the clocks feeding the TCON. Three are needed:
@@ -59,6 +61,7 @@ system.
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun5i-a13-display-backend
+* allwinner,sun8i-a33-display-backend
   - reg: base address and size of the memory-mapped region.
   - clocks: phandles to the clocks feeding the frontend and backend
 * ahb: the backend interface clock
@@ -80,6 +83,7 @@ deinterlacing and color space conversion.
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun5i-a13-display-frontend
+* allwinner,sun8i-a33-display-frontend
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the frontend and backend
@@ -104,6 +108,7 @@ extra node.
 Required properties:
   - compatible: value must be one of:
 * allwinner,sun5i-a13-display-engine
+* allwinner,sun8i-a33-display-engine

   - allwinner,pipelines: list of phandle to the display engine
 frontends available.
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 3ab560450a82..9bfd2e45fceb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -345,6 +345,7 @@ static int sun4i_backend_remove(struct platform_device 
*pdev)

 static const struct of_device_id sun4i_backend_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-backend" },
+   { .compatible = "allwinner,sun8i-a33-display-backend" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 942f62e2441c..c4d03c1b6db8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -199,13 +199,14 @@ static const struct component_master_ops 
sun4i_drv_master_ops = {

 static bool sun4i_drv_node_is_frontend(struct device_node *node)
 {
-   return of_device_is_compatible(node,
-  "allwinner,sun5i-a13-display-frontend");
+   return of_device_is_compatible(node, 
"allwinner,sun5i-a13-display-frontend") ||
+   of_device_is_compatible(node, 
"allwinner,sun8i-a33-display-frontend");
 }

 static bool sun4i_drv_node_is_tcon(struct device_node *node)
 {
-   return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon");
+   return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
+   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
 }

 static int compare_of(struct device *dev, void *data)
@@ -320,6 +321,7 @@ static int sun4i_drv_remove(struct platform_device *pdev)

 static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-engine" },
+   { .compatible = "allwinner,sun8i-a33-display-engine" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index fde6af1230d2..cadacb517f95 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -488,8 +488,13 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
tcon->drm = drm;
tcon->dev = dev;

-   if (of_device_is_compatible(dev->of_node, "allwinner,sun5i-a13-tcon"))
+   if (of_device_is_compatible(dev->of_node, "allwinner,sun5i-a13-tcon")) {
tcon->has_mux = true;
+   tcon->has_channel_1 = true;
+   } else {
+   tcon->has_mux = false;
+   tcon->has_channel_1 = false;
+   }

tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
if (IS_ERR(tcon->lcd_rst)) {
@@ -585,6 +590,7 

[PATCH v2 1/9] drm/sun4i: support TCONs without channel 1

2016-09-06 Thread Maxime Ripard
Some Allwinner SoCs, such as the A33, have a variation of the TCON that
doesn't have a second channel (or it is not wired to anything).

Make sure we can handle that case.

Signed-off-by: Maxime Ripard 
Acked-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 34 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 9180e7e7b551..fde6af1230d2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -59,11 +59,13 @@ void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, 
int channel)
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
   SUN4I_TCON0_CTL_TCON_ENABLE, 0);
clk_disable_unprepare(tcon->dclk);
-   } else if (channel == 1) {
-   regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
-  SUN4I_TCON1_CTL_TCON_ENABLE, 0);
-   clk_disable_unprepare(tcon->sclk1);
+   return;
}
+
+   WARN_ON(!tcon->has_channel_1);
+   regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
+  SUN4I_TCON1_CTL_TCON_ENABLE, 0);
+   clk_disable_unprepare(tcon->sclk1);
 }
 EXPORT_SYMBOL(sun4i_tcon_channel_disable);

@@ -75,12 +77,14 @@ void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int 
channel)
   SUN4I_TCON0_CTL_TCON_ENABLE,
   SUN4I_TCON0_CTL_TCON_ENABLE);
clk_prepare_enable(tcon->dclk);
-   } else if (channel == 1) {
-   regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
-  SUN4I_TCON1_CTL_TCON_ENABLE,
-  SUN4I_TCON1_CTL_TCON_ENABLE);
-   clk_prepare_enable(tcon->sclk1);
+   return;
}
+
+   WARN_ON(!tcon->has_channel_1);
+   regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
+  SUN4I_TCON1_CTL_TCON_ENABLE,
+  SUN4I_TCON1_CTL_TCON_ENABLE);
+   clk_prepare_enable(tcon->sclk1);
 }
 EXPORT_SYMBOL(sun4i_tcon_channel_enable);

@@ -198,6 +202,8 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val;

+   WARN_ON(!tcon->has_channel_1);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
@@ -321,10 +327,12 @@ static int sun4i_tcon_init_clocks(struct device *dev,
return PTR_ERR(tcon->sclk0);
}

-   tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
-   if (IS_ERR(tcon->sclk1)) {
-   dev_err(dev, "Couldn't get the TCON channel 1 clock\n");
-   return PTR_ERR(tcon->sclk1);
+   if (tcon->has_channel_1) {
+   tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
+   if (IS_ERR(tcon->sclk1)) {
+   dev_err(dev, "Couldn't get the TCON channel 1 clock\n");
+   return PTR_ERR(tcon->sclk1);
+   }
}

return sun4i_dclk_create(dev, tcon);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 100bfa093277..12bd48925f4d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -164,6 +164,8 @@ struct sun4i_tcon {
boolhas_mux;

struct drm_panel*panel;
+
+   boolhas_channel_1;
 };

 struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
-- 
2.9.3



[PATCH v2 0/9] drm/sun4i: Introduce A33 display driver

2016-09-06 Thread Maxime Ripard
Hi everyone,

This serie introduces the support in the sun4i-drm driver for the A33.

Beside the new IPs and special cases for the A33 new IPs, there's
nothing really outstanding, and is now at feature parity with the A13.

This serie is based on my A33 CCU patches posted earlier today here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/453208.html

Let me know what you think,
Maxime

Changes from v1:
  - Changed the TCON pins label
  - Changed the TCON compatible as it's different from A23's
  - Merged the SAT into the backend, as it really is part of the same
block in hardware.
  - Reworded the DRC bindings description
  - Added the backend interrupt to the DT
  - Changed the name of the LCD panel to the actual brand and model
found on the ribbon

Maxime Ripard (9):
  drm/sun4i: support TCONs without channel 1
  drm/sun4i: support A33 tcon
  drm/sun4i: backend: Handle the SAT
  drm/sun4i: Add a DRC driver
  of: Add vendor prefix for Netron DY
  drm/panel: Add Netron DY E231732
  ARM: sun8i: a33: Add display pipeline
  ARM: sun8i: a23/a33: Add RGB666 pins
  ARM: sun8i: sina33: Enable display

 .../bindings/display/sunxi/sun4i-drm.txt   |  39 +-
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  10 ++
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts |  34 +
 arch/arm/boot/dts/sun8i-a33.dtsi   | 152 +
 drivers/gpu/drm/panel/panel-simple.c   |  26 
 drivers/gpu/drm/sun4i/Makefile |   2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c  |  61 +
 drivers/gpu/drm/sun4i/sun4i_backend.h  |   3 +
 drivers/gpu/drm/sun4i/sun4i_drv.c  |   8 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  42 --
 drivers/gpu/drm/sun4i/sun4i_tcon.h |   2 +
 drivers/gpu/drm/sun4i/sun6i_drc.c  | 118 
 13 files changed, 479 insertions(+), 19 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c

-- 
2.9.3



[PATCH 4/7] drm/panel: Add Sinlinx SinA33 7" panel

2016-09-06 Thread Maxime Ripard
On Tue, Sep 06, 2016 at 11:12:24AM +0200, Thierry Reding wrote:
> On Mon, Sep 05, 2016 at 10:02:48PM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Sep 05, 2016 at 01:03:03AM +0800, Icenowy Zheng wrote:
> > > Hi Everyone,
> > > 
> > > 01.09.2016, 23:40, "Maxime Ripard" :
> > > >  The SinA33 has an unidentified panel. Add the timings for it under a 
> > > > new
> > > >  compatible.
> > > 
> > > 
> > > 
> > > Excuse me...
> > > I will ask a question which is not fully related to the patch here...
> > > If I want to add a generic panel for Q8 tablets, what should it be called?
> > > "allwinner,q8-lcd-panel-800x480"?
> > 
> > I guess it's more of a question for Thierry, but it seems like the
> > trend is to put the diagonal rather than the resolution in the
> > compatibles.
> 
> Compatible strings should contain the model number of the panel. There
> is no such thing as a "generic panel for Q8 tablets".
> 
> Also, how is it that these panels are unidentified? Has nobody tried to
> open them up and look at the panel to find a model number?

It is not always possible without breaking the device apart. And I can
understand not a lot of people want to do that.

But on that particular patch, I had a bunch of spare ones, and ended
up doing just that. The reference is from an unknown brand, but at
least the part number shows up on Google, I'll use that.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- 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/20160906/dcec7aca/attachment.sig>


[PATCH 2/2 v3] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

2016-09-06 Thread John Stultz
From: Srinivas Kandagatla 

This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 5eebd15..6798ecf 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -29,6 +29,7 @@ static const struct reg_sequence 
adv7533_cec_fixed_registers[] = {
{ 0x17, 0xd0 },
{ 0x24, 0x20 },
{ 0x57, 0x11 },
+   { 0x05, 0xc8 },
 };

 static const struct regmap_config adv7533_cec_regmap_config = {
-- 
1.9.1



[PATCH 1/2 v3] drm/bridge: adv7511: Add Audio support.

2016-09-06 Thread John Stultz
This patch adds support to Audio for both adv7511 and adv7533
bridge chips.

This patch was originally from [1] by Lars-Peter Clausen 
and was adapted by Archit Taneja  and
Srinivas Kandagatla .

Then I heavily reworked it to use the hdmi-codec driver. And also
folded in some audio packet initialization done by Andy Green
. So credit to them, but blame to me.

[1] 
https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
v3:
* Allowed audio support to be configured in or out, as suggested by Laurent
* Minor cleanups suggested by Laurent
* Folded in Andy's audio packet initialization patch, as suggested by Archit

 drivers/gpu/drm/bridge/adv7511/Kconfig |   9 ++
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   4 +
 5 files changed, 243 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index d2b0499..b303ad1 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -3,9 +3,18 @@ config DRM_I2C_ADV7511
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.

+config DRM_I2C_ADV7511_AUDIO
+   tristate "ADV7511 HDMI Audio driver"
+   depends on DRM_I2C_ADV7511 && SND_SOC
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the ADV7511 HDMI Audio interface. This is used in
+ conjunction with the AV7511  HDMI driver.
+
 config DRM_I2C_ADV7533
bool "ADV7533 encoder"
depends on DRM_I2C_ADV7511
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 9019327..5ba6755 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,3 +1,4 @@
 adv7511-y := adv7511_drv.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..992d76c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -309,6 +309,8 @@ struct adv7511 {
struct drm_display_mode curr_mode;

unsigned int f_tmds;
+   unsigned int f_audio;
+   unsigned int audio_source;

unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -334,6 +336,7 @@ struct adv7511 {
bool use_timing_gen;

enum adv7511_type type;
+   struct platform_device *audio_pdev;
 };

 #ifdef CONFIG_DRM_I2C_ADV7533
@@ -389,4 +392,17 @@ static inline int adv7533_parse_dt(struct device_node *np, 
struct adv7511 *adv)
 }
 #endif

+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
+void adv7511_audio_exit(struct adv7511 *adv7511);
+#else /*CONFIG_DRM_I2C_ADV7511_AUDIO */
+static inline int adv7511_audio_init(struct device *dev, struct adv7511 
*adv7511)
+{
+   return 0;
+}
+static inline void adv7511_audio_exit(struct adv7511 *adv7511)
+{
+}
+#endif /* CONFIG_DRM_I2C_ADV7511_AUDIO */
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
new file mode 100644
index 000..5ce29a5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -0,0 +1,213 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ * Copyright (c) 2016, Linaro Limited
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "adv7511.h"
+
+static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
+  unsigned int *cts, unsigned int *n)
+{
+   switch (fs) {
+   case 32000:
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   *n = 6144;
+   break;
+   }
+
+   *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
+}
+
+static int adv7511_update_cts_n(struct adv7511 *adv7511)
+{
+   unsigned int cts = 0;
+   unsigned int n = 0;
+
+   

[PATCH 0/2 v3] Audio support for adv7511 hdmi bridge

2016-09-06 Thread John Stultz
This is another swing at getting the adv7511 hdmi bridge
audio support reviewed.

I've taken the core audio work done by Lars-Peter Clausen, and
adapted by Srinivas Kandagatla and Archit Taneja, and tried to
rework it to use the hdmi-codec sound driver.

This patchset, along with the i2s driver and dts changes allows
HDMI audio to work on the HiKey board.

I'd really appreciate any thoughts or feedback.

New in v3:
* Dropped unnecessary first patch
* Made a few clenaups suggested by Laurent
* Made audio a config time option, as suggested by Laurent
* Folded in Andy Green's audio packet initialization patch

thanks
-john

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org

John Stultz (1):
  drm/bridge: adv7511: Add Audio support.

Srinivas Kandagatla (1):
  drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

 drivers/gpu/drm/bridge/adv7511/Kconfig |   9 ++
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   4 +
 drivers/gpu/drm/bridge/adv7511/adv7533.c   |   1 +
 6 files changed, 244 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

-- 
1.9.1



[PATCH] drm/atomic: mode_set encoders when routing changes

2016-09-06 Thread Brian Starkey
crtc_set_mode() only checks if the CRTC mode has changed when deciding
whether encoders require a mode_set. This is insufficient when the CRTC
mode isn't changed but a new encoder is added to it, leading to encoders
never getting mode_set.

Fix this by also checking that a connector's CRTC and encoder have not
changed before skipping its encoder's mode_set.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic_helper.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 20be86d..206fba1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -876,7 +876,9 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)
mode = _crtc_state->mode;
adjusted_mode = _crtc_state->adjusted_mode;

-   if (!new_crtc_state->mode_changed)
+   if (!new_crtc_state->mode_changed &&
+   connector->state->crtc == old_conn_state->crtc &&
+   connector->state->best_encoder == 
old_conn_state->best_encoder)
continue;

DRM_DEBUG_ATOMIC("modeset on [ENCODER:%d:%s]\n",
-- 
1.7.9.5



[PATCH, RESEND] drm: exynos: avoid unused function warning

2016-09-06 Thread Andrzej Hajda
On 09/06/2016 03:30 PM, Arnd Bergmann wrote:
> When CONFIG_PM is not set, we get a warning about an unused function:
>
> drivers/gpu/drm/exynos/exynos_drm_gsc.c:1219:12: error: 'gsc_clk_ctrl' 
> defined but not used [-Werror=unused-function]
>  static int gsc_clk_ctrl(struct gsc_context *ctx, bool enable)
> ^~~~
>
> This removes the two #ifdef checks in this file and instead marks the
> functions as __maybe_unused, which is a more reliable way of doing the
> same, allowing better build coverage and avoiding the warning above.
>
> Signed-off-by: Arnd Bergmann 
Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej


[linux-sunxi] [PATCH 3/7] drm/sun4i: Add SAT and DRC drivers

2016-09-06 Thread Maxime Ripard
Hi Peter,

On Sun, Sep 04, 2016 at 10:03:06PM +0200, Peter Korsgaard wrote:
> >>>>> "Maxime" == Maxime Ripard  writes:
> 
> Hi,
> 
>  > The A33 pipeline also has some new components called SAT and DRC. Even
>  > though their exact features and programming model is not known (or
>  > documented), they need to be clocked for the pipeline to carry the video
>  > signal all the way.
> 
>  > Add minimal drivers for those that just claim the needed resources for the
>  > pipeline to operate properly.
> 
>  > Signed-off-by: Maxime Ripard 
>  > ---
>  >  .../bindings/display/sunxi/sun4i-drm.txt   |  37 +++
>  >  drivers/gpu/drm/sun4i/Makefile |   3 +-
>  >  drivers/gpu/drm/sun4i/sun6i_drc.c  | 117 
> +
>  >  drivers/gpu/drm/sun4i/sun8i_sat.c  | 105 
> ++
>  >  4 files changed, 261 insertions(+), 1 deletion(-)
>  >  create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c
>  >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_sat.c
> 
>  > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>  > index d467ea93ac08..87c3c8dd34cb 100644
>  > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>  > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>  > @@ -51,6 +51,43 @@ Required properties:
>  >second the block connected to the TCON channel 1 (usually the TV
>  >encoder)
>  
>  > +SAT
>  > +---
>  > +
>  > +The SAT, found in the A33, allows to do some color correction.
>  > +
>  > +Required properties:
>  > +  - compatible: value must be one of:
>  > +* allwinner,sun8i-a33-sat
>  > +  - reg: base address and size of the memory-mapped region.
>  > +  - clock: phandles to bus clock feeding the SAT
>  > +  - resets: phandles to the reset line driving the SAT
>  > +
>  > +- ports: A ports node with endpoint definitions as defined in
>  > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
>  > +  first port should be the input endpoints, the second one the outputs
>  > +
>  > +DRC
>  > +---
>  > +
>  > +The DRC, found in the latest Allwinner SoCs (A31, A23, A33), allows to
>  > +do some backlight control to enhance the power consumption.
> 
> 'Enhance the power consumption'? That doesn't sound like something you
> would want ;) Presumably it is something to allow you to save power by
> dynamically adjusting LCD backlight and pixel brightness/contrast
> depending on screen content? I believe this is typically called content
> adaptive backlight control:
> 
> https://www.ecnmag.com/article/2010/04/content-adaptive-lcd-backlight-control
> 
> You spell out what DRC and SAT stands for in the driver source code,
> perhaps it also makes sense to do it here?
> 
> Perhaps rewording it to something like this is clearer:
> 
> .. allows to dynamically adjust pixel brightness/contrast based on
> histogram measurements for LCD content adaptive backlight control.

You're right, I changed it.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- 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/20160906/35bfc0a5/attachment.sig>


[PATCH 4/4 v2] drm/bridge: adv7511: Initialize audio packet on adv7533

2016-09-06 Thread John Stultz
On Fri, Sep 2, 2016 at 2:49 AM, Archit Taneja  wrote:
> Hi,
>
>
> On 8/30/2016 5:11 AM, John Stultz wrote:
>>
>> From: Andy Green 
>>
>> Set the initial audio packet settings to allow the audio
>> driver to work.
>>
>> Cc: David Airlie 
>> Cc: Archit Taneja 
>> Cc: Laurent Pinchart 
>> Cc: Wolfram Sang 
>> Cc: Srinivas Kandagatla 
>> Cc: "Ville Syrjälä" 
>> Cc: Boris Brezillon 
>> Cc: Andy Green 
>> Cc: Dave Long 
>> Cc: Guodong Xu 
>> Cc: Zhangfei Gao 
>> Cc: Mark Brown 
>> Cc: Lars-Peter Clausen 
>> Cc: Jose Abreu 
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Andy Green 
>> [jstultz: Forward ported to mainline, changed to use register
>>   names rather then hex values, and removed config values set by
>>   audio driver.]
>> Signed-off-by: John Stultz 
>> ---
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c | 22 ++
>>   1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
>> index 6798ecf..cced7c9 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
>> @@ -104,6 +104,28 @@ void adv7533_dsi_power_on(struct adv7511 *adv)
>> /* disable test mode */
>> regmap_write(adv->regmap_cec, 0x55, 0x00);
>>
>> +   /* hide Audio infoframe updates */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_INFOFRAME_UPDATE,
>> +   BIT(5), BIT(5));
>> +   /* enable N/CTS, enable Audio sample packets */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
>> +   BIT(5), BIT(5));
>> +   /* enable N/CTS */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
>> +   BIT(6), BIT(6));
>> +   /* not copyrighted */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_AUDIO_CFG1,
>> +   BIT(5), BIT(5));
>> +   /* enable audio infoframes */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_PACKET_ENABLE1,
>> +   BIT(3), BIT(3));
>> +   /* AV mute disable */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_GC(0),
>> +   BIT(7) | BIT(6), BIT(7));
>> +   /* use Audio infoframe updated info */
>> +   regmap_update_bits(adv->regmap, ADV7511_REG_GC(1),
>> +   BIT(5), 0);
>> +
>
>
> Wouldn't these writes be needed by ADV751x chips too? These seem to
> belong to the main ADV75xx regmap. These should probably be a separate func
> in adv7511_audio.c or adv7511_drv.c, and it should be called in
> adv7511_power_on, so that ADV751x chips can utilize this too.

Yea. It seems like folding this into the audio_startup() function is
the best thing here, so I've done so and it seems to be working well.
Will resend here shortly.

thanks
-john


[PATCH] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

2016-09-06 Thread Sean Paul
On Fri, Aug 26, 2016 at 6:19 AM, Yakir Yang  wrote:
> Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
> function, or printing the error Sink PSR state if we failed to effect
> the request PSR setting.
>
> Signed-off-by: Yakir Yang 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 
> --
>  3 files changed, 28 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 efac8ab..5a37de8 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -115,8 +115,7 @@ int analogix_dp_enable_psr(struct device *dev)
> psr_vsc.DB0 = 0;
> psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
>
> -   analogix_dp_send_psr_spd(dp, _vsc);
> -   return 0;
> +   return analogix_dp_send_psr_spd(dp, _vsc);
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>
> @@ -138,8 +137,7 @@ int analogix_dp_disable_psr(struct device *dev)
> psr_vsc.DB0 = 0;
> psr_vsc.DB1 = 0;
>
> -   analogix_dp_send_psr_spd(dp, _vsc);
> -   return 0;
> +   return analogix_dp_send_psr_spd(dp, _vsc);
>  }
>  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 473b980..f617a9d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -283,7 +283,7 @@ void analogix_dp_config_video_slave_mode(struct 
> analogix_dp_device *dp);
>  void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
>  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
>  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> - struct edp_vsc_psr *vsc);
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> +struct edp_vsc_psr *vsc);
>
>  #endif /* _ANALOGIX_DP_CORE_H */
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 52c1b6b..505e9d8 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -1328,9 +1328,11 @@ void analogix_dp_enable_psr_crc(struct 
> analogix_dp_device *dp)
> writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
>  }
>
> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> - struct edp_vsc_psr *vsc)
> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> +struct edp_vsc_psr *vsc)
>  {
> +   unsigned long timeout;
> +   unsigned char sink;

u8

> unsigned int val;
>
> /* don't send info frame */
> @@ -1372,4 +1374,24 @@ void analogix_dp_send_psr_spd(struct 
> analogix_dp_device *dp,
> val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
> val |= IF_EN;
> writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
> +
> +   timeout = jiffies + msecs_to_jiffies(100);

Pull 100 out into a #define

> +   while (1) {
> +   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_STATUS, );

You should be checking return value here.

> +
> +   if (vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB)
> +   break;
> +
> +   if (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE)
> +   break;
> +
> +   if (time_after(jiffies, timeout)) {
> +   dev_warn(dp->dev, "Failed to effect PSR: %x", sink);
> +   return -EBUSY;

-ETIMEDOUT is more appropriate

> +   }
> +
> +   usleep_range(1000, 1500);
> +   }

The while(1) loop is a little scary. I'd rather do:

while (time_before(jiffies, timeout)) {
   ret = analogix_dp_read_byte_from_dpcd(dp, DP_PSR_STATUS, );
   if (ret != 1) {
   DRM_DEV_ERROR(dp->dev, "PSR_STATUS read failed
ret=%d", ret);
   return ret;
   }

   if (vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB ||
   !vsc->DB1 && sink == DP_PSR_SINK_INACTIVE)
   return 0;

   usleep_range(1000, 1500);
}

dev_warn(dp->dev, "Failed to effect PSR: %x", sink);
return -ETIMEDOUT;



> +
> +   return 0;
>  }
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/atmel-hlcdc: mark atmel_hlcdc_crtc_reset() static

2016-09-06 Thread Boris Brezillon
On Tue, 06 Sep 2016 15:43:45 +0200
Arnd Bergmann  wrote:

> On Tuesday, September 6, 2016 3:46:16 PM CEST Baoyou Xie wrote:
> > We get 1 warning when building kernel with W=1:
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:390:6: warning: no previous 
> > prototype for 'atmel_hlcdc_crtc_reset' [-Wmissing-prototypes]
> > 
> > In fact, this function is only used in the file in which it is
> > declared and don't need a declaration, but can be made static.
> > So this patch marks it 'static'.
> > 
> > Signed-off-by: Baoyou Xie 
> >   
> 
> Acked-by: Arnd Bergmann 

Actually, Thierry already posted the same patch a while ago. I just
sent a PR to Dave containing this patch.


[PATCH 1/4 v2] drm/bridge: adv7511: Move the common data structures to header file

2016-09-06 Thread John Stultz
On Tue, Aug 30, 2016 at 1:56 AM, Laurent Pinchart
 wrote:
> Hi John,
>
> Thank you for the patch.
>
> On Monday 29 Aug 2016 16:41:33 John Stultz wrote:
>> From: Archit Taneja 
>>
>> This patch moves the adv7511 data structure to header file so that the
>> audio driver file could use it.
>
> Actually it doesn't, the data structure is already in the header file.

Heh.  Yea, it looks like most of that patch has fallen out, and
looking closer at it, the remainders aren't necessary, so I'm dropping
the whole thing.

thanks
-john


[PATCH] drm/atmel-hlcdc: mark atmel_hlcdc_crtc_reset() static

2016-09-06 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:390:6: warning: no previous 
prototype for 'atmel_hlcdc_crtc_reset' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index a978381..9b17a66 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -387,7 +387,7 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c)
atmel_hlcdc_crtc_finish_page_flip(drm_crtc_to_atmel_hlcdc_crtc(c));
 }

-void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
+static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
 {
struct atmel_hlcdc_crtc_state *state;

-- 
2.7.4



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

2016-09-06 Thread Arnd Bergmann
On Tuesday, September 6, 2016 3:37:55 PM CEST Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/armada/armada_gem.c:215:27: warning: no previous prototype 
> for 'armada_gem_alloc_object' [-Wmissing-prototypes]
> drivers/gpu/drm/armada/armada_gem.c:423:1: warning: no previous prototype for 
> 'armada_gem_prime_map_dma_buf' [-Wmissing-prototypes]
> 
> In fact, these functions are only used in the file in which they are
> declared and don't need a declaration, but can be made static.
> So this patch marks these functions with 'static'.
> 
> Signed-off-by: Baoyou Xie 
> 

Acked-by: Arnd Bergmann 


[PATCH] drm/atmel-hlcdc: mark atmel_hlcdc_crtc_reset() static

2016-09-06 Thread Arnd Bergmann
On Tuesday, September 6, 2016 3:46:16 PM CEST Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:390:6: warning: no previous 
> prototype for 'atmel_hlcdc_crtc_reset' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 
> 

Acked-by: Arnd Bergmann 


[PATCH v7 4/9] drm/mediatek: update display module connections

2016-09-06 Thread CK Hu
Hi, YT:

On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> update connections for OVL, RDMA, BLS, DSI
> 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
>  1 file changed, 25 insertions(+)
> 

[snip...]

> @@ -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) {

DDP_COMPONENT_BLS is a new symbol which is defined in 9th patch of this
series. I think the definition of DDP_COMPONENT_BLS should be in front
of this patch.

> + *addr = DISP_REG_CONFIG_DSI_SEL;
> + value = DSI_SEL_IN_BLS;
>   } else {
>   value = 0;
>   }
> @@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
> cur,
>   return value;
>  }
>  

Regards,
CK




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

2016-09-06 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/armada/armada_gem.c:215:27: warning: no previous prototype for 
'armada_gem_alloc_object' [-Wmissing-prototypes]
drivers/gpu/drm/armada/armada_gem.c:423:1: warning: no previous prototype for 
'armada_gem_prime_map_dma_buf' [-Wmissing-prototypes]

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

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/armada/armada_gem.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index cb8f034..1beef28 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -212,7 +212,8 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
size_t size)
return obj;
 }

-struct armada_gem_object *armada_gem_alloc_object(struct drm_device *dev,
+static struct
+armada_gem_object *armada_gem_alloc_object(struct drm_device *dev,
size_t size)
 {
struct armada_gem_object *obj;
@@ -419,7 +420,7 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
 }

 /* Prime support */
-struct sg_table *
+static struct sg_table *
 armada_gem_prime_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
 {
-- 
2.7.4



[PATCH, RESEND] drm: exynos: avoid unused function warning

2016-09-06 Thread Arnd Bergmann
When CONFIG_PM is not set, we get a warning about an unused function:

drivers/gpu/drm/exynos/exynos_drm_gsc.c:1219:12: error: 'gsc_clk_ctrl' defined 
but not used [-Werror=unused-function]
 static int gsc_clk_ctrl(struct gsc_context *ctx, bool enable)
^~~~

This removes the two #ifdef checks in this file and instead marks the
functions as __maybe_unused, which is a more reliable way of doing the
same, allowing better build coverage and avoiding the warning above.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

Originally sent on July 11, but I just got this again and noticed
it had never been applied, and I didn't get any reply for the patch.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5d20da8f957e..b0a773790f85 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1760,8 +1760,7 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
 }

-#ifdef CONFIG_PM_SLEEP
-static int gsc_suspend(struct device *dev)
+static int __maybe_unused gsc_suspend(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1773,7 +1772,7 @@ static int gsc_suspend(struct device *dev)
return gsc_clk_ctrl(ctx, false);
 }

-static int gsc_resume(struct device *dev)
+static int __maybe_unused gsc_resume(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1784,10 +1783,8 @@ static int gsc_resume(struct device *dev)

return 0;
 }
-#endif

-#ifdef CONFIG_PM
-static int gsc_runtime_suspend(struct device *dev)
+static int __maybe_unused gsc_runtime_suspend(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1796,7 +1793,7 @@ static int gsc_runtime_suspend(struct device *dev)
return  gsc_clk_ctrl(ctx, false);
 }

-static int gsc_runtime_resume(struct device *dev)
+static int __maybe_unused gsc_runtime_resume(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1804,7 +1801,6 @@ static int gsc_runtime_resume(struct device *dev)

return  gsc_clk_ctrl(ctx, true);
 }
-#endif

 static const struct dev_pm_ops gsc_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
-- 
2.9.0



[PATCH v7 2/9] drm/mediatek: add *driver_data for different hardware settings

2016-09-06 Thread CK Hu
Hi, YT:

On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> 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.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
> 
> Signed-off-by: YT Shen 
> ---

[snip...]

>  
> @@ -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));

DISP_REG_OVL_ADDR() is useless, so remove it.

> + writel_relaxed(addr, comp->regs + comp->data->ovl.addr_offset
> + + idx * 0x20);
>  
>   if (pending->enable)
>   mtk_ovl_layer_on(comp, idx);


Regards,
CK



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

2016-09-06 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/arm/malidp_planes.c:49:25: warning: no previous prototype for 
'malidp_duplicate_plane_state' [-Wmissing-prototypes]
drivers/gpu/drm/arm/malidp_planes.c:66:6: warning: no previous prototype for 
'malidp_destroy_plane_state' [-Wmissing-prototypes]

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

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/arm/malidp_planes.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 725098d..5f8bece 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -46,7 +46,8 @@ static void malidp_de_plane_destroy(struct drm_plane *plane)
devm_kfree(plane->dev->dev, mp);
 }

-struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
+static struct
+drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
 {
struct malidp_plane_state *state, *m_state;

@@ -63,7 +64,7 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
drm_plane *plane)
return >base;
 }

-void malidp_destroy_plane_state(struct drm_plane *plane,
+static void malidp_destroy_plane_state(struct drm_plane *plane,
struct drm_plane_state *state)
 {
struct malidp_plane_state *m_state = to_malidp_plane_state(state);
-- 
2.7.4



[PATCH 1/1] Revert "gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle"

2016-09-06 Thread Tomi Valkeinen
Hi Dave,

Can you pick this for drm-fixes? The bug is causing scary looking stack
dumps when loading omapdrm.

Apparently this fix went into drm-next accidentally instead of
drm-fixes. I hope having the same patch in both trees won't be causing
any extra conflicts.

 Tomi

On 11/08/16 12:44, Peter Chen wrote:
> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
> 
> The of_get_next_parent will drop refcount on the passed node, so the reverted
> patch is wrong, thanks for Tomi Valkeinen points it.
> 
> Cc: Tomi Valkeinen 
> Signed-off-by: Peter Chen 
> ---
>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> index e256d87..dfd4e96 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> @@ -125,16 +125,15 @@ u32 dss_of_port_get_port_number(struct device_node 
> *port)
>  
>  static struct device_node *omapdss_of_get_remote_port(const struct 
> device_node *node)
>  {
> - struct device_node *np, *np_parent;
> + struct device_node *np;
>  
>   np = of_parse_phandle(node, "remote-endpoint", 0);
>   if (!np)
>   return NULL;
>  
> - np_parent = of_get_next_parent(np);
> - of_node_put(np);
> + np = of_get_next_parent(np);
>  
> - return np_parent;
> + return np;
>  }
>  
>  struct device_node *
> 

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


[PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

2016-09-06 Thread John Stultz
On Tue, Aug 30, 2016 at 2:23 AM, Laurent Pinchart
 wrote:
> Hi John,
>
> Thank you for the patches.

Thanks so much for the review! I'm reworking the patchset now and will
be sending out an updated set soon!


>> This patchset, along with the i2s driver and dts changes allows
>> HDMI audio to work on the HiKey board.
>
> Where are the dts changes ?

Here's what I'm using to get it working:
https://git.linaro.org/people/john.stultz/android-dev.git/commitdiff/1024cb485b6f00a7e355ce60425f04a584481148

But again, that's dependent on the k3dma driver (queued), the hi6210
i2s driver (still being reworked), and adv7511 audio (this patchset).

thanks
-john


[PATCH] drm/amd/powerplay/polaris10: mark symbols static where possible

2016-09-06 Thread Baoyou Xie
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_clockpowergating.c:34:5:
 warning: no previous prototype
for 'polaris10_phm_powerup_uvd' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_thermal.c:428:5: 
warning: no previous prototype
for 'tf_polaris10_thermal_setup_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:125:31: 
warning: no previous prototype
for 'cast_phw_polaris10_power_state' [-Wmissing-prototypes]


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

Signed-off-by: Baoyou Xie 
---
 .../powerplay/hwmgr/polaris10_clockpowergating.c   | 10 ++--
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 65 --
 .../drm/amd/powerplay/hwmgr/polaris10_thermal.c|  6 +-
 3 files changed, 45 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_clockpowergating.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_clockpowergating.c
index b5edb51..7e405b0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_clockpowergating.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_clockpowergating.c
@@ -31,7 +31,7 @@ int polaris10_phm_powerdown_uvd(struct pp_hwmgr *hwmgr)
return 0;
 }

-int polaris10_phm_powerup_uvd(struct pp_hwmgr *hwmgr)
+static int polaris10_phm_powerup_uvd(struct pp_hwmgr *hwmgr)
 {
if (phm_cf_want_uvd_power_gating(hwmgr)) {
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
@@ -47,7 +47,7 @@ int polaris10_phm_powerup_uvd(struct pp_hwmgr *hwmgr)
return 0;
 }

-int polaris10_phm_powerdown_vce(struct pp_hwmgr *hwmgr)
+static int polaris10_phm_powerdown_vce(struct pp_hwmgr *hwmgr)
 {
if (phm_cf_want_vce_power_gating(hwmgr))
return smum_send_msg_to_smc(hwmgr->smumgr,
@@ -55,7 +55,7 @@ int polaris10_phm_powerdown_vce(struct pp_hwmgr *hwmgr)
return 0;
 }

-int polaris10_phm_powerup_vce(struct pp_hwmgr *hwmgr)
+static int polaris10_phm_powerup_vce(struct pp_hwmgr *hwmgr)
 {
if (phm_cf_want_vce_power_gating(hwmgr))
return smum_send_msg_to_smc(hwmgr->smumgr,
@@ -63,7 +63,7 @@ int polaris10_phm_powerup_vce(struct pp_hwmgr *hwmgr)
return 0;
 }

-int polaris10_phm_powerdown_samu(struct pp_hwmgr *hwmgr)
+static int polaris10_phm_powerdown_samu(struct pp_hwmgr *hwmgr)
 {
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_SamuPowerGating))
@@ -72,7 +72,7 @@ int polaris10_phm_powerdown_samu(struct pp_hwmgr *hwmgr)
return 0;
 }

-int polaris10_phm_powerup_samu(struct pp_hwmgr *hwmgr)
+static int polaris10_phm_powerup_samu(struct pp_hwmgr *hwmgr)
 {
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_SamuPowerGating))
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index 769636a..a6bab40 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -122,7 +122,7 @@ enum DPM_EVENT_SRC {

 static const unsigned long PhwPolaris10_Magic = (unsigned 
long)(PHM_VIslands_Magic);

-struct polaris10_power_state *cast_phw_polaris10_power_state(
+static struct polaris10_power_state *cast_phw_polaris10_power_state(
  struct pp_hw_power_state *hw_ps)
 {
PP_ASSERT_WITH_CODE((PhwPolaris10_Magic == hw_ps->magic),
@@ -132,7 +132,8 @@ struct polaris10_power_state 
*cast_phw_polaris10_power_state(
return (struct polaris10_power_state *)hw_ps;
 }

-const struct polaris10_power_state *cast_const_phw_polaris10_power_state(
+static const struct polaris10_power_state *
+cast_const_phw_polaris10_power_state(
 const struct pp_hw_power_state *hw_ps)
 {
PP_ASSERT_WITH_CODE((PhwPolaris10_Magic == hw_ps->magic),
@@ -155,7 +156,7 @@ static bool polaris10_is_dpm_running(struct pp_hwmgr *hwmgr)
  * @paramhwmgr  the address of the powerplay hardware manager.
  * @return   always 0
  */
-int phm_get_mc_microcode_version (struct pp_hwmgr *hwmgr)
+static int phm_get_mc_microcode_version(struct pp_hwmgr *hwmgr)
 {
cgs_write_register(hwmgr->device, mmMC_SEQ_IO_DEBUG_INDEX, 0x9F);

@@ -164,7 +165,7 @@ int phm_get_mc_microcode_version (struct pp_hwmgr *hwmgr)
return 0;
 }

-uint16_t phm_get_current_pcie_speed(struct pp_hwmgr *hwmgr)
+static uint16_t phm_get_current_pcie_speed(struct pp_hwmgr *hwmgr)
 {
uint32_t speedCntl = 0;

@@ -175,7 +176,7 @@ uint16_t phm_get_current_pcie_speed(struct pp_hwmgr *hwmgr)
PCIE_LC_SPEED_CNTL, LC_CURRENT_DATA_RATE));
 }

-int phm_get_current_pcie_lane_number(struct 

[PATCH] drm/rockchip: Fix up bug in psr state machine

2016-09-06 Thread Sean Paul
The ->set() callback would always be called when transitioning
from FLUSH->DISABLE since we assign state to psr->state right
above the skip condition.

Reported-by: Daniel Kurtz 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index c6ac5d0..cb17709 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -74,11 +74,13 @@ static void psr_set_state_locked(struct psr_drv *psr, enum 
psr_state state)
if (state == PSR_FLUSH && psr->state == PSR_DISABLE)
return;

-   psr->state = state;
-
/* Already disabled in flush, change the state, but not the hardware */
-   if (state == PSR_DISABLE && psr->state == PSR_FLUSH)
+   if (state == PSR_DISABLE && psr->state == PSR_FLUSH) {
+   psr->state = state;
return;
+   }
+
+   psr->state = state;

/* Actually commit the state change to hardware */
switch (psr->state) {
-- 
2.8.0.rc3.226.g39d4020



[PATCH 3/3] drm/tilcdc: Add mutex to protect crtc enable and disable routines

2016-09-06 Thread Jyri Sarha
On 09/06/16 12:30, Tomi Valkeinen wrote:
> On 06/09/16 11:19, Jyri Sarha wrote:
>> Add mutex to protect crtc enable and disable routines. The
>> tilcdc_crtc_disable() function waits for frame done interrupt, the
>> internal data will get out of sync, should another enable arrive while
>> waiting for the interrupt.
> 
> Why doesn't the per-crtc modeset lock work for this?
> 

I am not worried about DRM enabling and disabling the crtc, it should
take the locks it needs on its own, and AFAIU the driver should not try
take the same locks again.

The purpose of these locks is to protect underneath workings the LCDC
driver reacting to something happening outside the DRM, like CPU
frequency change or module unloading.

I considered dropping this patch already last night (it was my first
attempt to fix the race, and it worked too), but then decided to put it
under review just for the sake of argument ;).

All in all it should be enough to take all the necessary DRM locks when
fiddling with lcdc hw and not to implement any extra layers of locking.

I'll drop this patch.

BR,
Jyri


[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

2016-09-06 Thread Sean Paul
On Tue, Sep 6, 2016 at 3:01 PM, hl  wrote:
> Hi
>
>
> On 2016年09月07日 02:55, Sean Paul wrote:
>>
>> On Tue, Sep 6, 2016 at 2:15 PM, hl  wrote:
>>>
>>> Hi Sean,
>>>
>>>
>>> On 2016年09月07日 01:18, Sean Paul wrote:

 On Mon, Sep 5, 2016 at 1:06 AM, Lin Huang  wrote:
>
> when in ddr frequency scaling process, vop can not do enable or
> disable operation, since in dcf we check vop clock to see whether
> vop work. If vop work, dcf do ddr frequency scaling when vop
> in vblank status, and we need to read vop register to check whether
> vop go into vblank status. If vop not work, dcf can do ddr frequency
> any time. So when do ddr frequency scaling, you disabled or enable
> vop, there may two bad thing happen: 1, the panel flicker(when vop from
> disable status change to enable). 2, kernel hang (when vop from enable
> status change to disable, dcf need to read vblank status, but if you
> disable
> vop clock, it can not get the status, it will lead soc dead) So we need
> register to devfreq notifier, and we can get the dmc status. Also, when
> there have two vop enabled, we need to disable dmc, since dcf only base
> on one vop vblank time, so the other panel will flicker when do ddr
> frequency scaling.
>
> Signed-off-by: Lin Huang 
> Reviewed-by: Chanwoo Choi 
> ---
> Changes in v10:
> - None
>
> Changes in v9:
> - None
>
> Changes in v8:
> - None
>
> Changes in v7:
> - None
>
> Changes in v6:
> - fix a build error
>
> Changes in v5:
> - improve some nits
>
> Changes in v4:
> - register notifier to devfreq_register_notifier
> - use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
> - when two vop enable, disable dmc
> - when two vop back to one vop, enable dmc
>
> Changes in v3:
> - when do vop eanble/disable, dmc will wait until it finish
>
> Changes in v2:
> - None
>
> Changes in v1:
> - use wait_event instead usleep
>
>drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 116
> 
>1 file changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index efbc41a..a73f3aa 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -19,6 +19,8 @@
>#include 
>#include 
>
> +#include 
> +#include 
>#include 
>#include 
>#include 
> @@ -118,6 +120,13 @@ struct vop {
>
>   const struct vop_data *data;
>
> +   struct devfreq *devfreq;
> +   struct devfreq_event_dev *devfreq_event_dev;
> +   struct notifier_block dmc_nb;
> +   int dmc_in_process;
> +   int vop_switch_status;
> +   wait_queue_head_t wait_dmc_queue;
> +   wait_queue_head_t wait_vop_switch_queue;
>   uint32_t *regsbak;
>   void __iomem *regs;
>
> @@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct
> vop *vop)
>   spin_unlock_irqrestore(>irq_lock, flags);
>}
>
> +static int dmc_notify(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> +   struct vop *vop = container_of(nb, struct vop, dmc_nb);
> +
> +   if (event == DEVFREQ_PRECHANGE) {
> +   /*
> +* check if vop in enable or disable process,
> +* if yes, wait until it finishes, use 200ms as
> +* timeout.
> +*/
> +   if (!wait_event_timeout(vop->wait_vop_switch_queue,
> +   !vop->vop_switch_status, HZ /
> 5))
> +   dev_warn(vop->dev,
> +"Timeout waiting for vop swtich
> status\n");
> +   vop->dmc_in_process = 1;
> +   } else if (event == DEVFREQ_POSTCHANGE) {
> +   vop->dmc_in_process = 0;
> +   wake_up(>wait_dmc_queue);
> +   }
> +
> +   return NOTIFY_OK;
> +}
> +
>static int vop_enable(struct drm_crtc *crtc)
>{
>   struct vop *vop = to_vop(crtc);
> +   int num_enabled_crtc = 0;
>   int ret;
>
> +   /*
> +* if in dmc scaling frequency process, wait until it finishes
> +* use 200ms as timeout time.
> +*/
> +   if (!wait_event_timeout(vop->wait_dmc_queue,
> +   !vop->dmc_in_process, HZ / 5))
> +   dev_warn(vop->dev,
> +"Timeout waiting for dmc when vop enable\n");
> +


 This wait_event_timeout code is 

[PATCH 1/3] drm/tilcdc: Take mode config lock while updating the crtc clock rate

2016-09-06 Thread Jyri Sarha
On 09/06/16 12:07, Tomi Valkeinen wrote:
> 
> 
> On 06/09/16 11:19, Jyri Sarha wrote:
>> Take mode config lock while updating the crtc clock rate. To avoid a
>> race in tilcdc_crtc_update_clk(), we do not want the mode to change
>> while we update crtc clock.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 5 +
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 ++
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
>> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> index f8892e9..882d9b5 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> @@ -184,10 +184,14 @@ static int cpufreq_transition(struct notifier_block 
>> *nb,
>>  {
>>  struct tilcdc_drm_private *priv = container_of(nb,
>>  struct tilcdc_drm_private, freq_transition);
>> +struct drm_mode_config *config = >dev->mode_config;
>> +
>>  if (val == CPUFREQ_POSTCHANGE) {
>>  if (priv->lcd_fck_rate != clk_get_rate(priv->clk)) {
>> +mutex_lock(>mutex);
> 
> drm_modeset_lock_crtc()? Or drm_modeset_lock_all() if per-crtc is not
> suitable.
> 

I guess that should work too, all I need is just to make sure no one
calls mode_set_nofb() while the clock is updated.

I just thought that since I am not actually touching drm state at all
the back off mechanisms etc add just unnecessary complexity. But now
after reading a little bit drm locking code, for sure the mode config
mutex is not the light weight lock I was looking for.

One solution would be adding tilcdc internal mutex to synchronize
mode_set_nofb() and cpufreq_transition(), but after all it is probably
better to use the mechanisms that are already there and just use
drm_modeset_lock_crtc() despite its apparent complexity.

BR,
Jyri


[PULL] drm/atmel-hlcdc: fixes for 4.8-rc6

2016-09-06 Thread Boris Brezillon
Hi Dave,

Here are two fixes for 4.8-rc6. I was supposed to send this PR just
after -rc1, but I completely forgot, so if you feel it's too late
for this release, I can queue them for 4.9 (note that the fixes are
trivial, and I don't think they can introduce a regression).

Regards,

Boris

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git at github.com:bbrezillon/linux-at91.git tags/drm/atmel-hlcdc/4.8-fixes

for you to fetch changes up to 1ba7db07ccc2825669d6e376632316813a072887:

  drm/atmel-hlcdc: Make ->reset() implementation static (2016-09-06 14:46:16 
+0200)


Two fixes for 4.8:
- missing static specifier on atmel_hlcdc_crtc_reset()
- bug in the hardware scaling logic


Jan Leupold (1):
  drm: atmel-hlcdc: Fix vertical scaling

Thierry Reding (1):
  drm/atmel-hlcdc: Make ->reset() implementation static

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)


[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

2016-09-06 Thread Sean Paul
On Tue, Sep 6, 2016 at 2:15 PM, hl  wrote:
> Hi Sean,
>
>
> On 2016年09月07日 01:18, Sean Paul wrote:
>>
>> On Mon, Sep 5, 2016 at 1:06 AM, Lin Huang  wrote:
>>>
>>> when in ddr frequency scaling process, vop can not do enable or
>>> disable operation, since in dcf we check vop clock to see whether
>>> vop work. If vop work, dcf do ddr frequency scaling when vop
>>> in vblank status, and we need to read vop register to check whether
>>> vop go into vblank status. If vop not work, dcf can do ddr frequency
>>> any time. So when do ddr frequency scaling, you disabled or enable
>>> vop, there may two bad thing happen: 1, the panel flicker(when vop from
>>> disable status change to enable). 2, kernel hang (when vop from enable
>>> status change to disable, dcf need to read vblank status, but if you
>>> disable
>>> vop clock, it can not get the status, it will lead soc dead) So we need
>>> register to devfreq notifier, and we can get the dmc status. Also, when
>>> there have two vop enabled, we need to disable dmc, since dcf only base
>>> on one vop vblank time, so the other panel will flicker when do ddr
>>> frequency scaling.
>>>
>>> Signed-off-by: Lin Huang 
>>> Reviewed-by: Chanwoo Choi 
>>> ---
>>> Changes in v10:
>>> - None
>>>
>>> Changes in v9:
>>> - None
>>>
>>> Changes in v8:
>>> - None
>>>
>>> Changes in v7:
>>> - None
>>>
>>> Changes in v6:
>>> - fix a build error
>>>
>>> Changes in v5:
>>> - improve some nits
>>>
>>> Changes in v4:
>>> - register notifier to devfreq_register_notifier
>>> - use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
>>> - when two vop enable, disable dmc
>>> - when two vop back to one vop, enable dmc
>>>
>>> Changes in v3:
>>> - when do vop eanble/disable, dmc will wait until it finish
>>>
>>> Changes in v2:
>>> - None
>>>
>>> Changes in v1:
>>> - use wait_event instead usleep
>>>
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 116
>>> 
>>>   1 file changed, 116 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> index efbc41a..a73f3aa 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -19,6 +19,8 @@
>>>   #include 
>>>   #include 
>>>
>>> +#include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -118,6 +120,13 @@ struct vop {
>>>
>>>  const struct vop_data *data;
>>>
>>> +   struct devfreq *devfreq;
>>> +   struct devfreq_event_dev *devfreq_event_dev;
>>> +   struct notifier_block dmc_nb;
>>> +   int dmc_in_process;
>>> +   int vop_switch_status;
>>> +   wait_queue_head_t wait_dmc_queue;
>>> +   wait_queue_head_t wait_vop_switch_queue;
>>>  uint32_t *regsbak;
>>>  void __iomem *regs;
>>>
>>> @@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct
>>> vop *vop)
>>>  spin_unlock_irqrestore(>irq_lock, flags);
>>>   }
>>>
>>> +static int dmc_notify(struct notifier_block *nb, unsigned long event,
>>> + void *data)
>>> +{
>>> +   struct vop *vop = container_of(nb, struct vop, dmc_nb);
>>> +
>>> +   if (event == DEVFREQ_PRECHANGE) {
>>> +   /*
>>> +* check if vop in enable or disable process,
>>> +* if yes, wait until it finishes, use 200ms as
>>> +* timeout.
>>> +*/
>>> +   if (!wait_event_timeout(vop->wait_vop_switch_queue,
>>> +   !vop->vop_switch_status, HZ / 5))
>>> +   dev_warn(vop->dev,
>>> +"Timeout waiting for vop swtich
>>> status\n");
>>> +   vop->dmc_in_process = 1;
>>> +   } else if (event == DEVFREQ_POSTCHANGE) {
>>> +   vop->dmc_in_process = 0;
>>> +   wake_up(>wait_dmc_queue);
>>> +   }
>>> +
>>> +   return NOTIFY_OK;
>>> +}
>>> +
>>>   static int vop_enable(struct drm_crtc *crtc)
>>>   {
>>>  struct vop *vop = to_vop(crtc);
>>> +   int num_enabled_crtc = 0;
>>>  int ret;
>>>
>>> +   /*
>>> +* if in dmc scaling frequency process, wait until it finishes
>>> +* use 200ms as timeout time.
>>> +*/
>>> +   if (!wait_event_timeout(vop->wait_dmc_queue,
>>> +   !vop->dmc_in_process, HZ / 5))
>>> +   dev_warn(vop->dev,
>>> +"Timeout waiting for dmc when vop enable\n");
>>> +
>>
>>
>> This wait_event_timeout code is terribly racey (same goes above and
>> below).
>
>   No i use the vop_switch_status and dmc_in_progress to handle the vop and
> dmc racey,


So what happens if dmc_in_progress becomes 1 right here, or anywhere
during vop_enable()?

Sean




>I assume this can fix the racey now. I do not better a idea now.
>>
>>
>>
>>> +   vop->vop_switch_status = 1;
>>> +
>>>  ret = 

[PATCH] drm/amd/powerplay/fiji: mark symbols static where possible

2016-09-06 Thread Baoyou Xie
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_hwmgr.c:1633:9: warning: no 
previous prototype
for 'fiji_get_voltage_index' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_hwmgr.c:5412:5: warning: no 
previous prototype
for 'fiji_check_states_equal' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c:424:5: warning: no 
previous prototype
for 'tf_fiji_thermal_setup_fan_table' [-Wmissing-prototypes]


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

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 33 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c |  6 ++--
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
index 120a9e2..a4726c4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
@@ -113,7 +113,7 @@ static const uint8_t 
fiji_clock_stretch_amount_conversion[2][6] =

 static const unsigned long PhwFiji_Magic = (unsigned long)(PHM_VIslands_Magic);

-struct fiji_power_state *cast_phw_fiji_power_state(
+static struct fiji_power_state *cast_phw_fiji_power_state(
  struct pp_hw_power_state *hw_ps)
 {
PP_ASSERT_WITH_CODE((PhwFiji_Magic == hw_ps->magic),
@@ -123,7 +123,8 @@ struct fiji_power_state *cast_phw_fiji_power_state(
return (struct fiji_power_state *)hw_ps;
 }

-const struct fiji_power_state *cast_const_phw_fiji_power_state(
+static const struct
+fiji_power_state *cast_const_phw_fiji_power_state(
 const struct pp_hw_power_state *hw_ps)
 {
PP_ASSERT_WITH_CODE((PhwFiji_Magic == hw_ps->magic),
@@ -1630,7 +1631,7 @@ static int fiji_setup_default_dpm_tables(struct pp_hwmgr 
*hwmgr)
  * @param voltage - voltage to look for
  * @return 0 on success
  */
-uint8_t fiji_get_voltage_index(
+static uint8_t fiji_get_voltage_index(
struct phm_ppt_v1_voltage_lookup_table *lookup_table, uint16_t 
voltage)
 {
uint8_t count = (uint8_t) (lookup_table->count);
@@ -1694,7 +1695,7 @@ static int fiji_populate_cac_table(struct pp_hwmgr *hwmgr,
 * @return   always  0
 */

-int fiji_populate_smc_voltage_tables(struct pp_hwmgr *hwmgr,
+static int fiji_populate_smc_voltage_tables(struct pp_hwmgr *hwmgr,
struct SMU73_Discrete_DpmTable *table)
 {
int result;
@@ -2305,7 +2306,7 @@ static int fiji_populate_all_memory_levels(struct 
pp_hwmgr *hwmgr)
 * @parammclkthe MCLK value to be used in the decision if MVDD 
should be high or low.
 * @paramvoltage the SMC VOLTAGE structure to be populated
 */
-int fiji_populate_mvdd_value(struct pp_hwmgr *hwmgr,
+static int fiji_populate_mvdd_value(struct pp_hwmgr *hwmgr,
uint32_t mclk, SMIO_Pattern *smio_pat)
 {
const struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
@@ -4626,7 +4627,7 @@ static int fiji_generate_dpm_level_enable_mask(
return 0;
 }

-int fiji_enable_disable_uvd_dpm(struct pp_hwmgr *hwmgr, bool enable)
+static int fiji_enable_disable_uvd_dpm(struct pp_hwmgr *hwmgr, bool enable)
 {
return smum_send_msg_to_smc(hwmgr->smumgr, enable ?
  (PPSMC_Msg)PPSMC_MSG_UVDDPM_Enable :
@@ -4640,14 +4641,14 @@ int fiji_enable_disable_vce_dpm(struct pp_hwmgr *hwmgr, 
bool enable)
PPSMC_MSG_VCEDPM_Disable);
 }

-int fiji_enable_disable_samu_dpm(struct pp_hwmgr *hwmgr, bool enable)
+static int fiji_enable_disable_samu_dpm(struct pp_hwmgr *hwmgr, bool enable)
 {
return smum_send_msg_to_smc(hwmgr->smumgr, enable?
PPSMC_MSG_SAMUDPM_Enable :
PPSMC_MSG_SAMUDPM_Disable);
 }

-int fiji_enable_disable_acp_dpm(struct pp_hwmgr *hwmgr, bool enable)
+static int fiji_enable_disable_acp_dpm(struct pp_hwmgr *hwmgr, bool enable)
 {
return smum_send_msg_to_smc(hwmgr->smumgr, enable?
PPSMC_MSG_ACPDPM_Enable :
@@ -4884,7 +4885,7 @@ static void fiji_apply_dal_minimum_voltage_request(struct 
pp_hwmgr *hwmgr)
return;
 }

-int fiji_upload_dpm_level_enable_mask(struct pp_hwmgr *hwmgr)
+static int fiji_upload_dpm_level_enable_mask(struct pp_hwmgr *hwmgr)
 {
int result;
struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
@@ -5160,7 +5161,7 @@ static int fiji_program_display_gap(struct pp_hwmgr 
*hwmgr)
return 0;
 }

-int fiji_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
+static int fiji_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
 {
return fiji_program_display_gap(hwmgr);
 }
@@ -5191,7 +5192,7 @@ static int 

[PATCH 2/2] drm/udl: implement usb_driver suspend/resume.

2016-09-06 Thread Sean Paul
On Tue, Aug 30, 2016 at 5:50 PM, Haixia Shi  wrote:
> The usb_driver suspend and resume function pointers must be populated
> to prevent forced unbinding of USB interface driver. See usb/core/driver.c:
> unbind_no_pm_drivers_interfaces().
>
> Restore mode and damage the entire frame buffer upon resume.
>
> TEST=suspend and resume with the same UDL device connected
> TEST=suspend with UDL, unplug UDL and resume
> TEST=suspend with UDL, unplug and connect another UDL device then resume
>
> Signed-off-by: Haixia Shi 
> Reviewed-by: Stphane Marchesin 

I think this patch stands well on its own, and given the work required for 1/2:

I took the liberty of fixing your checkpatch warnings and gave marcheu
his é back.

Applied to drm-misc

Sean


> ---
>  drivers/gpu/drm/udl/udl_drv.c | 17 +
>  drivers/gpu/drm/udl/udl_drv.h |  2 ++
>  drivers/gpu/drm/udl/udl_modeset.c | 13 +
>  3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 17d34e0..e5dc73b 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -16,6 +16,21 @@ static int udl_driver_set_busid(struct drm_device *d, 
> struct drm_master *m)
> return 0;
>  }
>
> +static int udl_usb_suspend(struct usb_interface *interface,
> +  pm_message_t message)
> +{
> +   return 0;
> +}
> +
> +static int udl_usb_resume(struct usb_interface *interface)
> +{
> +   struct drm_device *dev = usb_get_intfdata(interface);
> +
> +   udl_modeset_restore(dev);
> +   return 0;
> +}
> +
> +
>  static const struct vm_operations_struct udl_gem_vm_ops = {
> .fault = udl_gem_fault,
> .open = drm_gem_vm_open,
> @@ -122,6 +137,8 @@ static struct usb_driver udl_driver = {
> .name = "udl",
> .probe = udl_usb_probe,
> .disconnect = udl_usb_disconnect,
> +   .suspend = udl_usb_suspend,
> +   .resume = udl_usb_resume,
> .id_table = id_table,
>  };
>  module_usb_driver(udl_driver);
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 0b03d34..f338a57 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -52,6 +52,7 @@ struct udl_device {
> struct device *dev;
> struct drm_device *ddev;
> struct usb_device *udev;
> +   struct drm_crtc *crtc;
>
> int sku_pixel_limit;
>
> @@ -87,6 +88,7 @@ struct udl_framebuffer {
>
>  /* modeset */
>  int udl_modeset_init(struct drm_device *dev);
> +void udl_modeset_restore(struct drm_device *dev);
>  void udl_modeset_cleanup(struct drm_device *dev);
>  int udl_connector_init(struct drm_device *dev, struct drm_encoder *encoder);
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
> b/drivers/gpu/drm/udl/udl_modeset.c
> index 7369512..69d6a4f 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -309,6 +309,8 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
> char *wrptr;
> int color_depth = 0;
>
> +   udl->crtc = crtc;
> +
> buf = (char *)udl->mode_buf;
>
> /* for now we just clip 24 -> 16 - if we fix that fix this */
> @@ -450,6 +452,17 @@ int udl_modeset_init(struct drm_device *dev)
> return 0;
>  }
>
> +void udl_modeset_restore(struct drm_device *dev)
> +{
> +   struct udl_device *udl = dev->dev_private;
> +   struct udl_framebuffer *ufb;
> +   if (!udl->crtc || !udl->crtc->primary->fb)
> +   return;
> +   udl_crtc_commit(udl->crtc);
> +   ufb = to_udl_fb(udl->crtc->primary->fb);
> +   udl_handle_damage(ufb, 0, 0, ufb->base.width, ufb->base.height);
> +}
> +
>  void udl_modeset_cleanup(struct drm_device *dev)
>  {
> drm_mode_config_cleanup(dev);
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] gpu/drm: fix signed integer overflow

2016-09-06 Thread Sean Paul
On Tue, Sep 6, 2016 at 4:55 AM, Xie XiuQi  wrote:
> Use 1UL for unsigned long, or we'll meet a overflow issue with UBSAN.
>
> [   15.589489] UBSAN: Undefined behaviour in 
> drivers/gpu/drm/drm_hashtab.c:145:35
> [   15.589500] signed integer overflow:
> [   15.58] -2147483648 - 1 cannot be represented in type 'int'
> [   15.590434] CPU: 2 PID: 294 Comm: plymouthd Not tainted 
> 3.10.0-327.28.3.el7.x86_64 #1
> [   15.590653] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
> Desktop Reference Platform, BIOS 6.00 01/07/2011
> [   15.591001]  11000670fe83 0d6b385e 88003387f3e0 
> 81ee3140
> [   15.591028]  88003387f3f8 81ee31fd a032f460 
> 88003387f560
> [   15.591044]  81ee46e2 002d0009 0001 
> 41b58ab3
> [   15.591059] Call Trace:
> [   15.591078]  [] dump_stack+0x1e/0x20
> [   15.591093]  [] ubsan_epilogue+0x12/0x55
> [   15.591109]  [] handle_overflow+0x1ba/0x215
> [   15.591126]  [] ? 
> __ubsan_handle_negate_overflow+0x162/0x162
> [   15.591146]  [] ? print_context_stack+0x9c/0x160
> [   15.591163]  [] ? dump_trace+0x252/0x750
> [   15.591181]  [] ? __list_add+0x93/0x160
> [   15.591197]  [] __ubsan_handle_sub_overflow+0x2a/0x31
> [   15.591261]  [] drm_ht_just_insert_please+0x1e0/0x200 
> [drm]
> [   15.591290]  [] ttm_base_object_init+0x10a/0x270 [ttm]
> [   15.591316]  [] ttm_vt_lock+0x28c/0x3a0 [ttm]
> [   15.591343]  [] ? ttm_write_lock+0x180/0x180 [ttm]
> [   15.591362]  [] ? kasan_unpoison_shadow+0x36/0x50
> [   15.591379]  [] ? kasan_unpoison_shadow+0x36/0x50
> [   15.591396]  [] ? kasan_unpoison_shadow+0x36/0x50
> [   15.591413]  [] ? kasan_unpoison_shadow+0x36/0x50
> [   15.591442]  [] vmw_master_set+0x121/0x470 [vmwgfx]
> [   15.591459]  [] ? __init_waitqueue_head+0x45/0x70
> [   15.591487]  [] ? vmw_master_drop+0x310/0x310 [vmwgfx]
> [   15.591535]  [] drm_open+0x92a/0xc00 [drm]
> [   15.591563]  [] ? vmw_driver_open+0x170/0x170 [vmwgfx]
> [   15.591610]  [] ? drm_poll+0xe0/0xe0 [drm]
> [   15.591661]  [] drm_stub_open+0x224/0x330 [drm]
> [   15.591711]  [] ? drm_minor_acquire+0x240/0x240 [drm]
> [   15.591727]  [] chrdev_open+0x1fa/0x3f0
> [   15.591742]  [] ? cdev_put+0x50/0x50
> [   15.591761]  [] ? __fsnotify_parent+0x53/0x210
> [   15.591778]  [] do_dentry_open+0x351/0x670
> [   15.591792]  [] ? cdev_put+0x50/0x50
> [   15.591807]  [] vfs_open+0xa2/0x170
> [   15.591824]  [] do_last+0xccf/0x2c80
> [   15.591842]  [] ? filename_create+0x320/0x320
> [   15.591858]  [] ? path_init+0x1b9/0xa90
> [   15.591875]  [] ? mountpoint_last+0x9a0/0x9a0
> [   15.591894]  [] ? selinux_file_alloc_security+0xcf/0x130
> [   15.591911]  [] path_openat+0x1e7/0xcc0
> [   15.591927]  [] ? dump_trace+0x252/0x750
> [   15.591943]  [] ? do_last+0x2c80/0x2c80
> [   15.591959]  [] ? __list_add+0x93/0x160
> [   15.591974]  [] ? save_stack_trace+0x7d/0xb0
> [   15.591989]  [] do_filp_open+0xa4/0x160
> [   15.592004]  [] ? user_path_mountpoint_at+0x50/0x50
> [   15.592022]  [] ? __alloc_fd+0x175/0x300
> [   15.592039]  [] do_sys_open+0x1b7/0x3f0
> [   15.592054]  [] ? filp_open+0x80/0x80
> [   15.592070]  [] SyS_open+0x32/0x40
> [   15.592088]  [] system_call_fastpath+0x16/0x1b
>
> Signed-off-by: Xie XiuQi 

Applied to drm-misc (with slightly tweaked subject)

> ---
>  drivers/gpu/drm/drm_hashtab.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
> index 7b30b30..dae18e5 100644
> --- a/drivers/gpu/drm/drm_hashtab.c
> +++ b/drivers/gpu/drm/drm_hashtab.c
> @@ -142,7 +142,7 @@ int drm_ht_just_insert_please(struct drm_open_hash *ht, 
> struct drm_hash_item *it
>   unsigned long add)
>  {
> int ret;
> -   unsigned long mask = (1 << bits) - 1;
> +   unsigned long mask = (1UL << bits) - 1;
> unsigned long first, unshifted_key;
>
> unshifted_key = hash_long(seed, bits);
> --
> 1.8.3.1
>


i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread Meelis Roos
> Meelis, what does 'lspci -nns 2' say for you?

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0102] (rev 09)

> 
> BR,
> Jani.
> 
> On Tue, 06 Sep 2016, Jani Nikula  wrote:
> > Lyude, this is due to
> >
> > commit 87660502f1a4d51fb043e89a45d30c9917787c22
> > Author: Lyude 
> > Date:   Wed Aug 17 15:55:53 2016 -0400
> >
> > drm/i915/gen6+: Interpret mailbox error flags
> >
> > and on its way to stable.
> >
> > BR,
> > Jani.
> >
> >
> > On Mon, 29 Aug 2016, Meelis Roos  wrote:
> >> Tried 4.8-rc4 on my i5-2400 PC, got this warning:
> >>
> >> [   14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> >> [   15.847321] [ cut here ]
> >> [   15.847346] WARNING: CPU: 0 PID: 208 at 
> >> drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x109/0x1f0 
> >> [i915]
> >> [   15.847348] Missing switch case (16) in gen6_check_mailbox_status
> >> [   15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace 
> >> cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal 
> >> kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek 
> >> snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support 
> >> glue_helper lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper 
> >> psmouse pcspkr syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci 
> >> ehci_hcd snd_hda_intel xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep 
> >> usbcore drm snd_hda_core usb_common i2c_i801 ptp pps_core i2c_smbus 
> >> snd_pcm_oss snd_mixer_oss snd_pcm snd_timer evdev snd tpm_tis lpc_ich 
> >> parport_pc tpm_tis_core mfd_core parport nuvoton_cir rc_core tpm soundcore 
> >> floppy w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core loop ip_tables 
> >> x_tables autofs4
> >> [   15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213
> >> [   15.847396] Hardware name:  /DQ67OW, BIOS 
> >> SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
> >> [   15.847412] Workqueue: events intel_gen6_powersave_work [i915]
> >> [   15.847414]   812d8198 88023191fd70 
> >> 
> >> [   15.847417]  81056d1e 88022ea4 88023191fdc0 
> >> 
> >> [   15.847419]  88022ea4a3c8 88022ea487c0 088023e21ba0 
> >> 81056d8f
> >> [   15.847422] Call Trace:
> >> [   15.847427]  [] ? dump_stack+0x46/0x5e
> >> [   15.847429]  [] ? __warn+0xbe/0xe0
> >> [   15.847431]  [] ? warn_slowpath_fmt+0x4f/0x60
> >> [   15.847446]  [] ? sandybridge_pcode_write+0x109/0x1f0 
> >> [i915]
> >> [   15.847459]  [] ? 
> >> intel_gen6_powersave_work+0x2a8/0x1400 [i915]
> >> [   15.847462]  [] ? process_one_work+0x1eb/0x480
> >> [   15.847465]  [] ? worker_thread+0x47/0x4c0
> >> [   15.847467]  [] ? __schedule+0x1d7/0x660
> >> [   15.847469]  [] ? process_one_work+0x480/0x480
> >> [   15.847472]  [] ? kthread+0xbd/0xe0
> >> [   15.847475]  [] ? ret_from_fork+0x1f/0x40
> >> [   15.847478]  [] ? kthread_worker_fn+0x160/0x160
> >> [   15.847487] ---[ end trace ad9e991297d99be1 ]---
> 
> 

-- 
Meelis Roos (mroos at linux.ee)


[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-09-06 Thread Ville Syrjälä
On Tue, Sep 06, 2016 at 12:20:51PM +0300, Ville Syrjälä wrote:
> On Sun, Aug 28, 2016 at 05:28:46PM +0200, Andrea Arcangeli wrote:
> > Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> > model which is based on IvyBridge.
> > 
> > The commit that introduced the regression is
> > 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > 
> > The Skylake workaround for the regression was introduced in commit
> > aeddda06c1a704bb97c8a7bfe7a472120193bd56
> > 
> > Signed-off-by: Andrea Arcangeli 
> > ---
> >  drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index adca262..ca17ab6 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct 
> > drm_i915_private *dev_priv)
> > }
> >  
> > /*
> > -* FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> > -* low vswing for eDP, whereas the VBT panel type (2) gives us normal
> > -* vswing instead. Low vswing results in some display flickers, so
> > -* let's simply ignore the OpRegion panel type on SKL for now.
> > +* FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> > +* OpRegion panel type (0) gives us low vswing for eDP,
> > +* whereas the VBT panel type (2) gives us normal vswing
> > +* instead. Low vswing results in some display flickers, so
> > +* let's simply ignore the OpRegion panel type on SKL and
> > +* IVYBRIDGE for now.
> >  */
> > -   if (IS_SKYLAKE(dev_priv)) {
> > +   if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
> > DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> > return -ENODEV;
> > }
> 
> Argh. I guess we'll just have to revert the whole opregion panel type thing
> and ty to figure out some way to do this only for the system(s) that need it.
> 
> Hmm. Can someone test the top commit from [1] on top of the broken kernel?
> If we can get an EDID somehow for the panel then the panel type shouldn't
> matter that much any more.
> 
> [1] git://github.com/vsyrjala/linux.git acpi_edid

Actually I just cooked up another branch [2]. It just throws in some
memory barriers to the opregion code, and adds a a new debug print so
to show the response from the BIOS. I'm not too optimistic that the
memory barriers would fix it, but at least we'd get to see the full
response from the BIOS. Can you give this a try?

[2] git://github.com/vsyrjala/linux.git opregion_panel_type_stuff

-- 
Ville Syrjälä
Intel OTC


[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

2016-09-06 Thread Sean Paul
On Mon, Sep 5, 2016 at 1:06 AM, Lin Huang  wrote:
> when in ddr frequency scaling process, vop can not do enable or
> disable operation, since in dcf we check vop clock to see whether
> vop work. If vop work, dcf do ddr frequency scaling when vop
> in vblank status, and we need to read vop register to check whether
> vop go into vblank status. If vop not work, dcf can do ddr frequency
> any time. So when do ddr frequency scaling, you disabled or enable
> vop, there may two bad thing happen: 1, the panel flicker(when vop from
> disable status change to enable). 2, kernel hang (when vop from enable
> status change to disable, dcf need to read vblank status, but if you disable
> vop clock, it can not get the status, it will lead soc dead) So we need
> register to devfreq notifier, and we can get the dmc status. Also, when
> there have two vop enabled, we need to disable dmc, since dcf only base
> on one vop vblank time, so the other panel will flicker when do ddr
> frequency scaling.
>
> Signed-off-by: Lin Huang 
> Reviewed-by: Chanwoo Choi 
> ---
> Changes in v10:
> - None
>
> Changes in v9:
> - None
>
> Changes in v8:
> - None
>
> Changes in v7:
> - None
>
> Changes in v6:
> - fix a build error
>
> Changes in v5:
> - improve some nits
>
> Changes in v4:
> - register notifier to devfreq_register_notifier
> - use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
> - when two vop enable, disable dmc
> - when two vop back to one vop, enable dmc
>
> Changes in v3:
> - when do vop eanble/disable, dmc will wait until it finish
>
> Changes in v2:
> - None
>
> Changes in v1:
> - use wait_event instead usleep
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 116 
> 
>  1 file changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index efbc41a..a73f3aa 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -118,6 +120,13 @@ struct vop {
>
> const struct vop_data *data;
>
> +   struct devfreq *devfreq;
> +   struct devfreq_event_dev *devfreq_event_dev;
> +   struct notifier_block dmc_nb;
> +   int dmc_in_process;
> +   int vop_switch_status;
> +   wait_queue_head_t wait_dmc_queue;
> +   wait_queue_head_t wait_vop_switch_queue;
> uint32_t *regsbak;
> void __iomem *regs;
>
> @@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
> *vop)
> spin_unlock_irqrestore(>irq_lock, flags);
>  }
>
> +static int dmc_notify(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> +   struct vop *vop = container_of(nb, struct vop, dmc_nb);
> +
> +   if (event == DEVFREQ_PRECHANGE) {
> +   /*
> +* check if vop in enable or disable process,
> +* if yes, wait until it finishes, use 200ms as
> +* timeout.
> +*/
> +   if (!wait_event_timeout(vop->wait_vop_switch_queue,
> +   !vop->vop_switch_status, HZ / 5))
> +   dev_warn(vop->dev,
> +"Timeout waiting for vop swtich status\n");
> +   vop->dmc_in_process = 1;
> +   } else if (event == DEVFREQ_POSTCHANGE) {
> +   vop->dmc_in_process = 0;
> +   wake_up(>wait_dmc_queue);
> +   }
> +
> +   return NOTIFY_OK;
> +}
> +
>  static int vop_enable(struct drm_crtc *crtc)
>  {
> struct vop *vop = to_vop(crtc);
> +   int num_enabled_crtc = 0;
> int ret;
>
> +   /*
> +* if in dmc scaling frequency process, wait until it finishes
> +* use 200ms as timeout time.
> +*/
> +   if (!wait_event_timeout(vop->wait_dmc_queue,
> +   !vop->dmc_in_process, HZ / 5))
> +   dev_warn(vop->dev,
> +"Timeout waiting for dmc when vop enable\n");
> +


This wait_event_timeout code is terribly racey (same goes above and below).


> +   vop->vop_switch_status = 1;
> +
> ret = pm_runtime_get_sync(vop->dev);
> if (ret < 0) {
> dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
> @@ -479,6 +524,21 @@ static int vop_enable(struct drm_crtc *crtc)
>
> drm_crtc_vblank_on(crtc);
>
> +   vop->vop_switch_status = 0;
> +   wake_up(>wait_vop_switch_queue);
> +
> +   /* check how many VOPs in use now */
> +   drm_for_each_crtc(crtc, vop->drm_dev) {
> +   if (crtc->state->enable)

I think you really want to check active, instead of enable.

> +   num_enabled_crtc++;
> +   }
> +
> +   /* if enable two vop, need to disable dmc */
> +   if ((num_enabled_crtc > 1) && vop->devfreq) {
> +

[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled

2016-09-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97119

--- Comment #19 from Christoph Haag  ---
Discard that. It still happens with kwin git.

-- 
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/20160906/6d7cd6eb/attachment.html>


[Intel-gfx] [PATCH 01/10] drm: Move a few macros away from drm_crtc.h

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Now that there's less stuff in there I noticed that I overlooked them.
> Sprinkle some docs over them while at it.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  include/drm/drm_connector.h   | 24 ++--
>  include/drm/drm_crtc.h| 32 
>  include/drm/drm_encoder.h | 22 ++
>  include/drm/drm_framebuffer.h | 17 +
>  include/drm/drm_modes.h   |  2 ++
>  include/drm/drm_property.h|  1 +
>  6 files changed, 64 insertions(+), 34 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 66b7d6744dd2..e4e545e9516d 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -181,14 +181,19 @@ int drm_display_info_set_bus_formats(struct 
> drm_display_info *info,
>  /**
>   * struct drm_connector_state - mutable connector state
>   * @connector: backpointer to the connector
> - * @crtc: CRTC to connect connector to, NULL if disabled
>   * @best_encoder: can be used by helpers and drivers to select the encoder
>   * @state: backpointer to global drm_atomic_state
>   */
>  struct drm_connector_state {
> struct drm_connector *connector;
>
> -   struct drm_crtc *crtc;  /* do not write directly, use 
> drm_atomic_set_crtc_for_connector() */
> +   /**
> +* @crtc: CRTC to connect connector to, NULL if disabled.
> +*
> +* Do not change this directly, use 
> drm_atomic_set_crtc_for_connector()
> +* instead.
> +*/
> +   struct drm_crtc *crtc;
>
> struct drm_encoder *best_encoder;
>
> @@ -744,4 +749,19 @@ int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
>  int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> const struct edid *edid);
> +
> +/**
> + * drm_for_each_connector - iterate over all connectors
> + * @connector: the loop cursor
> + * @dev: the DRM device
> + *
> + * Iterate over all connectors of @dev.
> + */
> +#define drm_for_each_connector(connector, dev) \
> +   for (assert_drm_connector_list_read_locked(&(dev)->mode_config),  
>   \
> +connector = list_first_entry(&(dev)->mode_config.connector_list, 
>   \
> + struct drm_connector, head);
>   \
> +>head != (&(dev)->mode_config.connector_list);
>   \
> +connector = list_next_entry(connector, head))
> +
>  #endif
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4880606e2ffd..2a642ae96127 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1991,22 +1991,7 @@ struct drm_mode_config {
> list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
> for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
>
> -/**
> - * drm_for_each_encoder_mask - iterate over encoders specified by bitmask
> - * @encoder: the loop cursor
> - * @dev: the DRM device
> - * @encoder_mask: bitmask of encoder indices
> - *
> - * Iterate over all encoders specified by bitmask.
> - */
> -#define drm_for_each_encoder_mask(encoder, dev, encoder_mask) \
> -   list_for_each_entry((encoder), &(dev)->mode_config.encoder_list, 
> head) \
> -   for_each_if ((encoder_mask) & (1 << 
> drm_encoder_index(encoder)))
> -
>  #define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
> -#define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
> -#define obj_to_fb(x) container_of(x, struct drm_framebuffer, base)
> -#define obj_to_blob(x) container_of(x, struct drm_property_blob, base)
>  #define obj_to_plane(x) container_of(x, struct drm_plane, base)
>
>  extern __printf(6, 7)
> @@ -2174,23 +2159,6 @@ assert_drm_connector_list_read_locked(struct 
> drm_mode_config *mode_config)
> !drm_modeset_is_locked(_config->connection_mutex));
>  }
>
> -#define drm_for_each_connector(connector, dev) \
> -   for (assert_drm_connector_list_read_locked(&(dev)->mode_config),  
>   \
> -connector = list_first_entry(&(dev)->mode_config.connector_list, 
>   \
> - struct drm_connector, head);
>   \
> ->head != (&(dev)->mode_config.connector_list);
>   \
> -connector = list_next_entry(connector, head))
> -
> -#define drm_for_each_encoder(encoder, dev) \
> -   list_for_each_entry(encoder, &(dev)->mode_config.encoder_list, head)
> -
> -#define drm_for_each_fb(fb, dev) \
> -   for (WARN_ON(!mutex_is_locked(&(dev)->mode_config.fb_lock)),  
>   \
> -fb = list_first_entry(&(dev)->mode_config.fb_list, \
> - struct drm_framebuffer, head);  
>   \
> -

[PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Some were still left in drm_crtc.h. Also include drm_edid.h in the
> rst files.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/drm-kms-helpers.rst |  3 +++
>  include/drm/drm_crtc.h| 30 +-
>  include/drm/drm_edid.h| 30 ++
>  3 files changed, 34 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 48fc5a96bf95..bb4254d19cbb 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -208,6 +208,9 @@ Output Probing Helper Functions Reference
>  EDID Helper Functions Reference
>  ===
>
> +.. kernel-doc:: include/drm/drm_edid.h
> +   :internal:
> +
>  .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> :export:
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bf9ee1b97c26..7bb3aa87a8be 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  struct drm_device;
>  struct drm_mode_set;
> @@ -1992,33 +1993,4 @@ assert_drm_connector_list_read_locked(struct 
> drm_mode_config *mode_config)
> !drm_modeset_is_locked(_config->connection_mutex));
>  }
>
> -/* drm_edid.c */
> -bool drm_probe_ddc(struct i2c_adapter *adapter);
> -struct edid *drm_get_edid(struct drm_connector *connector,
> - struct i2c_adapter *adapter);
> -struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> -struct i2c_adapter *adapter);
> -struct edid *drm_edid_duplicate(const struct edid *edid);
> -int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> -
> -u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> -enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> -bool drm_detect_hdmi_monitor(struct edid *edid);
> -bool drm_detect_monitor_audio(struct edid *edid);
> -bool drm_rgb_quant_range_selectable(struct edid *edid);
> -int drm_add_modes_noedid(struct drm_connector *connector,
> -int hdisplay, int vdisplay);
> -void drm_set_preferred_mode(struct drm_connector *connector,
> -   int hpref, int vpref);
> -
> -int drm_edid_header_is_valid(const u8 *raw_edid);
> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> - bool *edid_corrupt);
> -bool drm_edid_is_valid(struct edid *edid);
> -void drm_edid_get_monitor_name(struct edid *edid, char *name,
> -  int buflen);
> -struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> -  int hsize, int vsize, int fresh,
> -  bool rb);
> -
>  #endif /* __DRM_CRTC_H__ */
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 919933d1beb4..c3a7d440bc11 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -25,6 +25,9 @@
>
>  #include 
>
> +struct drm_device;
> +struct i2c_adapter;
> +
>  #define EDID_LENGTH 128
>  #define DDC_ADDR 0x50
>  #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */
> @@ -423,9 +426,36 @@ static inline u8 drm_eld_get_conn_type(const uint8_t 
> *eld)
> return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
>  }
>
> +bool drm_probe_ddc(struct i2c_adapter *adapter);
>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
>   size_t len),
> void *data);
> +struct edid *drm_get_edid(struct drm_connector *connector,
> + struct i2c_adapter *adapter);
> +struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> +struct i2c_adapter *adapter);
> +struct edid *drm_edid_duplicate(const struct edid *edid);
> +int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> +
> +u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> +bool drm_detect_hdmi_monitor(struct edid *edid);
> +bool drm_detect_monitor_audio(struct edid *edid);
> +bool drm_rgb_quant_range_selectable(struct edid *edid);
> +int drm_add_modes_noedid(struct drm_connector *connector,
> +int hdisplay, int vdisplay);
> +void drm_set_preferred_mode(struct drm_connector *connector,
> +   int hpref, int vpref);
> +
> +int drm_edid_header_is_valid(const u8 *raw_edid);
> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> + bool *edid_corrupt);
> +bool drm_edid_is_valid(struct edid *edid);
> +void 

[Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Just pure code movement, cleanup and polish will happen in later
> patches.
>
> v2: Don't forget all the ioctl! To extract those cleanly I decided to
> put check_src_coords into drm_framebuffer.c (and give it a
> drm_framebuffer_ prefix), since that just checks framebuffer
> constraints.
>
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms.rst   |  12 +
>  drivers/gpu/drm/Makefile|   3 +-
>  drivers/gpu/drm/drm_crtc.c  | 939 
> +---
>  drivers/gpu/drm/drm_crtc_internal.h |  38 +-
>  drivers/gpu/drm/drm_framebuffer.c   |  26 +
>  drivers/gpu/drm/drm_plane.c | 937 +++
>  include/drm/drm_atomic.h| 154 ++
>  include/drm/drm_crtc.h  | 583 +-
>  include/drm/drm_plane.h | 470 ++
>  9 files changed, 1628 insertions(+), 1534 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_plane.c
>  create mode 100644 include/drm/drm_plane.h
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index f9a991bb87d4..33181be97151 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -110,6 +110,18 @@ Note that dumb objects may not be used for gpu 
> acceleration, as has been
>  attempted on some ARM embedded platforms. Such drivers really must have
>  a hardware-specific ioctl to allocate suitable buffer objects.
>
> +Plane Abstraction
> +=
> +
> +Plane Functions Reference
> +-
> +
> +.. kernel-doc:: include/drm/drm_plane.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> +   :export:
> +
>  Display Modes Function Reference
>  
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 439d89b25ae0..8eeb07a35798 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -14,7 +14,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> drm_rect.o drm_vma_manager.o drm_flip_work.o \
> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> drm_framebuffer.o drm_connector.o drm_blend.o \
> -   drm_encoder.o drm_mode_object.o drm_property.o
> +   drm_encoder.o drm_mode_object.o drm_property.o \
> +   drm_plane.o
>
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0fad433f4d2d..513ab4729683 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c



> -
> -static int check_src_coords(uint32_t src_x, uint32_t src_y,
> -   uint32_t src_w, uint32_t src_h,
> -   const struct drm_framebuffer *fb)
> -{
> -   unsigned int fb_width, fb_height;
> -
> -   fb_width = fb->width << 16;
> -   fb_height = fb->height << 16;
> -
> -   /* Make sure source coordinates are inside the fb. */
> -   if (src_w > fb_width ||
> -   src_x > fb_width - src_w ||
> -   src_h > fb_height ||
> -   src_y > fb_height - src_h) {
> -   DRM_DEBUG_KMS("Invalid source coordinates "
> - "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
> - src_w >> 16, ((src_w & 0x) * 15625) >> 10,
> - src_h >> 16, ((src_h & 0x) * 15625) >> 10,
> - src_x >> 16, ((src_x & 0x) * 15625) >> 10,
> - src_y >> 16, ((src_y & 0x) * 15625) >> 10);
> -   return -ENOSPC;
> -   }
> -
> -   return 0;
> -}

I'm good with this change, but I'd argue that it probably belongs in
its own patch.




>  /**
> - * drm_mode_page_flip_ioctl - schedule an asynchronous fb update
> - * @dev: DRM device
> - * @data: ioctl data
> - * @file_priv: DRM file info
> - *
> - * This schedules an asynchronous update on a given CRTC, called page flip.
> - * Optionally a drm event is generated to signal the completion of the event.
> - * Generic drivers cannot assume that a pageflip with changed framebuffer
> - * properties (including driver specific metadata like tiling layout) will 
> work,
> - * but some drivers support e.g. pixel format changes through the pageflip
> - * ioctl.
> - *
> - * Called by the user via ioctl.
> - *
> - * Returns:
> - * Zero on success, negative errno on failure.
> - */
> -int drm_mode_page_flip_ioctl(struct drm_device *dev,
> -void *data, struct drm_file *file_priv)


IMO, this makes more sense where it is (it's a crtc operation since
the ioctl data doesn't even reference planes). Perhaps it should be
sent out on an icefloat with setplane and other legacy ABI in some
corner.

Sean



> ___
> Intel-gfx 

[PATCH 06/10] drm: Conslidate blending properties in drm_blend.[hc]

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Imo zpos, rotatation, blending eq (once we have it) and all that
> should be in drm_blend.c, since those are all about how exactly the
> pixels are rendered onto the CRTC's visible area. Also noticed that
> one exported function accidentally ended up in drm_crtc_internal.h,
> move it to the right place too.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_blend.c | 51 ++--
>  drivers/gpu/drm/drm_crtc.c  | 49 --
>  drivers/gpu/drm/drm_crtc_internal.h |  3 --
>  include/drm/drm_blend.h | 59 
> +
>  include/drm/drm_crtc.h  | 27 +
>  5 files changed, 109 insertions(+), 80 deletions(-)
>  create mode 100644 include/drm/drm_blend.h
>
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 0813b7e021be..ab39245a21c4 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -25,12 +25,59 @@
>   */
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
>
> -#include "drm_internal.h"
> +struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> *dev,
> +  unsigned int 
> supported_rotations)
> +{
> +   static const struct drm_prop_enum_list props[] = {
> +   { __builtin_ffs(DRM_ROTATE_0) - 1,   "rotate-0" },
> +   { __builtin_ffs(DRM_ROTATE_90) - 1,  "rotate-90" },
> +   { __builtin_ffs(DRM_ROTATE_180) - 1, "rotate-180" },
> +   { __builtin_ffs(DRM_ROTATE_270) - 1, "rotate-270" },
> +   { __builtin_ffs(DRM_REFLECT_X) - 1,  "reflect-x" },
> +   { __builtin_ffs(DRM_REFLECT_Y) - 1,  "reflect-y" },
> +   };
> +
> +   return drm_property_create_bitmask(dev, 0, "rotation",
> +  props, ARRAY_SIZE(props),
> +  supported_rotations);
> +}
> +EXPORT_SYMBOL(drm_mode_create_rotation_property);
> +
> +/**
> + * drm_rotation_simplify() - Try to simplify the rotation
> + * @rotation: Rotation to be simplified
> + * @supported_rotations: Supported rotations
> + *
> + * Attempt to simplify the rotation to a form that is supported.
> + * Eg. if the hardware supports everything except DRM_REFLECT_X
> + * one could call this function like this:
> + *
> + * drm_rotation_simplify(rotation, DRM_ROTATE_0 |
> + *   DRM_ROTATE_90 | DRM_ROTATE_180 |
> + *   DRM_ROTATE_270 | DRM_REFLECT_Y);
> + *
> + * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
> + * transforms the hardware supports, this function may not
> + * be able to produce a supported transform, so the caller should
> + * check the result afterwards.
> + */
> +unsigned int drm_rotation_simplify(unsigned int rotation,
> +  unsigned int supported_rotations)
> +{
> +   if (rotation & ~supported_rotations) {
> +   rotation ^= DRM_REFLECT_X | DRM_REFLECT_Y;
> +   rotation = (rotation & DRM_REFLECT_MASK) |
> +  BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
> +   }
> +
> +   return rotation;
> +}
> +EXPORT_SYMBOL(drm_rotation_simplify);
>
>  /**
>   * drm_plane_create_zpos_property - create mutable zpos property
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9ef7955032db..e5229b48d5d5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1218,37 +1218,6 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
>  }
>
>  /**
> - * drm_rotation_simplify() - Try to simplify the rotation
> - * @rotation: Rotation to be simplified
> - * @supported_rotations: Supported rotations
> - *
> - * Attempt to simplify the rotation to a form that is supported.
> - * Eg. if the hardware supports everything except DRM_REFLECT_X
> - * one could call this function like this:
> - *
> - * drm_rotation_simplify(rotation, DRM_ROTATE_0 |
> - *   DRM_ROTATE_90 | DRM_ROTATE_180 |
> - *   DRM_ROTATE_270 | DRM_REFLECT_Y);
> - *
> - * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
> - * transforms the hardware supports, this function may not
> - * be able to produce a supported transform, so the caller should
> - * check the result afterwards.
> - */
> -unsigned int drm_rotation_simplify(unsigned int rotation,
> -  unsigned int supported_rotations)
> -{
> -   if (rotation & ~supported_rotations) {
> -   rotation ^= DRM_REFLECT_X | DRM_REFLECT_Y;
> -   rotation = (rotation & DRM_REFLECT_MASK) |
> -  BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
> -   }
> -
> -   return rotation;
> -}
> 

[PATCH 07/10] drm/doc: Polish plane composition property docs

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Try to spec a bit more precisely how they all fit together, now that
> at least the code is for all the additional properties is in one
> place.
>
> Also remove the entries for the standardized properties from the
> table, because that thing is supremely unmaintaineable.

This is great!

But... I have a few spelling/copypasta/word nits below. Once they're fixed up,

Reviewed-by: Sean Paul 

>
> Cc: Ville Syrjälä 
> Cc: Sean Paul 
> Cc: Benjamin Gaignard 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms.rst|   7 +-
>  Documentation/gpu/kms-properties.csv |  15 
>  drivers/gpu/drm/drm_blend.c  | 146 
> ++-
>  drivers/gpu/drm/drm_plane.c  |   3 +
>  4 files changed, 136 insertions(+), 35 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index b1029e292e5c..6be8d3359620 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -287,8 +287,11 @@ Property Types and Blob Property Support
>  .. kernel-doc:: drivers/gpu/drm/drm_property.c
> :export:
>
> -Blending and Z-Position properties
> ---
> +Plane Composition Properties
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_blend.c
> +   :doc: overview
>
>  .. kernel-doc:: drivers/gpu/drm/drm_blend.c
> :export:
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 4c5ce3edcfd9..1aa2493d1ef9 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -1,23 +1,10 @@
>  Owner Module/Drivers,Group,Property Name,Type,Property Values,Object 
> attached,Description/Restrictions
> -DRM,Generic,“rotation”,BITMASK,"{ 0, ""rotate-0"" }, { 1, ""rotate-90"" 
> }, { 2, ""rotate-180"" }, { 3, ""rotate-270"" }, { 4, ""reflect-x"" }, { 5, 
> ""reflect-y"" }","CRTC, Plane",rotate-(degrees) rotates the image by the 
> specified amount in degrees in counter clockwise direction. reflect-x and 
> reflect-y reflects the image along the specified axis prior to rotation
>  ,,“scaling mode”,ENUM,"{ ""None"", ""Full"", ""Center"", ""Full aspect"" 
> }",Connector,"Supported by: amdgpu, gma500, i915, nouveau and radeon."
>  ,Connector,“EDID”,BLOB | IMMUTABLE,0,Connector,Contains id of edid blob 
> ptr object.
>  ,,“DPMS”,ENUM,"{ “On”, “Standby”, “Suspend”, “Off” 
> }",Connector,Contains DPMS operation mode value.
>  ,,“PATH”,BLOB | IMMUTABLE,0,Connector,Contains topology path to a 
> connector.
>  ,,“TILE”,BLOB | IMMUTABLE,0,Connector,Contains tiling information for a 
> connector.
>  ,,“CRTC_ID”,OBJECT,DRM_MODE_OBJECT_CRTC,Connector,CRTC that connector is 
> attached to (atomic)
> -,Plane,“type”,ENUM | IMMUTABLE,"{ ""Overlay"", ""Primary"", ""Cursor"" 
> }",Plane,Plane type
> -,,“SRC_X”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source x coordinate 
> in 16.16 fixed point (atomic)
> -,,“SRC_Y”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source y coordinate 
> in 16.16 fixed point (atomic)
> -,,“SRC_W”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source width in 
> 16.16 fixed point (atomic)
> -,,“SRC_H”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source height in 
> 16.16 fixed point (atomic)
> -,,“CRTC_X”,SIGNED_RANGE,"Min=INT_MIN, Max=INT_MAX",Plane,Scanout CRTC 
> (destination) x coordinate (atomic)
> -,,“CRTC_Y”,SIGNED_RANGE,"Min=INT_MIN, Max=INT_MAX",Plane,Scanout CRTC 
> (destination) y coordinate (atomic)
> -,,“CRTC_W”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination) 
> width (atomic)
> -,,“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
> @@ -95,7 +82,6 @@ armada,CRTC,"""CSC_YUV""",ENUM,"{ ""Auto"" , ""CCIR601"", 
> ""CCIR709"" }",CRTC,TB
>  ,,"""contrast""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
>  ,,"""saturation""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
>  exynos,CRTC,“mode”,ENUM,"{ ""normal"", ""blank"" }",CRTC,TBD
> -,Overlay,“zpos”,RANGE,"Min=0, Max=MAX_PLANE-1",Plane,TBD
>  i2c/ch7006_drv,Generic,“scale”,RANGE,"Min=0, Max=2",Connector,TBD
>  ,TV,“mode”,ENUM,"{ ""PAL"", ""PAL-M"",""PAL-N""}, 

[Intel-gfx] [PATCH 09/10] drm/doc: Document color space handling

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> Again move it from the unmaintainable csv into DOC free-form overview
> sections.
>
> Cc: Lionel Landwerlin 
> Signed-off-by: Daniel Vetter 

A few more comment nits, after those are fixed,

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/drm-kms.rst| 12 +
>  Documentation/gpu/kms-properties.csv |  5 
>  drivers/gpu/drm/drm_color_mgmt.c | 48 
> 
>  include/drm/drm_color_mgmt.h | 11 ++---
>  4 files changed, 68 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 6be8d3359620..53b872c105d2 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -296,6 +296,18 @@ Plane Composition Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_blend.c
> :export:
>
> +Color Management Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> +   :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_color_mgmt.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> +   :export:
> +
>  Existing KMS Properties
>  ---
>
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 1aa2493d1ef9..1a5729c4af65 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -24,11 +24,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to 
> suggest an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
>  ,,“dirty”,ENUM | IMMUTABLE,"{ ""Off"", ""On"", ""Annotate"" 
> }",Connector,TBD
> -,,“DEGAMMA_LUT”,BLOB,0,CRTC,DRM property to set the degamma lookup table 
> (LUT) mapping pixel data from the framebuffer before it is given to the 
> transformation matrix. The data is an interpreted as an array of struct 
> drm_color_lut elements. Hardware might choose not to use the full precision 
> of the LUT elements nor use all the elements of the LUT (for example the 
> hardware might choose to interpolate between LUT[0] and LUT[4]).
> -,,“DEGAMMA_LUT_SIZE”,RANGE | IMMUTABLE,"Min=0, Max=UINT_MAX",CRTC,DRM 
> property to gives the size of the lookup table to be set on the DEGAMMA_LUT 
> property (the size depends on the underlying hardware).
> -,,“CTM”,BLOB,0,CRTC,DRM property to set the current transformation 
> matrix (CTM) apply to pixel data after the lookup through the degamma LUT and 
> before the lookup through the gamma LUT. The data is an interpreted as a 
> struct drm_color_ctm.
> -,,“GAMMA_LUT”,BLOB,0,CRTC,DRM property to set the gamma lookup table 
> (LUT) mapping pixel data after to the transformation matrix to data sent to 
> the connector. The data is an interpreted as an array of struct drm_color_lut 
> elements. Hardware might choose not to use the full precision of the LUT 
> elements nor use all the elements of the LUT (for example the hardware might 
> choose to interpolate between LUT[0] and LUT[4]).
> -,,“GAMMA_LUT_SIZE”,RANGE | IMMUTABLE,"Min=0, Max=UINT_MAX",CRTC,DRM 
> property to gives the size of the lookup table to be set on the GAMMA_LUT 
> property (the size depends on the underlying hardware).
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" 
> }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" 
> } etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index aca1b7a6397c..23b792746cfd 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -26,6 +26,54 @@
>
>  #include "drm_crtc_internal.h"
>
> +/**
> + * DOC: overview
> + *
> + * Color management or color space adjustements is supported through a set 
> of 5

s/adjustements/adjustments/

> + * properties on the _crtc object. They are set up by calling
> + * drm_crtc_enable_color_mgmt().
> + *
> + * "DEGAMMA_LUT”:
> + * Blob property to set the degamma lookup table (LUT) mapping pixel data
> + * from the framebuffer before it is given to the transformation matrix.
> + * The data is an interpreted as an array of struct _color_lut 
> elements.
> + * Hardware might choose not to use the full precision of the LUT 
> elements
> + * nor use all the elements of the LUT (for example the hardware might
> + * choose to interpolate between LUT[0] and 

[Intel-gfx] [PATCH 10/10] drm: Remove dirty property from docs

2016-09-06 Thread Sean Paul
On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter  
wrote:
> We removed it in
>
> commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
> Author: Daniel Vetter 
> Date:   Fri Aug 12 22:48:45 2016 +0200
>
> drm/kms: Nuke dirty_info property
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/kms-properties.csv | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 1a5729c4af65..981873a05d14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -23,7 +23,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, 
> Max=0x",Connector,property to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to 
> suggest an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> -,,“dirty”,ENUM | IMMUTABLE,"{ ""Off"", ""On"", ""Annotate"" 
> }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" 
> }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" 
> } etc.",Connector,TBD
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[PATCH 2/3] drm/tilcdc: Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition()

2016-09-06 Thread Tomi Valkeinen
On 06/09/16 11:19, Jyri Sarha wrote:

> +static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + const unsigned clkdiv = 2; /* using a fixed divider of 2 */

Btw, not related to this patch, but you may want to revisit this
hardcoded divider at some point. I don't remember the history, but it
was a quick solution to some issues. Supporting any divider the HW
allows would probably give us better clock rates.

Well, except if the source clock comes right from a dedicated PLL, which
supports the whole pixel clock range. If that's the case, then the LCDC
divider doesn't help much.

 Tomi

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


[PATCH 2/3] drm/tilcdc: Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition()

2016-09-06 Thread Tomi Valkeinen
On 06/09/16 11:19, Jyri Sarha wrote:
> Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition(). The new
> tilcdc_crtc_set_clk() is used in tilcdc_crtc_mode_set_nofb() instead
> tilcdc_crtc_update_clk(). New tilcdc_crtc_update_clk() is implemented
> using tilcdc_crtc_set_clk() for cpufreq_transition() alone.

I think the patch looks ok, but the description doesn't help too much in
understanding what this does. It gives no hint on what
tilcdc_crtc_set_clk() is, what's its relation to
tilcdc_crtc_update_clk(), and what's the overall purpose here.

If I have to read the code to understand the reason for the patch, the
description has failed =).

 Tomi

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


[PATCH 3/3] drm/tilcdc: Add mutex to protect crtc enable and disable routines

2016-09-06 Thread Tomi Valkeinen
On 06/09/16 11:19, Jyri Sarha wrote:
> Add mutex to protect crtc enable and disable routines. The
> tilcdc_crtc_disable() function waits for frame done interrupt, the
> internal data will get out of sync, should another enable arrive while
> waiting for the interrupt.

Why doesn't the per-crtc modeset lock work for this?

 Tomi

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


[Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread Jani Nikula
On Tue, 06 Sep 2016, linux at eikelenboom.it wrote:
> L.S.,
>
> Since one of the last 4.8 RC's i'm getting the warning below when 
> booting on my sandybridge based thinkpad.
>  From what it seems the machine still works fine though.

What does 'lspci -nns 2' say for you?

BR,
Jani.


>
> --
> Sander
>
> [2.846265] [ cut here ]
> [2.846280] WARNING: CPU: 0 PID: 4 at 
> drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x104/0x1e0
> [2.846282] Missing switch case (16) in gen6_check_mailbox_status
> [2.846284] Modules linked in:
> [2.846289] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 
> 4.8.0-rc5-x220-20160905+ #1
> [2.846290] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW 
> (1.39 ) 07/18/2013
> [2.846297] Workqueue: events intel_gen6_powersave_work
> [2.846302]   8138bd84 88030fd7bd78 
> 
> [2.846305]  81062d84 88030d49 88030fd7bdc8 
> 
> [2.846308]  88030d49a438 88030d498830  
> 81062dea
> [2.846309] Call Trace:
> [2.846319]  [] ? dump_stack+0x5c/0x78
> [2.846324]  [] ? __warn+0xb4/0xd0
> [2.846328]  [] ? warn_slowpath_fmt+0x4a/0x50
> [2.846333]  [] ? 
> sandybridge_pcode_write+0x104/0x1e0
> [2.846338]  [] ? 
> intel_gen6_powersave_work+0x2a3/0x1400
> [2.846344]  [] ? process_one_work+0x1ba/0x3d0
> [2.846348]  [] ? worker_thread+0x45/0x4e0
> [2.846351]  [] ? process_one_work+0x3d0/0x3d0
> [2.846355]  [] ? kthread+0xb8/0xd0
> [2.846362]  [] ? ret_from_fork+0x1f/0x40
> [2.846365]  [] ? kthread_worker_fn+0x180/0x180
> [2.846368] ---[ end trace da7b2ca8a6654bfa ]---
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center


i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread Jani Nikula

Meelis, what does 'lspci -nns 2' say for you?

BR,
Jani.

On Tue, 06 Sep 2016, Jani Nikula  wrote:
> Lyude, this is due to
>
> commit 87660502f1a4d51fb043e89a45d30c9917787c22
> Author: Lyude 
> Date:   Wed Aug 17 15:55:53 2016 -0400
>
> drm/i915/gen6+: Interpret mailbox error flags
>
> and on its way to stable.
>
> BR,
> Jani.
>
>
> On Mon, 29 Aug 2016, Meelis Roos  wrote:
>> Tried 4.8-rc4 on my i5-2400 PC, got this warning:
>>
>> [   14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
>> [   15.847321] [ cut here ]
>> [   15.847346] WARNING: CPU: 0 PID: 208 at 
>> drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x109/0x1f0 
>> [i915]
>> [   15.847348] Missing switch case (16) in gen6_check_mailbox_status
>> [   15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace 
>> cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal 
>> kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek 
>> snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support 
>> glue_helper lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper psmouse 
>> pcspkr syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci ehci_hcd 
>> snd_hda_intel xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep usbcore drm 
>> snd_hda_core usb_common i2c_i801 ptp pps_core i2c_smbus snd_pcm_oss 
>> snd_mixer_oss snd_pcm snd_timer evdev snd tpm_tis lpc_ich parport_pc 
>> tpm_tis_core mfd_core parport nuvoton_cir rc_core tpm soundcore floppy 
>> w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core loop ip_tables x_tables 
>> autofs4
>> [   15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213
>> [   15.847396] Hardware name:  /DQ67OW, BIOS 
>> SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
>> [   15.847412] Workqueue: events intel_gen6_powersave_work [i915]
>> [   15.847414]   812d8198 88023191fd70 
>> 
>> [   15.847417]  81056d1e 88022ea4 88023191fdc0 
>> 
>> [   15.847419]  88022ea4a3c8 88022ea487c0 088023e21ba0 
>> 81056d8f
>> [   15.847422] Call Trace:
>> [   15.847427]  [] ? dump_stack+0x46/0x5e
>> [   15.847429]  [] ? __warn+0xbe/0xe0
>> [   15.847431]  [] ? warn_slowpath_fmt+0x4f/0x60
>> [   15.847446]  [] ? sandybridge_pcode_write+0x109/0x1f0 
>> [i915]
>> [   15.847459]  [] ? 
>> intel_gen6_powersave_work+0x2a8/0x1400 [i915]
>> [   15.847462]  [] ? process_one_work+0x1eb/0x480
>> [   15.847465]  [] ? worker_thread+0x47/0x4c0
>> [   15.847467]  [] ? __schedule+0x1d7/0x660
>> [   15.847469]  [] ? process_one_work+0x480/0x480
>> [   15.847472]  [] ? kthread+0xbd/0xe0
>> [   15.847475]  [] ? ret_from_fork+0x1f/0x40
>> [   15.847478]  [] ? kthread_worker_fn+0x160/0x160
>> [   15.847487] ---[ end trace ad9e991297d99be1 ]---

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

2016-09-06 Thread Ville Syrjälä
On Sun, Aug 28, 2016 at 05:28:46PM +0200, Andrea Arcangeli wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
> 
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> 
> The Skylake workaround for the regression was introduced in commit
> aeddda06c1a704bb97c8a7bfe7a472120193bd56
> 
> Signed-off-by: Andrea Arcangeli 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index adca262..ca17ab6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   /*
> -  * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> -  * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> -  * vswing instead. Low vswing results in some display flickers, so
> -  * let's simply ignore the OpRegion panel type on SKL for now.
> +  * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> +  * OpRegion panel type (0) gives us low vswing for eDP,
> +  * whereas the VBT panel type (2) gives us normal vswing
> +  * instead. Low vswing results in some display flickers, so
> +  * let's simply ignore the OpRegion panel type on SKL and
> +  * IVYBRIDGE for now.
>*/
> - if (IS_SKYLAKE(dev_priv)) {
> + if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }

Argh. I guess we'll just have to revert the whole opregion panel type thing
and ty to figure out some way to do this only for the system(s) that need it.

Hmm. Can someone test the top commit from [1] on top of the broken kernel?
If we can get an EDID somehow for the panel then the panel type shouldn't
matter that much any more.

[1] git://github.com/vsyrjala/linux.git acpi_edid

-- 
Ville Syrjälä
Intel OTC


i915 WARNING: Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread Jani Nikula

Lyude, this is due to

commit 87660502f1a4d51fb043e89a45d30c9917787c22
Author: Lyude 
Date:   Wed Aug 17 15:55:53 2016 -0400

drm/i915/gen6+: Interpret mailbox error flags

and on its way to stable.

BR,
Jani.


On Mon, 29 Aug 2016, Meelis Roos  wrote:
> Tried 4.8-rc4 on my i5-2400 PC, got this warning:
>
> [   14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   15.847321] [ cut here ]
> [   15.847346] WARNING: CPU: 0 PID: 208 at 
> drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x109/0x1f0 
> [i915]
> [   15.847348] Missing switch case (16) in gen6_check_mailbox_status
> [   15.847349] Modules linked in: cpufreq_powersave cpufreq_userspace 
> cpufreq_conservative joydev hid_generic usbhid hid x86_pkg_temp_thermal 
> kvm_intel kvm irqbypass crc32c_intel aesni_intel snd_hda_codec_realtek 
> snd_hda_codec_generic iTCO_wdt i915 aes_x86_64 iTCO_vendor_support 
> glue_helper lrw ablk_helper cryptd video i2c_algo_bit drm_kms_helper psmouse 
> pcspkr syscopyarea sysfillrect sysimgblt fb_sys_fops ehci_pci ehci_hcd 
> snd_hda_intel xhci_pci xhci_hcd e1000e snd_hda_codec snd_hwdep usbcore drm 
> snd_hda_core usb_common i2c_i801 ptp pps_core i2c_smbus snd_pcm_oss 
> snd_mixer_oss snd_pcm snd_timer evdev snd tpm_tis lpc_ich parport_pc 
> tpm_tis_core mfd_core parport nuvoton_cir rc_core tpm soundcore floppy 
> w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core loop ip_tables x_tables 
> autofs4
> [   15.847395] CPU: 0 PID: 208 Comm: kworker/0:2 Not tainted 4.8.0-rc4 #213
> [   15.847396] Hardware name:  /DQ67OW, BIOS 
> SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
> [   15.847412] Workqueue: events intel_gen6_powersave_work [i915]
> [   15.847414]   812d8198 88023191fd70 
> 
> [   15.847417]  81056d1e 88022ea4 88023191fdc0 
> 
> [   15.847419]  88022ea4a3c8 88022ea487c0 088023e21ba0 
> 81056d8f
> [   15.847422] Call Trace:
> [   15.847427]  [] ? dump_stack+0x46/0x5e
> [   15.847429]  [] ? __warn+0xbe/0xe0
> [   15.847431]  [] ? warn_slowpath_fmt+0x4f/0x60
> [   15.847446]  [] ? sandybridge_pcode_write+0x109/0x1f0 
> [i915]
> [   15.847459]  [] ? intel_gen6_powersave_work+0x2a8/0x1400 
> [i915]
> [   15.847462]  [] ? process_one_work+0x1eb/0x480
> [   15.847465]  [] ? worker_thread+0x47/0x4c0
> [   15.847467]  [] ? __schedule+0x1d7/0x660
> [   15.847469]  [] ? process_one_work+0x480/0x480
> [   15.847472]  [] ? kthread+0xbd/0xe0
> [   15.847475]  [] ? ret_from_fork+0x1f/0x40
> [   15.847478]  [] ? kthread_worker_fn+0x160/0x160
> [   15.847487] ---[ end trace ad9e991297d99be1 ]---

-- 
Jani Nikula, Intel Open Source Technology Center


[Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread Jani Nikula

Lyude, this is due to

commit 87660502f1a4d51fb043e89a45d30c9917787c22
Author: Lyude 
Date:   Wed Aug 17 15:55:53 2016 -0400

drm/i915/gen6+: Interpret mailbox error flags

and on its way to stable.

BR,
Jani.



On Tue, 06 Sep 2016, linux at eikelenboom.it wrote:
> L.S.,
>
> Since one of the last 4.8 RC's i'm getting the warning below when 
> booting on my sandybridge based thinkpad.
>  From what it seems the machine still works fine though.
>
> --
> Sander
>
> [2.846265] [ cut here ]
> [2.846280] WARNING: CPU: 0 PID: 4 at 
> drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write+0x104/0x1e0
> [2.846282] Missing switch case (16) in gen6_check_mailbox_status
> [2.846284] Modules linked in:
> [2.846289] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 
> 4.8.0-rc5-x220-20160905+ #1
> [2.846290] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW 
> (1.39 ) 07/18/2013
> [2.846297] Workqueue: events intel_gen6_powersave_work
> [2.846302]   8138bd84 88030fd7bd78 
> 
> [2.846305]  81062d84 88030d49 88030fd7bdc8 
> 
> [2.846308]  88030d49a438 88030d498830  
> 81062dea
> [2.846309] Call Trace:
> [2.846319]  [] ? dump_stack+0x5c/0x78
> [2.846324]  [] ? __warn+0xb4/0xd0
> [2.846328]  [] ? warn_slowpath_fmt+0x4a/0x50
> [2.846333]  [] ? 
> sandybridge_pcode_write+0x104/0x1e0
> [2.846338]  [] ? 
> intel_gen6_powersave_work+0x2a3/0x1400
> [2.846344]  [] ? process_one_work+0x1ba/0x3d0
> [2.846348]  [] ? worker_thread+0x45/0x4e0
> [2.846351]  [] ? process_one_work+0x3d0/0x3d0
> [2.846355]  [] ? kthread+0xb8/0xd0
> [2.846362]  [] ? ret_from_fork+0x1f/0x40
> [2.846365]  [] ? kthread_worker_fn+0x180/0x180
> [2.846368] ---[ end trace da7b2ca8a6654bfa ]---
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center


[Intel-gfx] Linux 4.8-rc?: WARNING: at drivers/gpu/drm/i915/intel_pm.c:7866 sandybridge_pcode_write Missing switch case (16) in gen6_check_mailbox_status

2016-09-06 Thread li...@eikelenboom.it
On 2016-09-06 11:25, Jani Nikula wrote:
> On Tue, 06 Sep 2016, linux at eikelenboom.it wrote:
>> L.S.,
>> 
>> Since one of the last 4.8 RC's i'm getting the warning below when
>> booting on my sandybridge based thinkpad.
>>  From what it seems the machine still works fine though.
> 
> What does 'lspci -nns 2' say for you?

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller 
[8086:0126] (rev 09)

--
Sander

> BR,
> Jani.
> 
> 
>> 
>> --
>> Sander
>> 
>> [2.846265] [ cut here ]
>> [2.846280] WARNING: CPU: 0 PID: 4 at
>> drivers/gpu/drm/i915/intel_pm.c:7866 
>> sandybridge_pcode_write+0x104/0x1e0
>> [2.846282] Missing switch case (16) in gen6_check_mailbox_status
>> [2.846284] Modules linked in:
>> [2.846289] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted
>> 4.8.0-rc5-x220-20160905+ #1
>> [2.846290] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW
>> (1.39 ) 07/18/2013
>> [2.846297] Workqueue: events intel_gen6_powersave_work
>> [2.846302]   8138bd84 88030fd7bd78
>> 
>> [2.846305]  81062d84 88030d49 88030fd7bdc8
>> 
>> [2.846308]  88030d49a438 88030d498830 
>> 81062dea
>> [2.846309] Call Trace:
>> [2.846319]  [] ? dump_stack+0x5c/0x78
>> [2.846324]  [] ? __warn+0xb4/0xd0
>> [2.846328]  [] ? warn_slowpath_fmt+0x4a/0x50
>> [2.846333]  [] ?
>> sandybridge_pcode_write+0x104/0x1e0
>> [2.846338]  [] ?
>> intel_gen6_powersave_work+0x2a3/0x1400
>> [2.846344]  [] ? process_one_work+0x1ba/0x3d0
>> [2.846348]  [] ? worker_thread+0x45/0x4e0
>> [2.846351]  [] ? process_one_work+0x3d0/0x3d0
>> [2.846355]  [] ? kthread+0xb8/0xd0
>> [2.846362]  [] ? ret_from_fork+0x1f/0x40
>> [2.846365]  [] ? kthread_worker_fn+0x180/0x180
>> [2.846368] ---[ end trace da7b2ca8a6654bfa ]---
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[PATCH 1/3] drm/tilcdc: Take mode config lock while updating the crtc clock rate

2016-09-06 Thread Tomi Valkeinen


On 06/09/16 11:19, Jyri Sarha wrote:
> Take mode config lock while updating the crtc clock rate. To avoid a
> race in tilcdc_crtc_update_clk(), we do not want the mode to change
> while we update crtc clock.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 5 +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index f8892e9..882d9b5 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -184,10 +184,14 @@ static int cpufreq_transition(struct notifier_block *nb,
>  {
>   struct tilcdc_drm_private *priv = container_of(nb,
>   struct tilcdc_drm_private, freq_transition);
> + struct drm_mode_config *config = >dev->mode_config;
> +
>   if (val == CPUFREQ_POSTCHANGE) {
>   if (priv->lcd_fck_rate != clk_get_rate(priv->clk)) {
> + mutex_lock(>mutex);

drm_modeset_lock_crtc()? Or drm_modeset_lock_all() if per-crtc is not
suitable.

 Tomi

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


[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

2016-09-06 Thread kbuild test robot
RT_SYMBOL_GPL(vop_component_ops);
^
>> include/linux/export.h:63:25: error: expected declaration or statement at 
>> end of input
 __visible const struct kernel_symbol __ksymtab_##sym \
^
   include/linux/export.h:94:25: note: in expansion of macro '___EXPORT_SYMBOL'
#define __EXPORT_SYMBOL ___EXPORT_SYMBOL
^
   include/linux/export.h:101:2: note: in expansion of macro '__EXPORT_SYMBOL'
 __EXPORT_SYMBOL(sym, "_gpl")
 ^
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1608:1: note: in expansion of 
macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(vop_component_ops);
^
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c: At top level:
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c:557:13: warning: 
'vop_crtc_disable' defined but not used [-Wunused-function]
static void vop_crtc_disable(struct drm_crtc *crtc)
^

vim +63 include/linux/export.h

f5016932 Paul Gortmaker  2011-05-23  57 extern typeof(sym) sym; 
\
f5016932 Paul Gortmaker  2011-05-23  58 __CRC_SYMBOL(sym, sec)  
\
f5016932 Paul Gortmaker  2011-05-23  59 static const char 
__kstrtab_##sym[] \
f5016932 Paul Gortmaker  2011-05-23  60 
__attribute__((section("__ksymtab_strings"), aligned(1))) \
b92021b0 Rusty Russell   2013-03-15  61 = VMLINUX_SYMBOL_STR(sym);  
\
7b4ec8dd Johannes Berg   2014-01-16  62 extern const struct 
kernel_symbol __ksymtab_##sym;  \
e0f244c6 Andi Kleen  2013-10-23 @63 __visible const struct 
kernel_symbol __ksymtab_##sym\
f5016932 Paul Gortmaker  2011-05-23  64 __used  
\
f5016932 Paul Gortmaker  2011-05-23  65 
__attribute__((section("___ksymtab" sec "+" #sym), unused)) \
f5016932 Paul Gortmaker  2011-05-23  66 = { (unsigned long), 
__kstrtab_##sym }
f5016932 Paul Gortmaker  2011-05-23  67  
c1a95fda Nicolas Pitre   2016-01-22  68  #if defined(__KSYM_DEPS__)
c1a95fda Nicolas Pitre   2016-01-22  69  
c1a95fda Nicolas Pitre   2016-01-22  70  /*
c1a95fda Nicolas Pitre   2016-01-22  71   * For fine grained build 
dependencies, we want to tell the build system
c1a95fda Nicolas Pitre   2016-01-22  72   * about each possible exported symbol 
even if they're not actually exported.
c1a95fda Nicolas Pitre   2016-01-22  73   * We use a string pattern that is 
unlikely to be valid code that the build
c1a95fda Nicolas Pitre   2016-01-22  74   * system filters out from the 
preprocessor output (see ksym_dep_filter
c1a95fda Nicolas Pitre   2016-01-22  75   * in scripts/Kbuild.include).
c1a95fda Nicolas Pitre   2016-01-22  76   */
c1a95fda Nicolas Pitre   2016-01-22  77  #define __EXPORT_SYMBOL(sym, sec)  
=== __KSYM_##sym ===
c1a95fda Nicolas Pitre   2016-01-22  78  
c1a95fda Nicolas Pitre   2016-01-22  79  #elif defined(CONFIG_TRIM_UNUSED_KSYMS)
f2355416 Nicolas Pitre   2016-01-22  80  
f2355416 Nicolas Pitre   2016-01-22  81  #include 
f2355416 Nicolas Pitre   2016-01-22  82  #include 
f2355416 Nicolas Pitre   2016-01-22  83  
f2355416 Nicolas Pitre   2016-01-22  84  #define __EXPORT_SYMBOL(sym, sec)  
\
6023d236 Masahiro Yamada 2016-06-14  85 __cond_export_sym(sym, sec, 
__is_defined(__KSYM_##sym))
f2355416 Nicolas Pitre   2016-01-22  86  #define __cond_export_sym(sym, sec, 
conf)  \
f2355416 Nicolas Pitre   2016-01-22  87 ___cond_export_sym(sym, sec, 
conf)
f2355416 Nicolas Pitre   2016-01-22  88  #define ___cond_export_sym(sym, sec, 
enabled)  \
f2355416 Nicolas Pitre   2016-01-22  89 
__cond_export_sym_##enabled(sym, sec)
f2355416 Nicolas Pitre   2016-01-22  90  #define __cond_export_sym_1(sym, sec) 
___EXPORT_SYMBOL(sym, sec)
f2355416 Nicolas Pitre   2016-01-22  91  #define __cond_export_sym_0(sym, sec) 
/* nothing */
f2355416 Nicolas Pitre   2016-01-22  92  
f2355416 Nicolas Pitre   2016-01-22  93  #else
f2355416 Nicolas Pitre   2016-01-22 @94  #define __EXPORT_SYMBOL 
___EXPORT_SYMBOL
f2355416 Nicolas Pitre   2016-01-22  95  #endif
f2355416 Nicolas Pitre   2016-01-22  96  
f5016932 Paul Gortmaker  2011-05-23  97  #define EXPORT_SYMBOL(sym) 
\

:: The code at line 63 was first introduced by commit
:: e0f244c63fc9d192dfd399cc2677bbdca61994b1 asmlinkage, module: Make 
ksymtab and kcrctab symbols and __this_module __visible

:: TO: Andi Kleen 
:: CC: Rusty Russell 

---
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: 38827 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160906/a4c3cb58/attachment-0001.obj>


[PATCH v4 4/4] gpu: ipu-ic: allow multiple handles to ic

2016-09-06 Thread Philipp Zabel
Am Mittwoch, den 17.08.2016, 17:50 -0700 schrieb Steve Longerbeam:
> The image converter kernel API supports conversion contexts and
> job queues, so we should allow more than one handle to the IC, so
> that multiple users can add jobs to the queue.

The image converter queue can be shared, but hardware access to the IC
task still has to be exclusive (ipu_ic_task_enable/disable/init/etc.)

> Note however that users that control the IC manually (that do not
> use the image converter APIs but setup the IC task by hand via calls
> to ipu_ic_task_enable(), ipu_ic_enable(), etc.) must still be careful not
> to share the IC handle with other threads. At this point, the only user
> that still controls the IC manually is the i.mx capture driver. In that
> case the capture driver only allows one open context to get a handle
> to the IC at a time, so we should be ok there.

The ipu_ic task handles should be kept exclusive. The image conversion
queue API could get its own handle (ipu_ic_queue? basically what is now
struct image_converter) with its own refcounting get/put functions on
top and each queue should take one exclusive reference on its
corresponding IC task while requested.:_:

If the capture code uses FSU channel linking to feed the IC preprocessor
tasks directly from the CSI, the viewfinder and encoder IC tasks should
not be available for the conversion queues to use.

regards
Philipp



[PATCH v4 3/4] gpu: ipu-ic: Add complete image conversion support with tiling

2016-09-06 Thread Philipp Zabel
Hi Steve,

Am Mittwoch, den 17.08.2016, 17:50 -0700 schrieb Steve Longerbeam:
> This patch implements complete image conversion support to ipu-ic,
> with tiling to support scaling to and from images up to 4096x4096.
> Image rotation is also supported.
> 
> The internal API is subsystem agnostic (no V4L2 dependency except
> for the use of V4L2 fourcc pixel formats).
> 
> Callers prepare for image conversion by calling
> ipu_image_convert_prepare(), which initializes the parameters of
> the conversion.

... and possibly allocates intermediate buffers for rotation support.
This should be documented somewhere, with a node that v4l2 users should
be doing this during REQBUFS.

>  The caller passes in the ipu_ic task to use for
> the conversion, the input and output image formats, a rotation mode,
> and a completion callback and completion context pointer:
> 
> struct image_converter_ctx *
> ipu_image_convert_prepare(struct ipu_ic *ic,
>   struct ipu_image *in, struct ipu_image *out,
>   enum ipu_rotate_mode rot_mode,
>   image_converter_cb_t complete,
>   void *complete_context);

As I commented on the other patch, I think the image_convert functions
should use a separate handle for the image conversion queues that sit on
top of the ipu_ic task handles.

> The caller is given a new conversion context that must be passed to
> the further APIs:
> 
> struct image_converter_run *
> ipu_image_convert_run(struct image_converter_ctx *ctx,
>   dma_addr_t in_phys, dma_addr_t out_phys);
> 
> This queues a new image conversion request to a run queue, and
> starts the conversion immediately if the run queue is empty. Only
> the physaddr's of the input and output image buffers are needed,
> since the conversion context was created previously with
> ipu_image_convert_prepare(). Returns a new run object pointer. When
> the conversion completes, the run pointer is returned to the
> completion callback.
>
> void image_convert_abort(struct image_converter_ctx *ctx);
> 
> This will abort any active or pending conversions for this context.
> Any currently active or pending runs belonging to this context are
> returned via the completion callback with an error status.
>
> void ipu_image_convert_unprepare(struct image_converter_ctx *ctx);
> 
> Unprepares the conversion context. Any active or pending runs will
> be aborted by calling image_convert_abort().
> 
> Signed-off-by: Steve Longerbeam 
> 
> ---
> 
> v4:
> - do away with struct ipu_ic_tile_off, and move tile offsets into
>   struct ipu_ic_tile. This paves the way for possibly allowing for
>   each tile to have different dimensions in the future.

Thanks, this looks a lot better to me.

> v3: no changes
> v2: no changes
> ---
>  drivers/gpu/ipu-v3/ipu-ic.c | 1694 
> ++-
>  include/video/imx-ipu-v3.h  |   57 +-
>  2 files changed, 1739 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index 1a37afc..01b1b56 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "ipu-prv.h"
>  
>  /* IC Register Offsets */
> @@ -82,6 +84,40 @@
>  #define IC_IDMAC_3_PP_WIDTH_MASK(0x3ff << 20)
>  #define IC_IDMAC_3_PP_WIDTH_OFFSET  20
>  
> +/*
> + * 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, for a maximum
> + * of 4*4 or 16 tiles. A conversion is then carried out for each
> + * tile (but taking care to pass the full frame stride length to
> + * the DMA channel's parameter memory!). IDMA double-buffering is used
> + * to convert each tile back-to-back when possible (see note below
> + * when double_buffering boolean is set).
> + *
> + * Note that the input frame must be split up into the same number
> + * of tiles as the output frame.
> + */
> +#define MAX_STRIPES_W4
> +#define MAX_STRIPES_H4
> +#define MAX_TILES (MAX_STRIPES_W * MAX_STRIPES_H)
> +
> +#define MIN_W 128
> +#define MIN_H 128

Where does this minimum come from?

> +#define MAX_W 4096
> +#define MAX_H 4096
> +
> +enum image_convert_type {
> + IMAGE_CONVERT_IN = 0,
> + IMAGE_CONVERT_OUT,
> +};
> +
>  struct ic_task_regoffs {
>   u32 rsc;
>   u32 tpmem_csc[2];
> @@ -96,6 +132,16 @@ struct ic_task_bitfields {
>   u32 ic_cmb_galpha_bit;
>  };
>  
> +struct ic_task_channels {
> + int in;
> + int out;
> + int rot_in;
> 

[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4

2016-09-06 Thread Philipp Zabel
Am Montag, den 05.09.2016, 11:41 -0300 schrieb Fabio Estevam:
> Hi Philipp,
> 
> On Thu, Aug 25, 2016 at 11:17 AM, Tim Harvey  wrote:
> 
> > Philipp,
> >
> > Have you had a chance to review this last series of Steve's submitted
> > last week? We are down to 4 patches in gpu/ipu-v3 needed in order to
> > get his IMX5/6 capture driver into staging and the sooner we do that
> > the sooner we can get more testing and additional support/features for
> > it.
> 
> Do these patches look good to you? It would be nice to get them into
> 4.9 if possible.

I have applied all but the IC patches so far. For those I have a few
comments.

regards
Philipp



[Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

2016-09-06 Thread Dave Gordon
On 04/09/16 19:58, Nicolas Iooss wrote:
> When building the kernel with clang and some warning flags, the compiler
> reports that the return value of dcs_get_backlight() may be
> uninitialized:
>
> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable
> 'data' is used uninitialized whenever 'for' loop exits because its
> condition is false [-Werror,-Wsometimes-uninitialized]
> for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
> ^~~
> drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
> 'for_each_dsi_port'
> #define for_each_dsi_port(__port, __ports_mask)
> for_each_port_masked(__port, __ports_mask)
> ^~
> drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
> 'for_each_port_masked'
> for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
> ^
> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
> uninitialized use occurs here
> return data;
>^~~~
>
> As intel_dsi->dcs_backlight_ports seems to be always initialized to a
> non-null value, the content of the for loop is always executed and there
> is no bug in the current code. Nevertheless the compiler has no way of
> knowing that assumption, so initialize variable 'data' to silence the
> warning here.
>
> Signed-off-by: Nicolas Iooss 

Interesting ... there are two things that could lead to this (possibly) 
incorrect analysis. Either it thinks the loop could be executed zero 
times, which would be a deficiency in the compiler, as the initialiser 
and loop bound are both known (different) constants:

enum port {
 PORT_A = 0,
 PORT_B,
 PORT_C,
 PORT_D,
 PORT_E,
 I915_MAX_PORTS
};

or, it doesn't understand that because we've passed  to another 
function, it can have been set by the callee. It may be extra confusing 
that the callee takes (void *); or it may be being ultra-sophisticated 
in its analysis and noted that in one error path data is *not* set (and 
we then discard the error and use data anyway). As an experiment, you 
could try:

static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
 u8 data = 0;

 mipi_dsi_dcs_read(dsi_device, cmd, , sizeof(data));

 return data;
}

static u32 dcs_get_backlight(struct intel_connector *connector)
{
 struct intel_encoder *encoder = connector->encoder;
 struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
 struct mipi_dsi_device *dsi_device;
 enum port port;
 u8 data;

 /* FIXME: Need to take care of 16 bit brightness level */
 for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
 dsi_device = intel_dsi->dsi_hosts[port]->device;
 data = mipi_dsi_dcs_read1(dsi_device, 
MIPI_DCS_GET_DISPLAY_BRIGHTNESS);
 break;
 }

 return data;
}

If it complains about that then it's a shortcoming in the loop analysis. 
If not you could try:

static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 cmd)
{
 u8 data;
ssize_t nbytes = sizeof(data);

nbytes = mipi_dsi_dcs_read(dsi_device, cmd, , nbytes);
return nbytes == sizeof(data) ? data : 0;
}

and if complains about that then it doesn't understand that passing 
 allows it to be set. If it doesn't complain about this version, 
then the original error was actually correct, in the sense that data can 
indeed be used uninitialised if certain error paths can be taken.

Here's an R-b for your fix anyway ...

Reviewed-by: Dave Gordon 

.Dave.

>  drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c 
> b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
> index ac7c6020c443..eec45856f910 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
> @@ -46,7 +46,7 @@ static u32 dcs_get_backlight(struct intel_connector 
> *connector)
>   struct intel_encoder *encoder = connector->encoder;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   struct mipi_dsi_device *dsi_device;
> - u8 data;
> + u8 data = 0;
>   enum port port;
>
>   /* FIXME: Need to take care of 16 bit brightness level */
>



[PATCH 3/3] drm/tilcdc: Add mutex to protect crtc enable and disable routines

2016-09-06 Thread Jyri Sarha
Add mutex to protect crtc enable and disable routines. The
tilcdc_crtc_disable() function waits for frame done interrupt, the
internal data will get out of sync, should another enable arrive while
waiting for the interrupt.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index f9e3da9..ac0a63e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -31,6 +31,7 @@ struct tilcdc_crtc {
const struct tilcdc_panel_info *info;
struct drm_pending_vblank_event *event;
bool enabled;
+   struct mutex enable_lock;
wait_queue_head_t frame_done_wq;
bool frame_done;
spinlock_t irq_lock;
@@ -153,8 +154,10 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

+   mutex_lock(_crtc->enable_lock);
+
if (tilcdc_crtc->enabled)
-   return;
+   goto out;

pm_runtime_get_sync(dev->dev);

@@ -169,6 +172,8 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);

tilcdc_crtc->enabled = true;
+out:
+   mutex_unlock(_crtc->enable_lock);
 }

 void tilcdc_crtc_disable(struct drm_crtc *crtc)
@@ -177,8 +182,10 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;

+   mutex_lock(_crtc->enable_lock);
+
if (!tilcdc_crtc->enabled)
-   return;
+   goto out;

tilcdc_crtc->frame_done = false;
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
@@ -218,6 +225,8 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
tilcdc_crtc->last_vblank = ktime_set(0, 0);

tilcdc_crtc->enabled = false;
+out:
+   mutex_unlock(_crtc->enable_lock);
 }

 static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
@@ -819,6 +828,8 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
drm_flip_work_init(_crtc->unref_work,
"unref", unref_worker);

+   mutex_init(_crtc->enable_lock);
+
spin_lock_init(_crtc->irq_lock);
INIT_WORK(_crtc->recover_work, tilcdc_crtc_recover_work);

-- 
1.9.1



[PATCH 2/3] drm/tilcdc: Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition()

2016-09-06 Thread Jyri Sarha
Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition(). The new
tilcdc_crtc_set_clk() is used in tilcdc_crtc_mode_set_nofb() instead
tilcdc_crtc_update_clk(). New tilcdc_crtc_update_clk() is implemented
using tilcdc_crtc_set_clk() for cpufreq_transition() alone.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 78 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 14 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  1 -
 3 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 84b36fd..f9e3da9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -35,6 +35,8 @@ struct tilcdc_crtc {
bool frame_done;
spinlock_t irq_lock;

+   unsigned int lcd_fck_rate;
+
ktime_t last_vblank;

struct drm_framebuffer *curr_fb;
@@ -324,6 +326,37 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

+static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct tilcdc_drm_private *priv = dev->dev_private;
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   const unsigned clkdiv = 2; /* using a fixed divider of 2 */
+   int ret;
+
+   /* mode.clock is in KHz, set_rate wants parameter in Hz */
+   ret = clk_set_rate(priv->clk, crtc->mode.clock * 1000 * clkdiv);
+   if (ret < 0) {
+   dev_err(dev->dev, "failed to set display clock rate to: %d\n",
+   crtc->mode.clock);
+   return;
+   }
+
+   tilcdc_crtc->lcd_fck_rate = clk_get_rate(priv->clk);
+
+   DBG("lcd_clk=%u, mode clock=%d, div=%u",
+   tilcdc_crtc->lcd_fck_rate, crtc->mode.clock, clkdiv);
+
+   /* Configure the LCD clock divisor. */
+   tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(clkdiv) |
+LCDC_RASTER_MODE);
+
+   if (priv->rev == 2)
+   tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
+   LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
+   LCDC_V2_CORE_CLK_EN);
+}
+
 static void tilcdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -486,7 +519,7 @@ static void tilcdc_crtc_mode_set_nofb(struct drm_crtc *crtc)

set_scanout(crtc, fb);

-   tilcdc_crtc_update_clk(crtc);
+   tilcdc_crtc_set_clk(crtc);

crtc->hwmode = crtc->state->adjusted_mode;
 }
@@ -655,41 +688,22 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
-   unsigned long lcd_clk;
-   const unsigned clkdiv = 2; /* using a fixed divider of 2 */
-   int ret;
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   struct drm_mode_config *config = >dev->mode_config;

-   pm_runtime_get_sync(dev->dev);
+   if (tilcdc_crtc->lcd_fck_rate != clk_get_rate(priv->clk)) {
+   mutex_lock(>mutex);
+   if (tilcdc_crtc_is_on(crtc)) {
+   pm_runtime_get_sync(dev->dev);
+   tilcdc_crtc_disable(crtc);

-   tilcdc_crtc_disable(crtc);
+   tilcdc_crtc_set_clk(crtc);

-   /* mode.clock is in KHz, set_rate wants parameter in Hz */
-   ret = clk_set_rate(priv->clk, crtc->mode.clock * 1000 * clkdiv);
-   if (ret < 0) {
-   dev_err(dev->dev, "failed to set display clock rate to: %d\n",
-   crtc->mode.clock);
-   goto out;
+   tilcdc_crtc_enable(crtc);
+   pm_runtime_put_sync(dev->dev);
+   }
+   mutex_unlock(>mutex);
}
-
-   lcd_clk = clk_get_rate(priv->clk);
-
-   DBG("lcd_clk=%lu, mode clock=%d, div=%u",
-   lcd_clk, crtc->mode.clock, clkdiv);
-
-   /* Configure the LCD clock divisor. */
-   tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(clkdiv) |
-   LCDC_RASTER_MODE);
-
-   if (priv->rev == 2)
-   tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
-   LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
-   LCDC_V2_CORE_CLK_EN);
-
-   if (tilcdc_crtc_is_on(crtc))
-   tilcdc_crtc_enable(crtc);
-
-out:
-   pm_runtime_put_sync(dev->dev);
 }

 #define SYNC_LOST_COUNT_LIMIT 50
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 882d9b5..4af58b7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -184,16 +184,9 @@ static int cpufreq_transition(struct notifier_block *nb,
 {
struct tilcdc_drm_private *priv = container_of(nb,
struct tilcdc_drm_private, freq_transition);
-   

[PATCH 1/3] drm/tilcdc: Take mode config lock while updating the crtc clock rate

2016-09-06 Thread Jyri Sarha
Take mode config lock while updating the crtc clock rate. To avoid a
race in tilcdc_crtc_update_clk(), we do not want the mode to change
while we update crtc clock.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 5 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index f8892e9..882d9b5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -184,10 +184,14 @@ static int cpufreq_transition(struct notifier_block *nb,
 {
struct tilcdc_drm_private *priv = container_of(nb,
struct tilcdc_drm_private, freq_transition);
+   struct drm_mode_config *config = >dev->mode_config;
+
if (val == CPUFREQ_POSTCHANGE) {
if (priv->lcd_fck_rate != clk_get_rate(priv->clk)) {
+   mutex_lock(>mutex);
priv->lcd_fck_rate = clk_get_rate(priv->clk);
tilcdc_crtc_update_clk(priv->crtc);
+   mutex_unlock(>mutex);
}
}

@@ -251,6 +255,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
}

dev->dev_private = priv;
+   priv->dev = dev;

priv->is_componentized =
tilcdc_get_external_components(dev->dev, NULL) > 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index a6e5e6d..6caecfc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -49,6 +49,8 @@
 struct tilcdc_drm_private {
void __iomem *mmio;

+   struct drm_device *dev;
+
struct clk *clk; /* functional clock */
int rev; /* IP revision */

-- 
1.9.1



[PATCH 0/3] drm/tilcdc: Fix cpufreq transition related race + cleanup

2016-09-06 Thread Jyri Sarha
There was a race between mode_set_nofb() and cpufreq_transition()
calling tilcdc_crtc_update_clk() without locking.

The first patch fixes the race in with a minimal change by taking
drm_mode_config mutex for the duration of the clock update.

The second patch goes a step forward and cleans up the clock setting
code a bit.

The third patch should not really be needed, for now. However,
tilcdc_crtc_enable() and -disable() are called from all over the place
and relying on drm to only do one thing at the time may not work
forever. Adding one mutex does not cost too much after all.

BR,
Jyri

Jyri Sarha (3):
  drm/tilcdc: Take mode config lock while updating the crtc clock rate
  drm/tilcdc: Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition()
  drm/tilcdc: Add mutex to protect crtc enable and disable routines

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 93 +++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 11 ++---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  3 +-
 3 files changed, 65 insertions(+), 42 deletions(-)

-- 
1.9.1



[PATCH 4/7] drm/panel: Add Sinlinx SinA33 7" panel

2016-09-06 Thread Thierry Reding
On Mon, Sep 05, 2016 at 10:02:48PM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Sep 05, 2016 at 01:03:03AM +0800, Icenowy Zheng wrote:
> > Hi Everyone,
> > 
> > 01.09.2016, 23:40, "Maxime Ripard" :
> > >  The SinA33 has an unidentified panel. Add the timings for it under a new
> > >  compatible.
> > 
> > 
> > 
> > Excuse me...
> > I will ask a question which is not fully related to the patch here...
> > If I want to add a generic panel for Q8 tablets, what should it be called?
> > "allwinner,q8-lcd-panel-800x480"?
> 
> I guess it's more of a question for Thierry, but it seems like the
> trend is to put the diagonal rather than the resolution in the
> compatibles.

Compatible strings should contain the model number of the panel. There
is no such thing as a "generic panel for Q8 tablets".

Also, how is it that these panels are unidentified? Has nobody tried to
open them up and look at the panel to find a model number?

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


[PATCH 4/7] drm/panel: Add Sinlinx SinA33 7" panel

2016-09-06 Thread Chen-Yu Tsai
On Tue, Sep 6, 2016 at 4:02 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Sep 05, 2016 at 01:03:03AM +0800, Icenowy Zheng wrote:
>> Hi Everyone,
>>
>> 01.09.2016, 23:40, "Maxime Ripard" :
>> >  The SinA33 has an unidentified panel. Add the timings for it under a new
>> >  compatible.
>>
>>
>>
>> Excuse me...
>> I will ask a question which is not fully related to the patch here...
>> If I want to add a generic panel for Q8 tablets, what should it be called?
>> "allwinner,q8-lcd-panel-800x480"?
>
> I guess it's more of a question for Thierry, but it seems like the
> trend is to put the diagonal rather than the resolution in the
> compatibles.

I think Hans (CC-ed) has some q8 tablet that has a 1024x600 LCD.
Both variants are 7". Without the exact model number we would need
the resolution to tell them apart.

ChenYu


[PATCH 5/7] ARM: sun8i: a33: Add display pipeline

2016-09-06 Thread Chen-Yu Tsai
On Tue, Sep 6, 2016 at 4:21 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, Sep 02, 2016 at 02:28:54PM +0800, Chen-Yu Tsai wrote:
>> > +   be0: display-backend at 01e6 {
>> > +   compatible = "allwinner,sun8i-a33-display-backend";
>> > +   reg = <0x01e6 0x1>;
>>
>> Please also list the interrupt, even though we don't use it yet.
>> The manual says it's 127 - 32 = 95.
>
> Yep, you're right.
>
>> > +   sat0: sat at 01e8 {
>> > +   compatible = "allwinner,sun8i-a33-sat";
>> > +   reg = <0x01e8 0x1000>;
>> > +   clocks = < CLK_BUS_SAT>;
>> > +   resets = < RST_BUS_SAT>;
>> > +
>> > +   ports {
>> > +   #address-cells = <1>;
>> > +   #size-cells = <0>;
>> > +
>> > +   sat0_in: port at 0 {
>> > +   #address-cells = <1>;
>> > +   #size-cells = <0>;
>> > +   reg = <0>;
>> > +
>> > +   sat0_in_fe0: endpoint at 0 {
>> > +   reg = <0>;
>> > +   remote-endpoint = 
>> > <_out_sat0>;
>> > +   };
>> > +   };
>> > +
>> > +   sat0_out: port at 1 {
>> > +   #address-cells = <1>;
>> > +   #size-cells = <0>;
>> > +   reg = <1>;
>> > +
>> > +   sat0_out_be0: endpoint at 0 {
>> > +   reg = <0>;
>> > +   remote-endpoint = 
>> > <_in_sat0>;
>> > +   };
>> > +   };
>>
>> I'm worried about the representation here.
>>
>> In the user manuals, the SAT is shown as part of the BE.  Look at it
>> this way: if it did come before the BE and is independent, we
>> shouldn't have to bring the SAT out of reset for simplefb to work.
>
> Indeed.
>
>> For comparison, a similar function unit called "CMU" found on the
>> other post-sun6i SoCs has the same function description as SAT on
>> the A33. It uses the reserved registers at the beginning of the BE
>> address space.
>
> Hmm, ok, so you would essentially, merge the backend and sat nodes?
>
> That wouldn't be very hard to do, i'll do it.

Yes. That is what I propose.

ChenYu


[Bug 100871] radeon fails to initialize one DisplayPort monitor

2016-09-06 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100871

--- Comment #15 from Reg  ---
Hm, I can't edit that last message. Here are a couple of corrections:

Where I showed:
xrandr --output DisplayPort-${1} --mode 1920x1080
sleep 
xrandr --output DisplayPort-${1} --mode 2560x1440

It should have been:
xrandr --output DisplayPort-${1} --mode 1920x1080
sleep 5
xrandr --output DisplayPort-${1} --mode 2560x1440

Where I showed: 
from /module/...
It should have been:
from /sys/module/...

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


[PATCH 0/7] drm/sun4i: Introduce A33 display driver

2016-09-06 Thread Chen-Yu Tsai
On Tue, Sep 6, 2016 at 4:37 AM, Maxime Ripard
 wrote:
> On Sat, Sep 03, 2016 at 09:43:59AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Sep 3, 2016 at 3:06 AM, Maxime Ripard
>>  wrote:
>> > Hi Icenowy,
>> >
>> > On Fri, Sep 02, 2016 at 09:30:05AM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> 01.09.2016, 23:40, "Maxime Ripard" :
>> >> > Hi everyone,
>> >> >
>> >> > This serie introduces the support in the sun4i-drm driver for the A33.
>> >> >
>> >> > Beside the new IPs and special cases for the A33 new IPs, there's
>> >> > nothing really outstanding, and is now at feature parity with the A13.
>> >>
>> >> How can the driver be modified to support LVDS screen?
>> >>
>> >> I have an A33 tablet with a 1024x768 LVDS panel. (iNet D978 Rev2 board,
>> >> which I pushed a dt a few days ago)
>> >
>> > Awesome, I don't have such a screen myself, so feel free to work on
>> > it.
>> >
>> > I haven't looked into the details of LVDS, but it should be something
>> > along the lines of commit 29e57fab97fc ("drm: sun4i: Add RGB output").
>>
>> The implementation might be along the lines of
>>
>>   1. having multiple output ports, each for a different interface type.
>>  (Some platforms go this route)
>>
>> Or
>>
>>   2. having a DT property describe what the output interface is.
>>
>> The RGB/TCON driver would then setup the registers accordingly.
>
> Hmmm, yeah, we would need to adjust the bindings too...
>
> I guess I'd prefer 1), but that would also be the most invasive
> solution. I'm not sure how the DT maintainers feel about that.

I wonder if the TCON could use its 2 channels simultaneously?
Like output to one LCD, then mirror through HDMI/VGA?
The first option would be able to cover this better?

And you still need to add outgoing endpoints for the HDMI block.

In addition we'll have to rework the TV encoder binding as well.

The 2 TV encoders (on the A20) each have four DACs, which map
onto 4 external pins. The address space includes a not so easy
to use mux. More importantly, the binding needs to specify which
pin is used for what signal (RGB, YUV, S/Video, composite).
There seems to be an implicit rule that 1 pin is always used
for composite, and the 3 others RGB, though.


Regards
ChenYu


[PATCH] drm: modify drm_global_item_ref to avoid two times of writing ref->object

2016-09-06 Thread Sean Paul
On Mon, Sep 5, 2016 at 3:00 AM, Huang Rui  wrote:
> In previous drm_global_item_ref, there are two times of writing
> ref->object if item->refcount is 0. So this patch does a minor update
> to put alloc and init ref firstly, and then to modify the item of glob
> array. Use "else" to avoid two times of writing ref->object. It can
> make the code logic more clearly.
>
> Signed-off-by: Huang Rui 
> ---
>  drivers/gpu/drm/drm_global.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_global.c b/drivers/gpu/drm/drm_global.c
> index 3d2e91c..3abe738 100644
> --- a/drivers/gpu/drm/drm_global.c
> +++ b/drivers/gpu/drm/drm_global.c
> @@ -70,25 +70,25 @@ int drm_global_item_ref(struct drm_global_reference *ref)
>
> mutex_lock(>mutex);
> if (item->refcount == 0) {
> -   item->object = kzalloc(ref->size, GFP_KERNEL);
> -   if (unlikely(item->object == NULL)) {
> +   ref->object = kzalloc(ref->size, GFP_KERNEL);
> +   if (unlikely(ref->object == NULL)) {
> ret = -ENOMEM;
> goto out_err;
> }
> -
> -   ref->object = item->object;
> ret = ref->init(ref);
> if (unlikely(ret != 0))
> goto out_err;
>
> -   }
> +   item->object = ref->object;
> +   } else
> +   ref->object = item->object;
> +

You should add the braces to all blocks if they're present in any block.

> ++item->refcount;
> -   ref->object = item->object;
> mutex_unlock(>mutex);
> return 0;
>  out_err:
> mutex_unlock(>mutex);
> -   item->object = NULL;
> +   ref->object = NULL;

It seems like you're leaking memory here. Do you need a
kfree(ref->object) before this?

I think perhaps you can simplify (or maybe streamline is a better
word) things better by unifying the unlock and return. Something like:


diff --git a/drivers/gpu/drm/drm_global.c b/drivers/gpu/drm/drm_global.c
index 3d2e91c..5b255e4 100644
--- a/drivers/gpu/drm/drm_global.c
+++ b/drivers/gpu/drm/drm_global.c
@@ -65,30 +65,31 @@ void drm_global_release(void)

 int drm_global_item_ref(struct drm_global_reference *ref)
 {
-   int ret;
+   int ret = 0;
struct drm_global_item *item = [ref->global_type];

mutex_lock(>mutex);
if (item->refcount == 0) {
-   item->object = kzalloc(ref->size, GFP_KERNEL);
-   if (unlikely(item->object == NULL)) {
+   ref->object = kzalloc(ref->size, GFP_KERNEL);
+   if (unlikely(ref->object == NULL)) {
ret = -ENOMEM;
-   goto out_err;
+   goto out;
}
-
-   ref->object = item->object;
ret = ref->init(ref);
if (unlikely(ret != 0))
goto out_err;
-
+   } else {
+   ref->object = item->object;
}
-   ++item->refcount;
-   ref->object = item->object;
-   mutex_unlock(>mutex);
-   return 0;
+
+   item->refcount++;
+   goto out;
+
 out_err:
+   kfree(ref->object);
+   ref->object = NULL;
+out:
mutex_unlock(>mutex);
-   item->object = NULL;
return ret;
 }
 EXPORT_SYMBOL(drm_global_item_ref);


> return ret;
>  }
>  EXPORT_SYMBOL(drm_global_item_ref);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100871] radeon fails to initialize one DisplayPort monitor

2016-09-06 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100871

Reg  changed:

   What|Removed |Added

 Attachment #231661|0   |1
is obsolete||
 Attachment #231671|0   |1
is obsolete||

--- Comment #14 from Reg  ---
Created attachment 232241
  --> https://bugzilla.kernel.org/attachment.cgi?id=232241=edit
Logs to compare all screens good on boot to some bad on boot

First I have to take one thing back, the radeon.audo=0 definitely makes a
difference and I am not so sure that radeon.apgmode=-1 helps anymore. That
said, things still go wrong. Because the biggest issue here seems to be a lack
of reproducibility and therefore it's almost impossible to track down I went to
the trouble to write a script to gather information.

In the tarred file I found that to see what's different between a good and bad
boot all you have to do is a diff on the files:
./Logs/timing-stripped/filtered-drm/

screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt

screens-0-5-good_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt

Anybody who wanted to also gather comprehensive information for the developers
could take the file ./gather-info-for-diagnostics.sh in the tarred file and
modify as needed for their own system.

That said, below explains in detail what's in the tarred compressed file.

Directory structure
===
. 
└── logs
├── filtered-drm
└── timing-stripped
└── filtered-drm

This structure is as follows:
. 
=
The script that creates the log files and script to turn on any screens
that are off during boot (more on this one later).

./Logs
==
The raw log files the script gathered which include:
dmsg.txt- from dmesg
proc-cmdline.txt- from /proc/cmdline
module-kernel-parameters.txt- from /module/kernel/parameters/*
module-processor-parameters.txt - from
/module/processor/parameters/*
sys-module-radeon-parameters.txt- from /module/radeon/parameters/*
Xorg.0.log.txt  - from /var/log/Xorg.0.log

./Logs/filtered-drm
===
Some of the above raw Log files with lines that do not contain radeon
information removed. Makes it easier to see what's relevant. If you want to
know exactly how the lines were filtered you can look at the script
./gather-info-for-diagnostics.sh.

./Logs/timing-stripped
==
The above raw Log files with the timing at the beginning of each line
removed. This makes using diff programs easier. If you want to know exactly how
this was done you can look at the script ./gather-info-for-diagnostics.sh.

./Logs/timing-stripped/filtered-drm
===
Some of the above raw Log files with the timing at the beginning of each
line removed and lines that do not contain radeon information removed. Again,
makes it easier to see what's relevant.  If you want to know exactly how this
was done you can look at the script ./gather-info-for-diagnostics.sh.


Scripts
===

./gather-info-for-diagnostics.sh

Does all the heavy lifting in gathering the info.

./display-on.sh
---
This was a curious discovery and may make fixing the issue easier. This is
because I found when the script was like this:

xrandr --output DisplayPort-${1} --mode 1920x1080
xrandr --output DisplayPort-${1} --mode 2560x1440

I found that sometimes it would turn the display on but others it would turn it
off. To consistantly turn the display on I had to change it to this:

xrandr --output DisplayPort-${1} --mode 1920x1080
sleep 
xrandr --output DisplayPort-${1} --mode 2560x1440

suggesting there might be a timing problem that needs to be addressed.


File Names
==

File names take the form of:
__.txt
E.g. The file:

screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt

can be broken down to:
screens-0-4-good-5-bad  = The first 5 of the 6 screens came on as
they should during boot but the 6th one (number 5) did not.
kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects
= shows most of the boot command line
dmsg= A key indicating the file contents, from
dmesg in this case
.txt= That is is a text file

If the file starts off with something like this: 
screens-0-5-good-after-5-fixed-with_display-on.sh it means after booting and
logging in I ran the script ./display-on.sh to turn on the display and then

  1   2   >