[PATCH libdrm] xf86drm: correct the OpenBSD DRM_MAJOR define

[Jonathan Gray]

On Mon, Jul 20, 2015 at 05:06:09PM +0100, Emil Velikov wrote:
> On 18 July 2015 at 22:20, Jonathan Gray  wrote:
> > As far as I can tell no OpenBSD platform ever used 81
> > for a drm major.  While the value was added to libdrm in 2003
> > or earlier drm didn't appear in OpenBSD till 2007.
> >
> > Of the OpenBSD platforms that support drm amd64/macppc/sparc64
> > use a major of 87, i386 uses 88.
> >
> > Signed-off-by: Jonathan Gray 
> > ---
> >  xf86drm.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index 7d7f9c7..a2c549c 100644
> > --- a/xf86drm.c
> > +++ b/xf86drm.c
> > @@ -72,9 +72,11 @@
> >  #define DRM_MAJOR 34
> >  #endif
> >
> > -# ifdef __OpenBSD__
> > -#  define DRM_MAJOR 81
> > -# endif
> > +#if defined(__OpenBSD__) && defined(__i386__)
> > +#define DRM_MAJOR 88
> > +#elif defined(__OpenBSD__)
> > +#define DRM_MAJOR 87
> > +#endif
> >
> Bikeshed: any objections if we cascade the ifdef statements ?

Do you mean indent the defines or have the entire block
undef ifdef __OpenBSD__?  Either way would be fine with me.

[PATCH libdrm v2] xf86drm: correct the OpenBSD DRM_MAJOR define

[Jonathan Gray]

As far as I can tell no OpenBSD platform ever used 81
for a drm major.  While the value was added to libdrm in 2003
or earlier drm didn't appear in OpenBSD till 2007.

Of the OpenBSD platforms that support drm amd64/macppc/sparc64
use a major of 87, i386 uses 88.

v2: rearrange ifdefs as suggested by Emil.

Signed-off-by: Jonathan Gray 
---
 xf86drm.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index c365778..47b2af3 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -82,9 +82,13 @@
 #define DRM_MAJOR 34
 #endif

-# ifdef __OpenBSD__
-#  define DRM_MAJOR 81
-# endif
+#ifdef __OpenBSD__
+#ifdef __i386__
+#define DRM_MAJOR 88
+#else
+#define DRM_MAJOR 87
+#endif
+#endif /* __OpenBSD__ */

 #ifndef DRM_MAJOR
 #define DRM_MAJOR 226  /* Linux */
-- 
2.4.5

[PATCH libdrm v2] xf86drm: use the correct device minor names on OpenBSD

[Jonathan Gray]

Add defines for the device minor names and make use of them
in drmGetMinorName() so the correct paths will be used on OpenBSD.

v2: don't add new defines to xf86drm.h to keep them out of the API
as requested by Emil.

Signed-off-by: Jonathan Gray 
---
 xf86drm.c | 16 +---
 xf86drm.h |  7 +++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 4de5210..c365778 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -64,6 +64,16 @@
 #include "xf86drm.h"
 #include "libdrm_macros.h"

+#ifdef __OpenBSD__
+#define DRM_PRIMARY_MINOR_NAME "drm"
+#define DRM_CONTROL_MINOR_NAME "drmC"
+#define DRM_RENDER_MINOR_NAME  "drmR"
+#else
+#define DRM_PRIMARY_MINOR_NAME "card"
+#define DRM_CONTROL_MINOR_NAME "controlD"
+#define DRM_RENDER_MINOR_NAME  "renderD"
+#endif
+
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
defined(__DragonFly__)
 #define DRM_MAJOR 145
 #endif
@@ -548,11 +558,11 @@ static const char *drmGetMinorName(int type)
 {
 switch (type) {
 case DRM_NODE_PRIMARY:
-return "card";
+return DRM_PRIMARY_MINOR_NAME;
 case DRM_NODE_CONTROL:
-return "controlD";
+return DRM_CONTROL_MINOR_NAME;
 case DRM_NODE_RENDER:
-return "renderD";
+return DRM_RENDER_MINOR_NAME;
 default:
 return NULL;
 }
diff --git a/xf86drm.h b/xf86drm.h
index 40c55c9..e3a19dc 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -76,11 +76,18 @@ extern "C" {
(S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH)
 #define DRM_DEV_MODE(S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP)

+#ifdef __OpenBSD__
+#define DRM_DIR_NAME  "/dev"
+#define DRM_DEV_NAME  "%s/drm%d"
+#define DRM_CONTROL_DEV_NAME  "%s/drmC%d"
+#define DRM_RENDER_DEV_NAME  "%s/drmR%d"
+#else
 #define DRM_DIR_NAME  "/dev/dri"
 #define DRM_DEV_NAME  "%s/card%d"
 #define DRM_CONTROL_DEV_NAME  "%s/controlD%d"
 #define DRM_RENDER_DEV_NAME  "%s/renderD%d"
 #define DRM_PROC_NAME "/proc/dri/" /* For backward Linux compatibility */
+#endif

 #define DRM_ERR_NO_DEVICE  (-1001)
 #define DRM_ERR_NO_ACCESS  (-1002)
-- 
2.4.5

[Bug 91386] Tonga HDMI Audio needs CPU load

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

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

--- Comment #2 from Andy Furniss  ---
(In reply to Alex Deucher from comment #1)

> Does audio work ok with the proprietary Linux driver?

No, fglrx on ubuntu 15.04 has the same issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

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

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

--- Comment #4 from Andy Furniss  ---
I tested Xonotic with load over the weekend and it did lock after about 10
minutes - but I then tested without any memory pressure and still managed to
lock, it did take longer.

I got another lock ehile browsing today - there was nothing else happening at
the time, but I had a few minutes earlier compiled llvm and mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 91371] Tonga HDMI Audio none on TV working on monitor - possible eld issue

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

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

--- Comment #8 from Andy Furniss  ---
Created attachment 117268
  --> https://bugs.freedesktop.org/attachment.cgi?id=117268=edit
tv eld ubuntu fglrx

I do get sound from the TV with ubuntu 15.04 and fglrx (with cpu load).

The eld still doesn't quite match eded-decode as only 16 is listed as sample
size but it is different from my OSS setup in that it just lists 

speakers[0x1] FL/FR

rather than the eronious extra "C" in the tv - eld I previously attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v2 3/4] of: Add NVIDIA Tegra VIC binding

[Mikko Perttunen]

On 07/20/2015 08:20 PM, Emil Velikov wrote:
> Hi Mikko,
> 
> On 20 July 2015 at 08:54, Mikko Perttunen  wrote:
>> This adds device tree binding documentation for the Video Image
>> Compositor (VIC) present on Tegra124 and newer SoC's.
>>
>> Signed-off-by: Mikko Perttunen 
>> ---
>>  .../devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 15 
>> +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt 
>> b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
>> index 009f4bf..1328f3f 100644
>> --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
>> +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
>> @@ -240,6 +240,21 @@ of the following host1x client modules:
>>  - dpaux
>>- vdd-supply: phandle of a supply that powers the DisplayPort link
>>
>> +- vic: Video Image Compositor
>> +  - compatible: For Tegra124, must contain "nvidia,tegra124-vic".  
>> Otherwise,
>> +must contain '"nvidia,-vic", "nvidia,tegra124-vic"', where
>> + is tegra132.
> Did you make a typo here, or is "tegra124" string really used to
> identify the tegra132 chips ?

The idea here is that the compatible string must either be
  "nvidia,tegra124-vic"
if the board is a Tegra124 chip. If it's not, the board must be a
Tegra132 (though we probably should add Tegra210 here too) it must be
  "nvidia,tegra132-vic", "nvidia,tegra124-vic"
to indicate that while the hardware is compatible with the Tegra124 VIC
(and thus can use the same driver and we don't need to update the
compatible list in the driver), it is actually the Tegra132 version in
case the driver needs to apply some quirks. Other Tegra bindings use the
same system.

> 
> Thanks
> Emil

Thanks,
Mikko

[Intel-gfx] [PATCH v2] drm/i915: remove unnecessary null test

[Sudip Mukherjee]

On Mon, Jul 20, 2015 at 05:33:50PM +0200, Daniel Vetter wrote:
> On Mon, Jul 20, 2015 at 08:36:01PM +0530, Sudip Mukherjee wrote:
> > While creating the debugfs file we are setting the inode->i_private to
> > dev. That same dev is passed to these functions as private of struct
> > seq_file via single_open(). So at this point it can never be NULL.
> > 
> > Signed-off-by: Sudip Mukherjee 
> > ---
> > 
> > v1 was drm/i915: fix possible null pointer dereference
> 
> There's still one left in i915_displayport_test_active_write.
I left it out intentionally as it was not used via single_open(). Will
include that and send v3.
>Also please mention the commit that introduced these and Cc: the author.
> Also please Cc: Chris since he's commented on v1 of this patch.
sure, Chris was Cc: in v2 and will Cc: him in v3 also.

regards
sudip

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

[Pekka Paalanen]

On Mon, 20 Jul 2015 10:32:31 -0700
Stéphane Marchesin  wrote:

> On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter  wrote:
> > On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
> >> On Mon, 20 Jul 2015 01:58:33 -0700
> >> Stéphane Marchesin  wrote:
> >>
> >> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen  >> > gmail.com> wrote:
> >> > > On Sun, 19 Jul 2015 17:20:32 -0700
> >> > > Stéphane Marchesin  wrote:
> >> > >
> >> > >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen  >> > >> gmail.com> wrote:
> >> > >> >
> >> > >> > On Thu, 16 Jul 2015 20:20:39 +0800
> >> > >> > John Hunter  wrote:
> >> > >> >
> >> > >> > > From: Zhao Junwang 
> >> > >> > >
> >> > >> > > This supports the asynchronous commits, required for page-flipping
> >> > >> > > Since it's virtual hw it's ok to commit async stuff right away, we
> >> > >> > > never have to wait for vblank.
> >> > >> >
> >> > >> > Hi,
> >> > >> >
> >> > >> > in theory, yes. This is what a patch to bochs implemented not too 
> >> > >> > long
> >> > >> > ago, so AFAIK you are only replicating the existing behaviour.
> >> > >> >
> >> > >> > However, if userspace doing an async commit (or sync, I suppose) 
> >> > >> > does
> >> > >> > not incur any waits in the kernel in e.g. sending the page flip 
> >> > >> > event,
> >> > >> > then flip driven programs (e.g. a Wayland compositor, say, Weston)
> >> > >> > will be running its rendering loop as a busy-loop, because the 
> >> > >> > kernel
> >> > >> > does not throttle it to the (virtual) display refresh rate.
> >> > >> >
> >> > >> > This will cause maximal CPU usage and poor user experience as
> >> > >> > everything else needs to fight for CPU time and event dispatch to 
> >> > >> > get
> >> > >> > through, like input.
> >> > >> >
> >> > >> > I would hope someone could do a follow-up to implement a refresh 
> >> > >> > cycle
> >> > >> > emulation based on a clock. Userspace expects page flips to happen 
> >> > >> > at
> >> > >> > most at refresh rate when asking for vblank-synced flips. It's only
> >> > >> > natural for userspace to drive its rendering loop based on the 
> >> > >> > vblank
> >> > >> > cycle.
> >> > >>
> >> > >>
> >> > >> I've been asking myself the same question (for the UDL driver) and I'm
> >> > >> not sure if this policy should go in the kernel. After all, there
> >> > >> could be legitimate reasons for user space to render lots of frames
> >> > >> per second. It seems to me that if user space doesn't want too many
> >> > >> fps, it should just throttle itself.
> >> > >
> >> > > If userspace wants to render lots of frames per second, IMO it should
> >> > > not be using vblank-synced operations in a way that may throttle it.
> >> > > The lots of frames use case is already non-working for the majority of
> >> > > the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right?
> >> > >
> >> > > The problem here I see is that one DRM driver decides to work different
> >> > > to other DRM drivers. All real-hardware DRM drivers, when asked to do
> >> > > vblank-synced update, actually do throttle to the vblank AFAIK.
> >> >
> >> > udl is an exception here. It is (arguably) real hardware but doesn't 
> >> > throttle.
> >> >
> >> > > Is it
> >> > > too much to assume, that the video mode set in a driver (refresh rate)
> >> > > corresponds to the vblank rate which implicitly delays the completion
> >> > > of vblank-sync'd operations to at least the next vblank boundary?
> >> >
> >> > I think it's wrong to make user space think that a vsynced display
> >> > always matches the refresh rate in a world where:
> >> >
> >> > - some displays have variable refresh rates (not just the fancy new
> >> > stuff like g-sync, look for lvds_downclock in the intel driver for
> >> > example, also consider DSI displays)
> >> >
> >> > - some displays have no refresh rate (the ones we are talking about
> >> > here: udl, bochs...)

> > Imo aiming for vrefresh to be accurate is good. For gsync and friends I
> > think we should have an explicit range or flag to make userspace aware of
> > what's going on.
> 
> I think the concept of vrefresh is flawed and not really future-proof
> (I gave a few examples in my previous email). I agree we should keep
> it as legacy, but we should add something else for the more advanced
> cases.

Right, so let's add something new for new hardware features and keep
the existing behavior existing.

I suppose the problem is that the existing behavior is not really
documented so we have to resort to screaming users?

If one does not ask for ASYNC with a page flip, does it mean flipping
on the next vblank, or flipping such that it cannot tear but allowing
techiques like scanline waits?

It used to be reasonable to assume a constant refresh rate apart from
explicit mode changes. Should we keep this assumption the default and
add API to say different?

> >> > > I think, if the driver cannot implement proper semantics (which IMO
> >> > > includes the throttling) for vblank-sync'd operations and it 

[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control

[Shobhit Kumar]

On Fri, Jul 10, 2015 at 6:36 PM, Shobhit Kumar  wrote:
> On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker
>  wrote:
>> [Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm 
>> control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote:
>>
>>> On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote:
>>> > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote:
>>> > > Hi,
>>> > > Next update of the series reviewed at
>>> > > https://lkml.org/lkml/2015/6/22/155
>>> > >
>>> > > Major changes are few review comments from Varka and Ville being 
>>> > > addressed. Also except
>>> > > for intel-gfx patches, all patches reviesion history is moved out of 
>>> > > commit message.
>>> > >
>>> > > Hope this series finally finds its mark.
>>> > >
>>> > > Regards
>>> > > Shobhit
>>> > >
>>> > > Shobhit Kumar (7):
>>> > >   gpiolib: Add support for removing registered consumer lookup table
>>> > >   mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
>>> > > signal
>>> > >   mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
>>> > >   mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
>>> > >   pwm: crc: Add Crystalcove (CRC) PWM driver
>>> > >   drm/i915: Use the CRC gpio for panel enable/disable
>>> > >   drm/i915: Backlight control using CRC PMIC based PWM driver
>>> >
>>> > I think we have r-b/acks on all the patches now. Ok if I pull this in
>>> > through drm-intel.git for 4.3? Or should I make a topic branch with tag
>>> > and then send out pull requests to everyone? Or will each maintainer merge
>>> > on their own since it's all only coupled at runtime anyway? Any of these
>>> > would suit me.
>>>
>>> I forgot to mention that I had a build failure due to
>>> builtin_platform_driver() when I tried this (just changed it to
>>> module_platform_driver() to get past it). So I'm not sure if this
>>> now depends on some tree which isn't included in -nightly...
>>
>> builtin_platform_register does not yet exist in mainline; as Paul (the
>> other one) said earlier.  So you can either open-code what it does for
>> now, or use  module_platform_register.  If you do the latter, then
>> ensure you (temorarily) also include module.h or you risk additional
>> breakage in the future.
>>
>
> Guess its in mainline now. Whats the plan for the merge of these patches ?
>

Do I need to do anything further on these patches ? Daniel can you
help in the next steps.

Regards
Shobhit

[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control

[Daniel Vetter]

On Tue, Jul 21, 2015 at 12:43:48PM +0530, Shobhit Kumar wrote:
> On Fri, Jul 10, 2015 at 6:36 PM, Shobhit Kumar  wrote:
> > On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker
> >  wrote:
> >> [Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm 
> >> control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote:
> >>
> >>> On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote:
> >>> > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote:
> >>> > > Hi,
> >>> > > Next update of the series reviewed at
> >>> > > https://lkml.org/lkml/2015/6/22/155
> >>> > >
> >>> > > Major changes are few review comments from Varka and Ville being 
> >>> > > addressed. Also except
> >>> > > for intel-gfx patches, all patches reviesion history is moved out of 
> >>> > > commit message.
> >>> > >
> >>> > > Hope this series finally finds its mark.
> >>> > >
> >>> > > Regards
> >>> > > Shobhit
> >>> > >
> >>> > > Shobhit Kumar (7):
> >>> > >   gpiolib: Add support for removing registered consumer lookup table
> >>> > >   mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
> >>> > > signal
> >>> > >   mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
> >>> > >   mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based 
> >>> > > PWM
> >>> > >   pwm: crc: Add Crystalcove (CRC) PWM driver
> >>> > >   drm/i915: Use the CRC gpio for panel enable/disable
> >>> > >   drm/i915: Backlight control using CRC PMIC based PWM driver
> >>> >
> >>> > I think we have r-b/acks on all the patches now. Ok if I pull this in
> >>> > through drm-intel.git for 4.3? Or should I make a topic branch with tag
> >>> > and then send out pull requests to everyone? Or will each maintainer 
> >>> > merge
> >>> > on their own since it's all only coupled at runtime anyway? Any of these
> >>> > would suit me.
> >>>
> >>> I forgot to mention that I had a build failure due to
> >>> builtin_platform_driver() when I tried this (just changed it to
> >>> module_platform_driver() to get past it). So I'm not sure if this
> >>> now depends on some tree which isn't included in -nightly...
> >>
> >> builtin_platform_register does not yet exist in mainline; as Paul (the
> >> other one) said earlier.  So you can either open-code what it does for
> >> now, or use  module_platform_register.  If you do the latter, then
> >> ensure you (temorarily) also include module.h or you risk additional
> >> breakage in the future.
> >>
> >
> > Guess its in mainline now. Whats the plan for the merge of these patches ?
> >
> 
> Do I need to do anything further on these patches ? Daniel can you
> help in the next steps.

I'm pulling them into a topic branch and then get it merged through
drm-intel.git. If other maintainers want to I can send them a pull request
for that topic branch too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PULL] drm: atmel-hlcdc: Fix for 4.1

[Boris Brezillon]

Hi Dave,

This pull request contains a bug fix preventing a warning backtrace
when we call drm_vblank_on just after the DRM device
initialization.

Best Regards,

Boris

The following changes since commit e9308884878942c618a42cab122df80fbf458dc9:

  drm/ttm: improve uncached page deallocation. (2015-07-17 18:18:04 +1000)

are available in the git repository at:

  https://github.com/bbrezillon/linux-at91.git 
tags/drm-atmel-hlcdc/fixes-for-4.2

for you to fetch changes up to 8c4b4b0d19880354864f7720ee5e4e7ab11859d2:

  drm: atmel-hlcdc: fix vblank initial state (2015-07-20 22:47:11 +0200)


Boris Brezillon (1):
  drm: atmel-hlcdc: fix vblank initial state

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)

[PULL] drm: atmel-hlcdc: Fix for 4.1

[Boris Brezillon]

On Tue, 21 Jul 2015 09:19:53 +0200
Boris Brezillon  wrote:

This PR is for 4.2 not 4.1.

> Hi Dave,
> 
> This pull request contains a bug fix preventing a warning backtrace
> when we call drm_vblank_on just after the DRM device
> initialization.
> 
> Best Regards,
> 
> Boris
> 
> The following changes since commit e9308884878942c618a42cab122df80fbf458dc9:
> 
>   drm/ttm: improve uncached page deallocation. (2015-07-17 18:18:04 +1000)
> 
> are available in the git repository at:
> 
>   https://github.com/bbrezillon/linux-at91.git 
> tags/drm-atmel-hlcdc/fixes-for-4.2
> 
> for you to fetch changes up to 8c4b4b0d19880354864f7720ee5e4e7ab11859d2:
> 
>   drm: atmel-hlcdc: fix vblank initial state (2015-07-20 22:47:11 +0200)
> 
> 
> Boris Brezillon (1):
>   drm: atmel-hlcdc: fix vblank initial state
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 12 ++--
>  2 files changed, 7 insertions(+), 6 deletions(-)



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

[PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

[Tomasz Figa]

On Fri, Jul 3, 2015 at 7:08 PM, Mark yao  wrote:
> On 2015年07月03日 17:24, Tomasz Figa wrote:
>>
>> On Fri, Jul 3, 2015 at 5:19 PM, Mark yao  wrote:
>>>
>>> On 2015年07月03日 16:02, Tomasz Figa wrote:

 Hi Mark,

 Please see my comments inline.

 On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao 
 wrote:
>
> Win2/3 support 4 area display, but now havn't found a suitable
> way to use it, and it enable by win gate and area gate,
> so default enable area0 gate, so that its behaviour just like a
> win.

 So I assume this means that currently, without those bits set, win2
 and win3 do not work? This would make this patch a fix maybe even with
 a potential backportability.
>>>
>>>
>>> Yes, without this patch, all win2/3 area gate default disabled.
>>> vop_update_plane_event call win enable only enable the win gate.
>>>
>>>
> Signed-off-by: Mark Yao 
>
> ---
> Changes in v2: None
>
>drivers/gpu/drm/rockchip/rockchip_drm_vop.c |6 ++
>1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 40107bb..e001d26 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -337,6 +337,12 @@ static const struct vop_reg_data
> vop_init_reg_table[] = {
>   {DSP_CTRL0, 0x},
>   {WIN0_CTRL0, 0x0080},
>   {WIN1_CTRL0, 0x0080},
> +   /*
> +* Todo: win2/3 support area func, but now havn't found a
> suitable
> +* way to use it, so default enable area0 as a win display.

 TODO: Win2/3 support multiple area function, but we haven't found
 a suitable way to use it yet, so let's just use them as other windows
 with only area 0 enabled.

> +*/
> +   {WIN2_CTRL0, 0x0010},
> +   {WIN3_CTRL0, 0x0010},

 Anyway, is it enough to program those registers one time in
 vop_initial()? Won't they get cleared when VOP is power cycled, e.g.
 in case of DPMS off and on? Maybe instead this could be done in
 vop_update_plane_event() for windows that need it?
>>>
>>> There are two gate for Win2/3,
>>> at VOP_WIN3_CTRL0:
>>>  bit[0], "win3_en"
>>>  this gating all the area.
>>>
>>>  bit[4], win3_mst0_en
>>>  bit[5], win3_mst1_en
>>>  bit[6], win3_mst2_en
>>>  bit[7], win3_mst3_en
>>>  those gate each area.
>>>
>>> This patch default enable win3_mst0_en, so control bit[0]"win3_en" that
>>> cat
>>> power on/off this window.
>>>
>>> vop_update_plane_event()/ vop_disable_plane() only can control
>>> bit[0]"win3_en".
>>>
>>>
>>> So this patch is enough to enable window2/3 area 0.
>>
>> That's right. However, the vop_init_reg_table[] is only used at probe
>> time by vop_initial() and register settings listed there are not
>> applied any time later. If we call DPMS off, which will turn the VOP
>> off and in turn also the whole power domain off, won't the registers
>> be reset to default values (e.g. zeroed)?
>
> Right, the vop registers would be reset to default values when power domain
> off.
>
> But the cursor can works after resume. because the initial value save to the
> regbak cache,
> and cursor area gate, win gate are at the same regs, so it can be restore
> when do cursor enable.
>
> But if we add other regs, this may cause bug, maybe no one restore them.
> So I think we need do like under to force restore all the regs when resume:
> memcpy(vop->regs, vop->regsbak, vop->len);
>

Actually, you're right. The value will be restored on next write to
WINx_CTRL0 using the bit field accessors. So:

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

[Intel-gfx] [PATCH v2] drm/i915: remove unnecessary null test

[Daniel Vetter]

On Tue, Jul 21, 2015 at 12:11:18PM +0530, Sudip Mukherjee wrote:
> On Mon, Jul 20, 2015 at 05:33:50PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 20, 2015 at 08:36:01PM +0530, Sudip Mukherjee wrote:
> > > While creating the debugfs file we are setting the inode->i_private to
> > > dev. That same dev is passed to these functions as private of struct
> > > seq_file via single_open(). So at this point it can never be NULL.
> > > 
> > > Signed-off-by: Sudip Mukherjee 
> > > ---
> > > 
> > > v1 was drm/i915: fix possible null pointer dereference
> > 
> > There's still one left in i915_displayport_test_active_write.
> I left it out intentionally as it was not used via single_open(). Will
> include that and send v3.

Well I didn't even read that far ;-) But ->write can only be called once
you opened the file, which means it will be set up already correctly too.
-Daniel

> >Also please mention the commit that introduced these and Cc: the author.
> > Also please Cc: Chris since he's commented on v1 of this patch.
> sure, Chris was Cc: in v2 and will Cc: him in v3 also.
> 
> regards
> sudip
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH v2] drm/rockchip: vop: remove hardware cursor window

[Tomasz Figa]

On Thu, Jul 2, 2015 at 4:07 PM, Mark Yao  wrote:
> hardware cursor windows only have some fixed size, and not support
> width virtual, when move hardware cursor windows outside of left,
> the display would be wrong, so this window can't for cursor now.
>
> And Tag hardware cursor window as a overlay is wrong, will make
> userspace wrong behaviour.
>
> So just remove the hardware cursor window
>
> Signed-off-by: Mark Yao 
> ---
> Changes in v2:
> remove unused cursor_data struct.
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   11 ---
>  1 file changed, 11 deletions(-)

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz

[PATCH v2 4/5] drm/rockchip: vop: switch cursor plane to window 3

[Tomasz Figa]

I missed it originally, but if it's not too late yet...

On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao  wrote:
> Window 1 support scale and yuv format, it's waste use it for a
> cursor, use window 3 is enough.
>
> Signed-off-by: Mark Yao 
> ---
> Changes in v2: None
>
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index f6ef634..40107bb 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -342,13 +342,14 @@ static const struct vop_reg_data vop_init_reg_table[] = 
> {
>  /*
>   * Note: rk3288 has a dedicated 'cursor' window, however, that window 
> requires
>   * special support to get alpha blending working.  For now, just use overlay
> - * window 1 for the drm cursor.
> + * window 3 for the drm cursor.
> + *

I guess this blank line is not necessary, as pointed on chromium review.

Best regards,
Tomasz

[PATCH] drm: Make the connector dpms callback return a value.

[Maarten Lankhorst]

This is required to properly handle failing dpms calls.
When making a wait in i915 interruptible, I've noticed
that the dpms sequence could fail with -ERESTARTSYS because
it was waiting interruptibly for flips. So from now on
allow drivers to fail in their connector dpms callback.

Encoder and crtc dpms callbacks are unaffected.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 25 +
 drivers/gpu/drm/drm_crtc.c  |  4 ++--
 drivers/gpu/drm/drm_crtc_helper.c   |  6 +++---
 drivers/gpu/drm/nouveau/nouveau_connector.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_dp_mst.c  |  3 ++-
 drivers/gpu/drm/tegra/dsi.c |  3 ++-
 drivers/gpu/drm/tegra/hdmi.c|  5 +++--
 drivers/gpu/drm/tegra/rgb.c |  5 +++--
 drivers/gpu/drm/tegra/sor.c |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |  2 +-
 include/drm/drm_atomic_helper.h |  4 ++--
 include/drm/drm_crtc.h  |  2 +-
 include/drm/drm_crtc_helper.h   |  2 +-
 14 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d5eba80dc39f..7eb6f751445c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1958,8 +1958,8 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
  * ->active state for the corresponding CRTC (if the connector is enabled) and
  *  updates it.
  */
-void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
- int mode)
+int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+int mode)
 {
struct drm_mode_config *config = >dev->mode_config;
struct drm_atomic_state *state;
@@ -1968,6 +1968,7 @@ void drm_atomic_helper_connector_dpms(struct 
drm_connector *connector,
struct drm_connector *tmp_connector;
int ret;
bool active = false;
+   int old_mode = connector->dpms;

if (mode != DRM_MODE_DPMS_ON)
mode = DRM_MODE_DPMS_OFF;
@@ -1976,18 +1977,19 @@ void drm_atomic_helper_connector_dpms(struct 
drm_connector *connector,
crtc = connector->state->crtc;

if (!crtc)
-   return;
+   return 0;

-   /* FIXME: ->dpms has no return value so can't forward the -ENOMEM. */
state = drm_atomic_state_alloc(connector->dev);
if (!state)
-   return;
+   return -ENOMEM;

state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
 retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state))
-   return;
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto fail;
+   }

WARN_ON(!drm_modeset_is_locked(>connection_mutex));

@@ -2006,17 +2008,16 @@ retry:
if (ret != 0)
goto fail;

-   /* Driver takes ownership of state on successful async commit. */
-   return;
+   /* Driver takes ownership of state on successful commit. */
+   return 0;
 fail:
if (ret == -EDEADLK)
goto backoff;

+   connector->dpms = old_mode;
drm_atomic_state_free(state);

-   WARN(1, "Driver bug: Changing ->active failed with ret=%i\n", ret);
-
-   return;
+   return ret;
 backoff:
drm_atomic_state_clear(state);
drm_atomic_legacy_backoff(state);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a717d18e7a97..5c11083dd186 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4869,9 +4869,9 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,

/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
-   if (connector->funcs->dpms)
-   (*connector->funcs->dpms)(connector, (int)value);
ret = 0;
+   if (connector->funcs->dpms)
+   ret = (*connector->funcs->dpms)(connector, (int)value);
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, 
value);

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index d3dfb0ebbeb2..ae5e52f8f5b3 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -763,14 +763,14 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc 
*crtc)
  * state for all encoders and crtcs in the output mesh and calls the ->dpms()
  * callback provided by the driver appropriately.
  */
-void drm_helper_connector_dpms(struct drm_connector *connector, int mode)
+int drm_helper_connector_dpms(struct drm_connector *connector, int mode)
 {
struct 

[PATCH v3 1/6] drm/rockchip: vop: Fix virtual stride calculation

[Mark Yao]

vir_stride need number words of the virtual width, and fb->pitches
save bytes_per_pixel, so just div 4 switch to stride.

Signed-off-by: Mark Yao 
---
Changes in v3:
Adviced by Tomasz Figa
- use more suitable tile for this patch. 

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 4557f33..3558acb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -644,7 +644,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
offset += (src.y1 >> 16) * fb->pitches[0];
yrgb_mst = rk_obj->dma_addr + offset;

-   y_vir_stride = fb->pitches[0] / (fb->bits_per_pixel >> 3);
+   y_vir_stride = fb->pitches[0] >> 2;

/*
 * If this plane update changes the plane's framebuffer, (or more
-- 
1.7.9.5

[PATCH v3 0/6] drm/rockchip: fixes and new features

[Mark Yao]

This series patches are used for yuv image overlay display.

Rockchip vop support NV11, NV16, NV24 yuv format,
and can scale the image scale 1/8 to 8.

Changes in v3:
- make code more readable
- fix some bugs

Changes in v2:
- Uv buffer not support odd offset, align it.
- Fix error display when move yuv image. 
- Fix scale dest info. 
Mark Yao (6):
  drm/rockchip: vop: Fix virtual stride calculation
  drm/rockchip: vop: Fix window dest start point
  drm/rockchip: vop: Add yuv plane support
  drm/rockchip: vop: Default enable win2/3 area0 bit
  drm/rockchip: vop: restore vop registers when resume
  drm/rockchip: vop: support plane scale


-- 
1.7.9.5

[PATCH v3 2/6] drm/rockchip: vop: Fix window dest start point

[Mark Yao]

Dest start point use crtc_x/y is wrong, crtc_x/y is not equal
to dest.x1/y1 at plane scale.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3558acb..c7e0283 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -634,11 +634,9 @@ static int vop_update_plane_event(struct drm_plane *plane,

actual_w = (src.x2 - src.x1) >> 16;
actual_h = (src.y2 - src.y1) >> 16;
-   crtc_x = max(0, crtc_x);
-   crtc_y = max(0, crtc_y);

-   dsp_stx = crtc_x + crtc->mode.htotal - crtc->mode.hsync_start;
-   dsp_sty = crtc_y + crtc->mode.vtotal - crtc->mode.vsync_start;
+   dsp_stx = dest.x1 + crtc->mode.htotal - crtc->mode.hsync_start;
+   dsp_sty = dest.y1 + crtc->mode.vtotal - crtc->mode.vsync_start;

offset = (src.x1 >> 16) * (fb->bits_per_pixel >> 3);
offset += (src.y1 >> 16) * fb->pitches[0];
-- 
1.7.9.5

[PATCH v3 3/6] drm/rockchip: vop: Add yuv plane support

[Mark Yao]

vop support yuv with NV12, NV16 and NV24, only 2 plane yuv.

Signed-off-by: Mark Yao 
---
Changes in v3:
Adviced by Tomasz Figa
- separate dest calculate to another patch
- fix src x1,x2 when do align, and remove unnecessary src.y1 align.

Changes in v2:
- Uv buffer not support odd offset, align it.
- Fix error display when move yuv image.  

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   56 ++-
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7e0283..47ce943 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -373,6 +373,18 @@ static enum vop_data_format vop_convert_format(uint32_t 
format)
}
 }

+static bool is_yuv_support(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV24:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static bool is_alpha_support(uint32_t format)
 {
switch (format) {
@@ -577,16 +589,21 @@ static int vop_update_plane_event(struct drm_plane *plane,
struct vop *vop = to_vop(crtc);
struct drm_gem_object *obj;
struct rockchip_gem_object *rk_obj;
+   struct drm_gem_object *uv_obj;
+   struct rockchip_gem_object *rk_uv_obj;
unsigned long offset;
unsigned int actual_w;
unsigned int actual_h;
unsigned int dsp_stx;
unsigned int dsp_sty;
unsigned int y_vir_stride;
+   unsigned int uv_vir_stride = 0;
dma_addr_t yrgb_mst;
+   dma_addr_t uv_mst = 0;
enum vop_data_format format;
uint32_t val;
bool is_alpha;
+   bool is_yuv;
bool visible;
int ret;
struct drm_rect dest = {
@@ -620,6 +637,8 @@ static int vop_update_plane_event(struct drm_plane *plane,
return 0;

is_alpha = is_alpha_support(fb->pixel_format);
+   is_yuv = is_yuv_support(fb->pixel_format);
+
format = vop_convert_format(fb->pixel_format);
if (format < 0)
return format;
@@ -632,18 +651,47 @@ static int vop_update_plane_event(struct drm_plane *plane,

rk_obj = to_rockchip_obj(obj);

+   if (is_yuv) {
+   /*
+* Src.x1 can be odd when do clip, but yuv plane start point
+* need align with 2 pixel.
+*/
+   val = (src.x1 >> 16) % 2;
+   src.x1 += val << 16;
+   src.x2 += val << 16;
+   }
+
actual_w = (src.x2 - src.x1) >> 16;
actual_h = (src.y2 - src.y1) >> 16;

dsp_stx = dest.x1 + crtc->mode.htotal - crtc->mode.hsync_start;
dsp_sty = dest.y1 + crtc->mode.vtotal - crtc->mode.vsync_start;

-   offset = (src.x1 >> 16) * (fb->bits_per_pixel >> 3);
+   offset = (src.x1 >> 16) * drm_format_plane_cpp(fb->pixel_format, 0);
offset += (src.y1 >> 16) * fb->pitches[0];
-   yrgb_mst = rk_obj->dma_addr + offset;

+   yrgb_mst = rk_obj->dma_addr + offset + fb->offsets[0];
y_vir_stride = fb->pitches[0] >> 2;

+   if (is_yuv) {
+   int hsub = drm_format_horz_chroma_subsampling(fb->pixel_format);
+   int vsub = drm_format_vert_chroma_subsampling(fb->pixel_format);
+   int bpp = drm_format_plane_cpp(fb->pixel_format, 1);
+
+   uv_obj = rockchip_fb_get_gem_obj(fb, 1);
+   if (!uv_obj) {
+   DRM_ERROR("fail to get uv object from framebuffer\n");
+   return -EINVAL;
+   }
+   rk_uv_obj = to_rockchip_obj(uv_obj);
+   uv_vir_stride = fb->pitches[1] >> 2;
+
+   offset = (src.x1 >> 16) * bpp / hsub;
+   offset += (src.y1 >> 16) * fb->pitches[1] / vsub;
+
+   uv_mst = rk_uv_obj->dma_addr + offset + fb->offsets[1];
+   }
+
/*
 * If this plane update changes the plane's framebuffer, (or more
 * precisely, if this update has a different framebuffer than the last
@@ -679,6 +727,10 @@ static int vop_update_plane_event(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, y_vir_stride);
VOP_WIN_SET(vop, win, yrgb_mst, yrgb_mst);
+   if (is_yuv) {
+   VOP_WIN_SET(vop, win, uv_vir, uv_vir_stride);
+   VOP_WIN_SET(vop, win, uv_mst, uv_mst);
+   }
val = (actual_h - 1) << 16;
val |= (actual_w - 1) & 0x;
VOP_WIN_SET(vop, win, act_info, val);
-- 
1.7.9.5

[PATCH v3 4/6] drm/rockchip: vop: Default enable win2/3 area0 bit

[Mark Yao]

Win2/3 support multiple area function, but we haven't found
a suitable way to use it yet, so let's just use them as other windows
with only area 0 enabled.

Signed-off-by: Mark Yao 
---
Changes in v3:
Adviced by Tomasz Figa
- fix patch comments.
Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 47ce943..e08f318 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -276,6 +276,12 @@ static const struct vop_reg_data vop_init_reg_table[] = {
{DSP_CTRL0, 0x},
{WIN0_CTRL0, 0x0080},
{WIN1_CTRL0, 0x0080},
+   /* TODO: Win2/3 support multiple area function, but we haven't found
+* a suitable way to use it yet, so let's just use them as other windows
+* with only area 0 enabled.
+*/
+   {WIN2_CTRL0, 0x0010},
+   {WIN3_CTRL0, 0x0010},
 };

 /*
-- 
1.7.9.5

[PATCH v3 5/6] drm/rockchip: vop: restore vop registers when resume

[Mark Yao]

The registers will be reset to default values when whole
power domain off, so restore registers from regsbak.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e08f318..4dfad065 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -475,6 +475,7 @@ static void vop_enable(struct drm_crtc *crtc)
goto err_disable_aclk;
}

+   memcpy(vop->regs, vop->regsbak, vop->len);
/*
 * At here, vop clock & iommu is enable, R/W vop regs would be safe.
 */
-- 
1.7.9.5

[PATCH v3 6/6] drm/rockchip: vop: support plane scale

[Mark Yao]

Win_full support 1/8 to 8 scale down/up engine, support
all format scale.

Signed-off-by: Mark Yao 
---
Changes in v3:
Adviced by Tomasz Figa
- remove unused code and unnecessary scale path.
- use static inline funcion instead "#define", let gcc check the cast
- move same call into helper, make code clean.

Changes in v2:
- Fix scale dest info. 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  196 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   87 
 2 files changed, 281 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 4dfad065..8257e98 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -49,6 +49,8 @@

 #define VOP_WIN_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->name, v, RELAXED)
+#define VOP_SCL_SET(x, win, name, v) \
+   REG_SET(x, win->base, win->phy->scl->name, v, RELAXED)
 #define VOP_CTRL_SET(x, name, v) \
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)

@@ -163,7 +165,37 @@ struct vop_ctrl {
struct vop_reg vpost_st_end;
 };

+struct vop_scl_regs {
+   struct vop_reg cbcr_vsd_mode;
+   struct vop_reg cbcr_vsu_mode;
+   struct vop_reg cbcr_hsd_mode;
+   struct vop_reg cbcr_ver_scl_mode;
+   struct vop_reg cbcr_hor_scl_mode;
+   struct vop_reg yrgb_vsd_mode;
+   struct vop_reg yrgb_vsu_mode;
+   struct vop_reg yrgb_hsd_mode;
+   struct vop_reg yrgb_ver_scl_mode;
+   struct vop_reg yrgb_hor_scl_mode;
+   struct vop_reg line_load_mode;
+   struct vop_reg cbcr_axi_gather_num;
+   struct vop_reg yrgb_axi_gather_num;
+   struct vop_reg vsd_cbcr_gt2;
+   struct vop_reg vsd_cbcr_gt4;
+   struct vop_reg vsd_yrgb_gt2;
+   struct vop_reg vsd_yrgb_gt4;
+   struct vop_reg bic_coe_sel;
+   struct vop_reg cbcr_axi_gather_en;
+   struct vop_reg yrgb_axi_gather_en;
+
+   struct vop_reg lb_mode;
+   struct vop_reg scale_yrgb_x;
+   struct vop_reg scale_yrgb_y;
+   struct vop_reg scale_cbcr_x;
+   struct vop_reg scale_cbcr_y;
+};
+
 struct vop_win_phy {
+   const struct vop_scl_regs *scl;
const uint32_t *data_formats;
uint32_t nformats;

@@ -212,7 +244,36 @@ static const uint32_t formats_234[] = {
DRM_FORMAT_RGB565,
 };

+static const struct vop_scl_regs win_full_scl = {
+   .cbcr_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 31),
+   .cbcr_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 30),
+   .cbcr_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 28),
+   .cbcr_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 26),
+   .cbcr_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 24),
+   .yrgb_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 23),
+   .yrgb_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 22),
+   .yrgb_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 20),
+   .yrgb_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 18),
+   .yrgb_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 16),
+   .line_load_mode = VOP_REG(WIN0_CTRL1, 0x1, 15),
+   .cbcr_axi_gather_num = VOP_REG(WIN0_CTRL1, 0x7, 12),
+   .yrgb_axi_gather_num = VOP_REG(WIN0_CTRL1, 0xf, 8),
+   .vsd_cbcr_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 7),
+   .vsd_cbcr_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 6),
+   .vsd_yrgb_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 5),
+   .vsd_yrgb_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 4),
+   .bic_coe_sel = VOP_REG(WIN0_CTRL1, 0x3, 2),
+   .cbcr_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 1),
+   .yrgb_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 0),
+   .lb_mode = VOP_REG(WIN0_CTRL0, 0x7, 5),
+   .scale_yrgb_x = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+   .scale_yrgb_y = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 16),
+   .scale_cbcr_x = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+   .scale_cbcr_y = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
 static const struct vop_win_phy win01_data = {
+   .scl = _full_scl,
.data_formats = formats_01,
.nformats = ARRAY_SIZE(formats_01),
.enable = VOP_REG(WIN0_CTRL0, 0x1, 0),
@@ -401,6 +462,126 @@ static bool is_alpha_support(uint32_t format)
}
 }

+static uint16_t scl_vop_cal_scale(enum scale_mode mode, uint32_t src,
+ uint32_t dst, int scan_type,
+ int vsu_mode, int *vskiplines)
+{
+   uint16_t val = 1 << SCL_FT_DEFAULT_FIXPOINT_SHIFT;
+
+   if (scan_type == 0) {
+   if (mode == SCALE_UP)
+   val = GET_SCL_FT_BIC(src, dst);
+   else if (mode == SCALE_DOWN)
+   val = GET_SCL_FT_BILI_DN(src, dst);
+   } else {
+   if (mode == SCALE_UP) {
+   if (vsu_mode == SCALE_UP_BIL)
+   val = GET_SCL_FT_BILI_UP(src, dst);
+   else
+   val = GET_SCL_FT_BIC(src, dst);
+   } else if 

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

[Daniel Vetter]

On Tue, Jul 21, 2015 at 10:06:09AM +0300, Pekka Paalanen wrote:
> On Mon, 20 Jul 2015 10:32:31 -0700
> Stéphane Marchesin  wrote:
> 
> > On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter  wrote:
> > > On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
> > >> On Mon, 20 Jul 2015 01:58:33 -0700
> > >> Stéphane Marchesin  wrote:
> > >>
> > >> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen  > >> > gmail.com> wrote:
> > >> > > On Sun, 19 Jul 2015 17:20:32 -0700
> > >> > > Stéphane Marchesin  wrote:
> > >> > >
> > >> > >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen  > >> > >> gmail.com> wrote:
> > >> > >> >
> > >> > >> > On Thu, 16 Jul 2015 20:20:39 +0800
> > >> > >> > John Hunter  wrote:
> > >> > >> >
> > >> > >> > > From: Zhao Junwang 
> > >> > >> > >
> > >> > >> > > This supports the asynchronous commits, required for 
> > >> > >> > > page-flipping
> > >> > >> > > Since it's virtual hw it's ok to commit async stuff right away, 
> > >> > >> > > we
> > >> > >> > > never have to wait for vblank.
> > >> > >> >
> > >> > >> > Hi,
> > >> > >> >
> > >> > >> > in theory, yes. This is what a patch to bochs implemented not too 
> > >> > >> > long
> > >> > >> > ago, so AFAIK you are only replicating the existing behaviour.
> > >> > >> >
> > >> > >> > However, if userspace doing an async commit (or sync, I suppose) 
> > >> > >> > does
> > >> > >> > not incur any waits in the kernel in e.g. sending the page flip 
> > >> > >> > event,
> > >> > >> > then flip driven programs (e.g. a Wayland compositor, say, Weston)
> > >> > >> > will be running its rendering loop as a busy-loop, because the 
> > >> > >> > kernel
> > >> > >> > does not throttle it to the (virtual) display refresh rate.
> > >> > >> >
> > >> > >> > This will cause maximal CPU usage and poor user experience as
> > >> > >> > everything else needs to fight for CPU time and event dispatch to 
> > >> > >> > get
> > >> > >> > through, like input.
> > >> > >> >
> > >> > >> > I would hope someone could do a follow-up to implement a refresh 
> > >> > >> > cycle
> > >> > >> > emulation based on a clock. Userspace expects page flips to 
> > >> > >> > happen at
> > >> > >> > most at refresh rate when asking for vblank-synced flips. It's 
> > >> > >> > only
> > >> > >> > natural for userspace to drive its rendering loop based on the 
> > >> > >> > vblank
> > >> > >> > cycle.
> > >> > >>
> > >> > >>
> > >> > >> I've been asking myself the same question (for the UDL driver) and 
> > >> > >> I'm
> > >> > >> not sure if this policy should go in the kernel. After all, there
> > >> > >> could be legitimate reasons for user space to render lots of frames
> > >> > >> per second. It seems to me that if user space doesn't want too many
> > >> > >> fps, it should just throttle itself.
> > >> > >
> > >> > > If userspace wants to render lots of frames per second, IMO it should
> > >> > > not be using vblank-synced operations in a way that may throttle it.
> > >> > > The lots of frames use case is already non-working for the majority 
> > >> > > of
> > >> > > the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right?
> > >> > >
> > >> > > The problem here I see is that one DRM driver decides to work 
> > >> > > different
> > >> > > to other DRM drivers. All real-hardware DRM drivers, when asked to do
> > >> > > vblank-synced update, actually do throttle to the vblank AFAIK.
> > >> >
> > >> > udl is an exception here. It is (arguably) real hardware but doesn't 
> > >> > throttle.
> > >> >
> > >> > > Is it
> > >> > > too much to assume, that the video mode set in a driver (refresh 
> > >> > > rate)
> > >> > > corresponds to the vblank rate which implicitly delays the completion
> > >> > > of vblank-sync'd operations to at least the next vblank boundary?
> > >> >
> > >> > I think it's wrong to make user space think that a vsynced display
> > >> > always matches the refresh rate in a world where:
> > >> >
> > >> > - some displays have variable refresh rates (not just the fancy new
> > >> > stuff like g-sync, look for lvds_downclock in the intel driver for
> > >> > example, also consider DSI displays)
> > >> >
> > >> > - some displays have no refresh rate (the ones we are talking about
> > >> > here: udl, bochs...)
> 
> > > Imo aiming for vrefresh to be accurate is good. For gsync and friends I
> > > think we should have an explicit range or flag to make userspace aware of
> > > what's going on.
> > 
> > I think the concept of vrefresh is flawed and not really future-proof
> > (I gave a few examples in my previous email). I agree we should keep
> > it as legacy, but we should add something else for the more advanced
> > cases.
> 
> Right, so let's add something new for new hardware features and keep
> the existing behavior existing.
> 
> I suppose the problem is that the existing behavior is not really
> documented so we have to resort to screaming users?
> 
> If one does not ask for ASYNC with a page flip, does it mean flipping
> on the next vblank, or flipping such that it 

[PATCH] tests: modetest: Accept connector names in addition to connector IDs

[Thierry Reding]

On Mon, Jul 20, 2015 at 07:56:20PM +0300, Laurent Pinchart wrote:
> From: Thierry Reding 
> 
> Allow connector names to be used in the specification of the -s option.
> This requires storing the string passed on the command-line so that it
> can later be resolved to a connector ID (after the DRM device has been
> opened).
> 
> Connector names are constructed from the connector type name and
> connector type ID using the same format as used internally in the
> Linux kernel.
> 
> Signed-off-by: Thierry Reding 
> Signed-off-by: Laurent Pinchart 
> ---
>  tests/modetest/modetest.c | 94 
> +--
>  1 file changed, 82 insertions(+), 12 deletions(-)
> 
> I've carried this patch in my tree for too long and I'm now tired of rebasing
> it. It's thus time to get it in mainline.
> 
> Compared to the original version developed by Thierry, I've
> 
> - rebased the patch on top of latest master
> - dropped dependencies on other WIP patches in Thierry's tree
> - fixed printf alignment
> - used asprintf to simplify name string allocation
> - constructed the connector name using the same format as the Linux kernel

Heh, I started to get all these patches into shape last week, and this
will probably give me more rebase headaches. But I guess that's what I
deserve for letting things slide...

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

[PATCH v2] drm: Make the connector dpms callback return a value, v2.

[Maarten Lankhorst]

This is required to properly handle failing dpms calls.
When making a wait in i915 interruptible, I've noticed
that the dpms sequence could fail with -ERESTARTSYS because
it was waiting interruptibly for flips. So from now on
allow drivers to fail in their connector dpms callback.

Encoder and crtc dpms callbacks are unaffected.

Changes since v1:
- Update kerneldoc for the drm helper functions.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d5eba80dc39f..0ea8c5d476ef 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1957,9 +1957,12 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
  * implementing the legacy DPMS connector interface. It computes the new 
desired
  * ->active state for the corresponding CRTC (if the connector is enabled) and
  *  updates it.
+ *
+ * Returns:
+ * Returns 0 on success, negative errno numbers on failure.
  */
-void drm_atomic_helper_connector_dpms(struct drm_connector *connector,
- int mode)
+int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
+int mode)
 {
struct drm_mode_config *config = >dev->mode_config;
struct drm_atomic_state *state;
@@ -1968,6 +1971,7 @@ void drm_atomic_helper_connector_dpms(struct 
drm_connector *connector,
struct drm_connector *tmp_connector;
int ret;
bool active = false;
+   int old_mode = connector->dpms;

if (mode != DRM_MODE_DPMS_ON)
mode = DRM_MODE_DPMS_OFF;
@@ -1976,18 +1980,19 @@ void drm_atomic_helper_connector_dpms(struct 
drm_connector *connector,
crtc = connector->state->crtc;

if (!crtc)
-   return;
+   return 0;

-   /* FIXME: ->dpms has no return value so can't forward the -ENOMEM. */
state = drm_atomic_state_alloc(connector->dev);
if (!state)
-   return;
+   return -ENOMEM;

state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
 retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state))
-   return;
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto fail;
+   }

WARN_ON(!drm_modeset_is_locked(>connection_mutex));

@@ -2006,17 +2011,16 @@ retry:
if (ret != 0)
goto fail;

-   /* Driver takes ownership of state on successful async commit. */
-   return;
+   /* Driver takes ownership of state on successful commit. */
+   return 0;
 fail:
if (ret == -EDEADLK)
goto backoff;

+   connector->dpms = old_mode;
drm_atomic_state_free(state);

-   WARN(1, "Driver bug: Changing ->active failed with ret=%i\n", ret);
-
-   return;
+   return ret;
 backoff:
drm_atomic_state_clear(state);
drm_atomic_legacy_backoff(state);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a717d18e7a97..5c11083dd186 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4869,9 +4869,9 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,

/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
-   if (connector->funcs->dpms)
-   (*connector->funcs->dpms)(connector, (int)value);
ret = 0;
+   if (connector->funcs->dpms)
+   ret = (*connector->funcs->dpms)(connector, (int)value);
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, 
value);

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index d3dfb0ebbeb2..a859e192e19d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -762,15 +762,18 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc 
*crtc)
  * implementing the DPMS connector attribute. It computes the new desired DPMS
  * state for all encoders and crtcs in the output mesh and calls the ->dpms()
  * callback provided by the driver appropriately.
+ *
+ * Returns:
+ * Always returns 0.
  */
-void drm_helper_connector_dpms(struct drm_connector *connector, int mode)
+int drm_helper_connector_dpms(struct drm_connector *connector, int mode)
 {
struct drm_encoder *encoder = connector->encoder;
struct drm_crtc *crtc = encoder ? encoder->crtc : NULL;
int old_dpms, encoder_dpms = DRM_MODE_DPMS_OFF;

if (mode == connector->dpms)
-   return;
+   return 0;

old_dpms = connector->dpms;
connector->dpms = mode;
@@ -802,7 +805,7 @@ void drm_helper_connector_dpms(struct drm_connector 
*connector, int mode)
}
}

-   return;
+   return 0;
 }
 

[PATCH 10/16] drm/i915: Add set_property handler for pipe Gamma correction on CHV/BSW

[Malladi, Kausal]

On Tuesday 21 July 2015 05:33 AM, Matt Roper wrote:
> On Wed, Jul 15, 2015 at 06:39:34PM +0530, Kausal Malladi wrote:
>> This patch adds set_property handler for Gamma color correction and
>> enhancement capability at Pipe level on CHV/BSW platform. The set
>> function just attaches the Gamma blob to CRTC state, that later gets
>> committed using atomic path.
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>   drivers/gpu/drm/i915/intel_atomic.c|  7 +++
>>   drivers/gpu/drm/i915/intel_color_manager.c | 19 +++
>>   drivers/gpu/drm/i915/intel_drv.h   |  3 +++
>>   3 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index d873bda..72d6b37 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -473,6 +473,13 @@ int intel_crtc_atomic_set_property(struct drm_crtc 
>> *crtc,
>> struct drm_property *property,
>> uint64_t val)
>>   {
>> +struct drm_device *dev = crtc->dev;
>> +struct drm_mode_config *config = >mode_config;
>> +
>> +if (property == config->prop_palette_after_ctm)
>> +return intel_color_manager_set_pipe_gamma(dev, state,
>> +>base, val);
>> +
>>  DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
>>  return -EINVAL;
>>   }
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> index def20d0f..70c0d42 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -27,6 +27,25 @@
>>   
>>   #include "intel_color_manager.h"
>>   
>> +int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
>> +struct drm_crtc_state *crtc_state,
>> +struct drm_mode_object *obj, uint32_t blob_id)
>> +{
>> +struct drm_property_blob *blob;
>> +
>> +blob = drm_property_lookup_blob(dev, blob_id);
>> +if (!blob) {
>> +DRM_ERROR("Invalid Blob ID\n");
>> +return -EINVAL;
>> +}
> I'm not terribly familiar the semantics of the color correction
> stuff...this prevents userspace from removing the gamma setting by
> passing a 0; is that expected that gamma can't be disabled once set?
> Same question for your degamma patch later in the series.
If you mean to say this is preventing user space from disabling gamma, 
we have another provision for the same. During set property, if 
num_samples is 0 in the blob that was passed, it will disable gamma 
correction.

This check is just preventing user space to pass garbage blob ID.

Thanks
Kausal
>
> Matt
>
>> +
>> +if (crtc_state->palette_after_ctm_blob)
>> +
>> drm_property_unreference_blob(crtc_state->palette_after_ctm_blob);
>> +
>> +crtc_state->palette_after_ctm_blob = blob;
>> +return 0;
>> +}
>> +
>>   int get_chv_pipe_gamma_capabilities(struct drm_device *dev,
>>  struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
>>   {
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 1e61036..45c42f0 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1453,5 +1453,8 @@ extern const struct drm_plane_helper_funcs 
>> intel_plane_helper_funcs;
>>   /* intel_color_manager.c */
>>   void intel_attach_color_properties_to_crtc(struct drm_device *dev,
>>  struct drm_mode_object *mode_obj);
>> +int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
>> +struct drm_crtc_state *crtc_state,
>> +struct drm_mode_object *obj, uint32_t blob_id);
>>   
>>   #endif /* __INTEL_DRV_H__ */
>> -- 
>> 2.4.5
>>

[PATCH 11/16] drm/i915: Add pipe level Gamma correction for CHV/BSW

[Malladi, Kausal]

On Tuesday 21 July 2015 05:33 AM, Matt Roper wrote:
> On Wed, Jul 15, 2015 at 06:39:35PM +0530, Kausal Malladi wrote:
>> CHV/BSW platform supports various Gamma correction modes, which are:
>> 1. Legacy 8-bit mode
>> 2. 10-bit CGM (Color Gamut Mapping) mode
>>
>> This patch does the following:
>> 1. Adds the core function to program Gamma correction values for CHV/BSW
>> platform
>> 2. Adds Gamma correction macros/defines
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>   drivers/gpu/drm/i915/i915_reg.h|  12 +++
>>   drivers/gpu/drm/i915/intel_color_manager.c | 149 
>> +
>>   drivers/gpu/drm/i915/intel_color_manager.h |  20 
>>   drivers/gpu/drm/i915/intel_display.c   |   3 +
>>   drivers/gpu/drm/i915/intel_drv.h   |   2 +
>>   5 files changed, 186 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 059de0f..4ec2e4f 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7906,4 +7906,16 @@ enum skl_disp_power_wells {
>>   #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
>>   #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
>>   
>> +/* Color Management */
>> +#define PIPEA_CGM_CONTROL   (VLV_DISPLAY_BASE + 0x67A00)
>> +#define PIPEB_CGM_CONTROL   (VLV_DISPLAY_BASE + 0x69A00)
>> +#define PIPEC_CGM_CONTROL   (VLV_DISPLAY_BASE + 0x6BA00)
>> +#define PIPEA_CGM_GAMMA (VLV_DISPLAY_BASE + 
>> 0x67000)
>> +#define PIPEB_CGM_GAMMA (VLV_DISPLAY_BASE + 
>> 0x69000)
>> +#define PIPEC_CGM_GAMMA (VLV_DISPLAY_BASE + 
>> 0x6B000)
>> +#define _PIPE_CGM_CONTROL(pipe) \
>> +(_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
>> +#define _PIPE_GAMMA_BASE(pipe) \
>> +(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
>> +
>>   #endif /* _I915_REG_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> index 70c0d42..7e9e934 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -27,6 +27,155 @@
>>   
>>   #include "intel_color_manager.h"
>>   
>> +int chv_set_gamma(struct drm_device *dev, struct drm_property_blob *blob,
>> +  struct drm_crtc *crtc)
>> +{
>> +struct drm_palette *gamma_data;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct drm_mode_config *config = >mode_config;
>> +u32 cgm_control_reg = 0;
>> +u32 cgm_gamma_reg = 0;
>> +enum pipe pipe;
>> +u32 red, green, blue;
>> +u8 red_int, blue_int, green_int;
>> +u16 red_fract, green_fract, blue_fract;
>> +u32 count = 0;
>> +struct drm_r32g32b32 *correction_values = NULL;
>> +u32 num_samples;
>> +u32 word;
>> +int ret = 0, length, flag = 0;
>> +
>> +if (!blob) {
>> +DRM_ERROR("NULL Blob\n");
>> +return -EINVAL;
>> +}
>> +
>> +gamma_data = (struct drm_palette *)blob->data;
>> +
>> +if (gamma_data->version != CHV_GAMMA_DATA_STRUCT_VERSION) {
>> +DRM_ERROR("Invalid Gamma Data struct version\n");
>> +return -EINVAL;
>> +}
>> +
>> +pipe = to_intel_crtc(crtc)->pipe;
>> +num_samples = gamma_data->num_samples;
>> +length = num_samples * sizeof(struct drm_r32g32b32);
>> +
>> +if (num_samples == 0) {
>> +
>> +/* Disable Gamma functionality on Pipe - CGM Block */
>> +cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
>> +cgm_control_reg &= ~CGM_GAMMA_EN;
>> +I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
>> +
>> +DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
>> +pipe_name(pipe));
>> +ret = 0;
>> +} else if (num_samples == CHV_10BIT_GAMMA_MAX_VALS ||
>> +num_samples == CHV_8BIT_GAMMA_MAX_VALS) {
>> +cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
>> +
>> +count = 0;
>> +correction_values = (struct drm_r32g32b32 *)_data->lut;
>> +while (count < num_samples) {
>> +blue = correction_values[count].b32;
>> +green = correction_values[count].g32;
>> +red = correction_values[count].r32;
>> +
>> +blue_int = _GAMMA_INT_PART(blue);
>> +if (blue_int > GAMMA_INT_MAX)
>> +blue = CHV_MAX_GAMMA;
>> +green_int = _GAMMA_INT_PART(green);
>> +if (green_int > GAMMA_INT_MAX)
>> +green = CHV_MAX_GAMMA;
>> +red_int = _GAMMA_INT_PART(red);
>> +if (red_int > GAMMA_INT_MAX)
>> +red = 

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

[Pekka Paalanen]

On Tue, 21 Jul 2015 11:02:58 +0200
Daniel Vetter  wrote:

> On Tue, Jul 21, 2015 at 10:06:09AM +0300, Pekka Paalanen wrote:
> > On Mon, 20 Jul 2015 10:32:31 -0700
> > Stéphane Marchesin  wrote:
> > 
> > > On Mon, Jul 20, 2015 at 7:21 AM, Daniel Vetter  wrote:
> > > > On Mon, Jul 20, 2015 at 12:35:48PM +0300, Pekka Paalanen wrote:
> > > >> On Mon, 20 Jul 2015 01:58:33 -0700
> > > >> Stéphane Marchesin  wrote:
> > > >>
> > > >> > On Mon, Jul 20, 2015 at 12:46 AM, Pekka Paalanen  > > >> > gmail.com> wrote:
> > > >> > > On Sun, 19 Jul 2015 17:20:32 -0700
> > > >> > > Stéphane Marchesin  wrote:
> > > >> > >
> > > >> > >> On Thu, Jul 16, 2015 at 11:08 PM, Pekka Paalanen  > > >> > >> gmail.com> wrote:
> > > >> > >> >
> > > >> > >> > On Thu, 16 Jul 2015 20:20:39 +0800
> > > >> > >> > John Hunter  wrote:
> > > >> > >> >
> > > >> > >> > > From: Zhao Junwang 
> > > >> > >> > >
> > > >> > >> > > This supports the asynchronous commits, required for 
> > > >> > >> > > page-flipping
> > > >> > >> > > Since it's virtual hw it's ok to commit async stuff right 
> > > >> > >> > > away, we
> > > >> > >> > > never have to wait for vblank.
> > > >> > >> >
> > > >> > >> > Hi,
> > > >> > >> >
> > > >> > >> > in theory, yes. This is what a patch to bochs implemented not 
> > > >> > >> > too long
> > > >> > >> > ago, so AFAIK you are only replicating the existing behaviour.
> > > >> > >> >
> > > >> > >> > However, if userspace doing an async commit (or sync, I 
> > > >> > >> > suppose) does
> > > >> > >> > not incur any waits in the kernel in e.g. sending the page flip 
> > > >> > >> > event,
> > > >> > >> > then flip driven programs (e.g. a Wayland compositor, say, 
> > > >> > >> > Weston)
> > > >> > >> > will be running its rendering loop as a busy-loop, because the 
> > > >> > >> > kernel
> > > >> > >> > does not throttle it to the (virtual) display refresh rate.
> > > >> > >> >
> > > >> > >> > This will cause maximal CPU usage and poor user experience as
> > > >> > >> > everything else needs to fight for CPU time and event dispatch 
> > > >> > >> > to get
> > > >> > >> > through, like input.
> > > >> > >> >
> > > >> > >> > I would hope someone could do a follow-up to implement a 
> > > >> > >> > refresh cycle
> > > >> > >> > emulation based on a clock. Userspace expects page flips to 
> > > >> > >> > happen at
> > > >> > >> > most at refresh rate when asking for vblank-synced flips. It's 
> > > >> > >> > only
> > > >> > >> > natural for userspace to drive its rendering loop based on the 
> > > >> > >> > vblank
> > > >> > >> > cycle.
> > > >> > >>
> > > >> > >>
> > > >> > >> I've been asking myself the same question (for the UDL driver) 
> > > >> > >> and I'm
> > > >> > >> not sure if this policy should go in the kernel. After all, there
> > > >> > >> could be legitimate reasons for user space to render lots of 
> > > >> > >> frames
> > > >> > >> per second. It seems to me that if user space doesn't want too 
> > > >> > >> many
> > > >> > >> fps, it should just throttle itself.
> > > >> > >
> > > >> > > If userspace wants to render lots of frames per second, IMO it 
> > > >> > > should
> > > >> > > not be using vblank-synced operations in a way that may throttle 
> > > >> > > it.
> > > >> > > The lots of frames use case is already non-working for the 
> > > >> > > majority of
> > > >> > > the drivers without DRM_MODE_PAGE_FLIP_ASYNC, right?
> > > >> > >
> > > >> > > The problem here I see is that one DRM driver decides to work 
> > > >> > > different
> > > >> > > to other DRM drivers. All real-hardware DRM drivers, when asked to 
> > > >> > > do
> > > >> > > vblank-synced update, actually do throttle to the vblank AFAIK.
> > > >> >
> > > >> > udl is an exception here. It is (arguably) real hardware but doesn't 
> > > >> > throttle.
> > > >> >
> > > >> > > Is it
> > > >> > > too much to assume, that the video mode set in a driver (refresh 
> > > >> > > rate)
> > > >> > > corresponds to the vblank rate which implicitly delays the 
> > > >> > > completion
> > > >> > > of vblank-sync'd operations to at least the next vblank boundary?
> > > >> >
> > > >> > I think it's wrong to make user space think that a vsynced display
> > > >> > always matches the refresh rate in a world where:
> > > >> >
> > > >> > - some displays have variable refresh rates (not just the fancy new
> > > >> > stuff like g-sync, look for lvds_downclock in the intel driver for
> > > >> > example, also consider DSI displays)
> > > >> >
> > > >> > - some displays have no refresh rate (the ones we are talking about
> > > >> > here: udl, bochs...)
> > 
> > > > Imo aiming for vrefresh to be accurate is good. For gsync and friends I
> > > > think we should have an explicit range or flag to make userspace aware 
> > > > of
> > > > what's going on.
> > > 
> > > I think the concept of vrefresh is flawed and not really future-proof
> > > (I gave a few examples in my previous email). I agree we should keep
> > > it as legacy, but we should add something else for the more 

[PATCH 2/6] drm/atomic: pass old crtc state to atomic_begin/flush.

[Maarten Lankhorst]

In intel it's useful to keep track of some state changes with old
crtc state vs new state, for example to disable initial planes or
when a modeset's prevented during fastboot.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  6 --
 drivers/gpu/drm/drm_atomic_helper.c|  8 
 drivers/gpu/drm/drm_plane_helper.c |  4 ++--
 drivers/gpu/drm/i915/intel_display.c   | 10 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |  6 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   |  6 --
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  6 --
 drivers/gpu/drm/sti/sti_drm_crtc.c |  6 --
 drivers/gpu/drm/tegra/dc.c |  6 --
 include/drm/drm_crtc_helper.h  |  6 --
 10 files changed, 40 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index f69b92535505..8b8fe3762ca9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -239,7 +239,8 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c,
return atmel_hlcdc_plane_prepare_disc_area(s);
 }

-static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
+static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c,
+ struct drm_crtc_state *old_s)
 {
struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);

@@ -253,7 +254,8 @@ static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc 
*c)
}
 }

-static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc *crtc)
+static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_s)
 {
/* TODO: write common plane control register if available */
 }
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ac6601071414..4a48d76c4fb1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1170,7 +1170,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs || !funcs->atomic_begin)
continue;

-   funcs->atomic_begin(crtc);
+   funcs->atomic_begin(crtc, old_crtc_state);
}

for_each_plane_in_state(old_state, plane, old_plane_state, i) {
@@ -1200,7 +1200,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs || !funcs->atomic_flush)
continue;

-   funcs->atomic_flush(crtc);
+   funcs->atomic_flush(crtc, old_crtc_state);
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_planes);
@@ -1236,7 +1236,7 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
drm_crtc_state *old_crtc_state)

crtc_funcs = crtc->helper_private;
if (crtc_funcs && crtc_funcs->atomic_begin)
-   crtc_funcs->atomic_begin(crtc);
+   crtc_funcs->atomic_begin(crtc, old_crtc_state);

drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
struct drm_plane_state *old_plane_state =
@@ -1259,7 +1259,7 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
drm_crtc_state *old_crtc_state)
}

if (crtc_funcs && crtc_funcs->atomic_flush)
-   crtc_funcs->atomic_flush(crtc);
+   crtc_funcs->atomic_flush(crtc, old_crtc_state);
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 03b7afe455e6..cb5dab4c4337 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -436,7 +436,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,

for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_begin)
-   crtc_funcs[i]->atomic_begin(crtc[i]);
+   crtc_funcs[i]->atomic_begin(crtc[i], crtc[i]->state);
}

/*
@@ -451,7 +451,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,

for (i = 0; i < 2; i++) {
if (crtc_funcs[i] && crtc_funcs[i]->atomic_flush)
-   crtc_funcs[i]->atomic_flush(crtc[i]);
+   crtc_funcs[i]->atomic_flush(crtc[i], crtc[i]->state);
}

/*
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 671ca2820f82..def9444eeae2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -102,8 +102,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
 static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state 

[PATCH 1/6] drm/atomic: add connectors_changed to separate it from mode_changed, v2

[Maarten Lankhorst]

This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.

Changes since v1:
- Update kerneldocs slightly.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 39 +++-
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 include/drm/drm_atomic.h |  3 ++-
 include/drm/drm_crtc.h   |  8 +---
 4 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0ea8c5d476ef..ac6601071414 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -124,7 +124,7 @@ steal_encoder(struct drm_atomic_state *state,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);

-   crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;

list_for_each_entry(connector, >connector_list, head) {
if (connector->state->best_encoder != encoder)
@@ -174,14 +174,14 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
idx = drm_crtc_index(connector->state->crtc);

crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;
}

if (connector_state->crtc) {
idx = drm_crtc_index(connector_state->crtc);

crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;
}
}

@@ -233,7 +233,7 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
idx = drm_crtc_index(connector_state->crtc);

crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;

DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
[CRTC:%d]\n",
 connector->base.id,
@@ -256,7 +256,8 @@ mode_fixup(struct drm_atomic_state *state)
bool ret;

for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (!crtc_state->mode_changed)
+   if (!crtc_state->mode_changed &&
+   !crtc_state->connectors_changed)
continue;

drm_mode_copy(_state->adjusted_mode, _state->mode);
@@ -312,7 +313,8 @@ mode_fixup(struct drm_atomic_state *state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
const struct drm_crtc_helper_funcs *funcs;

-   if (!crtc_state->mode_changed)
+   if (!crtc_state->mode_changed &&
+   !crtc_state->connectors_changed)
continue;

funcs = crtc->helper_private;
@@ -338,9 +340,14 @@ mode_fixup(struct drm_atomic_state *state)
  *
  * Check the state object to see if the requested state is physically possible.
  * This does all the crtc and connector related computations for an atomic
- * update. It computes and updates crtc_state->mode_changed, adds any 
additional
- * connectors needed for full modesets and calls down into ->mode_fixup
- * functions of the driver backend.
+ * update and adds any additional connectors needed for full modesets and calls
+ * down into ->mode_fixup functions of the driver backend.
+ *
+ * crtc_state->mode_changed is set when the input mode is changed.
+ * crtc_state->connectors_changed is set when a connector is added or
+ * removed from the crtc.
+ * crtc_state->active_changed is set when crtc_state->active changes,
+ * which is used for dpms.
  *
  * IMPORTANT:
  *
@@ -373,7 +380,17 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (crtc->state->enable != crtc_state->enable) {
DRM_DEBUG_ATOMIC("[CRTC:%d] enable changed\n",
 crtc->base.id);
+
+   /*
+* For clarity this assignment is done here, but
+* enable == 0 is only true when there are no
+* connectors and a NULL mode.
+*
+* The other way around is true as well. enable != 0
+* iff connectors are attached and a mode is set.
+*/
crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;
}
}

@@ -448,6 +465,9 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
  * This does all the plane update related checks using by calling into the
  * ->atomic_check hooks provided by the driver.
  *
+ * It 

[PATCH v3 1/2] drm/i915: remove unnecessary null test

[Sudip Mukherjee]

While creating the debugfs file we are setting the inode->i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). Moreover single_open is setting
file->private_data->private to dev.
So at this point it can never be NULL.
This check was added by commit eb3394faeb97 ("drm/i915: Add debugfs test
control files for Displayport compliance testing")

Signed-off-by: Sudip Mukherjee 
---

v3: removed the check in i915_displayport_test_active_write also
v2: removed null check
v1 was drm/i915: fix possible null pointer dereference

 drivers/gpu/drm/i915/i915_debugfs.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bc817da..ffce62e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4028,24 +4028,14 @@ static ssize_t 
i915_displayport_test_active_write(struct file *file,
 {
char *input_buffer;
int status = 0;
-   struct seq_file *m;
struct drm_device *dev;
struct drm_connector *connector;
struct list_head *connector_list;
struct intel_dp *intel_dp;
int val = 0;

-   m = file->private_data;
-   if (!m) {
-   status = -ENODEV;
-   return status;
-   }
-   dev = m->private;
+   dev = ((struct seq_file *)file->private_data)->private;

-   if (!dev) {
-   status = -ENODEV;
-   return status;
-   }
connector_list = >mode_config.connector_list;

if (len == 0)
@@ -4103,9 +4093,6 @@ static int i915_displayport_test_active_show(struct 
seq_file *m, void *data)
struct list_head *connector_list = >mode_config.connector_list;
struct intel_dp *intel_dp;

-   if (!dev)
-   return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {

if (connector->connector_type !=
@@ -4150,9 +4137,6 @@ static int i915_displayport_test_data_show(struct 
seq_file *m, void *data)
struct list_head *connector_list = >mode_config.connector_list;
struct intel_dp *intel_dp;

-   if (!dev)
-   return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {

if (connector->connector_type !=
@@ -4192,9 +4176,6 @@ static int i915_displayport_test_type_show(struct 
seq_file *m, void *data)
struct list_head *connector_list = >mode_config.connector_list;
struct intel_dp *intel_dp;

-   if (!dev)
-   return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {

if (connector->connector_type !=
-- 
1.8.1.2

[PATCH v3 2/2] drm/i915: remove redundant if check

[Sudip Mukherjee]

The extra check for connector_type is not required as we are already
checking for connector_type != DRM_MODE_CONNECTOR_DisplayPort.
The check was added by commit eb3394faeb97 ("drm/i915: Add debugfs test
control files for Displayport compliance testing")

Signed-off-by: Sudip Mukherjee 
---
v3: It is new. Submitting together in a series as the changes are in the
same part of the code.

 drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ffce62e..caf1382 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4059,9 +4059,7 @@ static ssize_t i915_displayport_test_active_write(struct 
file *file,
DRM_MODE_CONNECTOR_DisplayPort)
continue;

-   if (connector->connector_type ==
-   DRM_MODE_CONNECTOR_DisplayPort &&
-   connector->status == connector_status_connected &&
+   if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
status = kstrtoint(input_buffer, 10, );
-- 
1.8.1.2

[PATCH] tests: modetest: Accept connector names in addition to connector IDs

[Laurent Pinchart]

Hi Thierry,

On Tuesday 21 July 2015 11:05:59 Thierry Reding wrote:
> On Mon, Jul 20, 2015 at 07:56:20PM +0300, Laurent Pinchart wrote:
> > From: Thierry Reding 
> > 
> > Allow connector names to be used in the specification of the -s option.
> > This requires storing the string passed on the command-line so that it
> > can later be resolved to a connector ID (after the DRM device has been
> > opened).
> > 
> > Connector names are constructed from the connector type name and
> > connector type ID using the same format as used internally in the
> > Linux kernel.
> > 
> > Signed-off-by: Thierry Reding 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  tests/modetest/modetest.c | 94 --
> >  1 file changed, 82 insertions(+), 12 deletions(-)
> > 
> > I've carried this patch in my tree for too long and I'm now tired of
> > rebasing it. It's thus time to get it in mainline.
> > 
> > Compared to the original version developed by Thierry, I've
> > 
> > - rebased the patch on top of latest master
> > - dropped dependencies on other WIP patches in Thierry's tree
> > - fixed printf alignment
> > - used asprintf to simplify name string allocation
> > - constructed the connector name using the same format as the Linux kernel
> 
> Heh, I started to get all these patches into shape last week, and this
> will probably give me more rebase headaches.

It shouldn't hurt too much as rebasing your patch on top of the master branch 
without any other dependency was pretty easy.

> But I guess that's what I deserve for letting things slide...

Should I consider this as an Acked-by ? :-)

-- 
Regards,

Laurent Pinchart

[PATCH] drm: Detect no-op drmModeAtomicRequest and return early

[Chris Wilson]

If the number of items to process in the request is zero, we can forgo
duplicating, sorting the request and feeding it into the kernel and
instead report success immediately.  This prevents a NULL dereference of
the sorted->items for the no-op request.

Fixes: ed44e0b9585c563905447eceed12af9c1c7ca8d4
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Emil Velikov 
---
 xf86drmMode.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 529429e..fa21986 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1289,7 +1289,7 @@ static int sort_req_list(const void *misc, const void 
*other)
 int drmModeAtomicCommit(int fd, drmModeAtomicReqPtr req, uint32_t flags,
void *user_data)
 {
-   drmModeAtomicReqPtr sorted = drmModeAtomicDuplicate(req);
+   drmModeAtomicReqPtr sorted;
struct drm_mode_atomic atomic;
uint32_t *objs_ptr = NULL;
uint32_t *count_props_ptr = NULL;
@@ -1300,7 +1300,11 @@ int drmModeAtomicCommit(int fd, drmModeAtomicReqPtr req, 
uint32_t flags,
int obj_idx = -1;
int ret = -1;

-   if (!sorted)
+   if (req->cursor == 0)
+   return 0;
+
+   sorted = drmModeAtomicDuplicate(req);
+   if (sorted == NULL)
return -ENOMEM;

memclear(atomic);
-- 
2.1.4

[PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver

[Marek Szyprowski]

Hello,

On 2015-07-16 15:09, Hans Verkuil wrote:
> Marek, Kamil,
>
> On 06/29/15 12:14, Hans Verkuil wrote:
>> From: Kamil Debski 
>>
>> Add CEC interface driver present in the Samsung Exynos range of
>> SoCs.
>>
>> The following files were based on work by SangPil Moon:
>> - exynos_hdmi_cec.h
>> - exynos_hdmi_cecctl.c
>>
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
>> ---
> 
>
>> diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c 
>> b/drivers/media/platform/s5p-cec/s5p_cec.c
>> new file mode 100644
>> index 000..0f16d00
>> --- /dev/null
>> +++ b/drivers/media/platform/s5p-cec/s5p_cec.c
>> @@ -0,0 +1,283 @@
>> +/* drivers/media/platform/s5p-cec/s5p_cec.c
>> + *
>> + * Samsung S5P CEC driver
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + *
>> + * 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.
>> + *
>> + * This driver is based on the "cec interface driver for exynos soc" by
>> + * SangPil Moon.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "exynos_hdmi_cec.h"
>> +#include "regs-cec.h"
>> +#include "s5p_cec.h"
>> +
>> +#define CEC_NAME"s5p-cec"
>> +
>> +static int debug;
>> +module_param(debug, int, 0644);
>> +MODULE_PARM_DESC(debug, "debug level (0-2)");
>> +
>> +static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
>> +{
>> +struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
>> +int ret;
>> +
>> +if (enable) {
>> +ret = pm_runtime_get_sync(cec->dev);
>> +
>> +adap->phys_addr = 0x100b;
> This is a bogus physical address. The actual physical address has to be 
> derived
> from the EDID that is read by the HDMI transmitter.
>
> I think in the case of this driver it will have to be userspace that assigns
> the physical address after reading the EDID from drm/kms?
>
> How did you test this, Kamil?

If I remember correctly, physical address has been derived from EDID in the
userspace (it is available in /sys/class/drm/*) and passed to s5p-cec 
driver by
appropriate ioctl.

I don't know what is the reason for the above 'adap->phys_addr = 0x100b' 
assignment.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Krzysztof Kozlowski]

Hi,

Today's linux-next (next-20150721) encounters boot failures on Exynos
Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
commit d80167b85024982c5f18d0481a5c248100360118
Author: Joonyoung Shim 
Date:   Thu Jul 2 21:49:39 2015 +0900

drm/exynos: remove drm_iommu_attach_device_if_possible

Already drm_iommu_attach_device checks whether support iommu internally.
It should clear channels always regardless iommu support. We didn't know
because we can detect the problem when iommu is enabled, so we don't
have to use drm_iommu_attach_device_if_possible and then we can remove
drm_iommu_attach_device_if_possible and clear_channels function pointer.

Signed-off-by: Joonyoung Shim 
Tested-by: Marek Szyprowski 
Signed-off-by: Inki Dae 

:04 04 83379efbf4960f58d680371628ec04387935bd53
da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


Config: exynos
Boot log from Odroid XU3-Lite attached.

Any hints or ideas?

Best regards,
Krzysztof
-- next part --
Starting kernel ...

[0.00] Booting Linux on physical CPU 0x100
[0.00] Linux version 4.2.0-rc2-00314-gd80167b85024 (kozik at kozik-lap) 
(gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #766 SMP PREEMPT Tue Jul 21 
22:12:16 KST 2015
[0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: Hardkernel Odroid XU3 Lite
[0.00] cma: Reserved 64 MiB at 0xba80
[0.00] Memory policy: Data cache writealloc
[0.00] Samsung CPU ID: 0xe5422001
[0.00] Running under secure firmware.
[0.00] PERCPU: Embedded 11 pages/cpu @ee77f000 s15040 r8192 d21824 
u45056
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 513040
[0.00] Kernel command line: console=tty1 console=ttySAC2,115200n8 
root=/dev/mmcblk0p1 rootwait rw smsc95xx.macaddr=00:1e:06:61:7a:93
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1957712K/2058240K available (6176K kernel code, 314K 
rwdata, 2232K rodata, 412K init, 8223K bss, 34992K reserved, 65536K 
cma-reserved, 1230848K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc083e2e8   (8409 kB)
[0.00]   .init : 0xc083f000 - 0xc08a6000   ( 412 kB)
[0.00]   .data : 0xc08a6000 - 0xc08f4b68   ( 315 kB)
[0.00].bss : 0xc08f7000 - 0xc10fef60   (8224 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[0.00] Running RCU self tests
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU lockdep checking is enabled.
[0.00]  Additional per-CPU info printed with stalls.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] GIC physical location is 0x10481000
[0.00] L2C: failed to init: -19
[0.00] Switching to timer-based delay loop, resolution 41ns
[0.00] clocksource: mct-frc: mask: 0x max_cycles: 0x, 
max_idle_ns: 79635851949 ns
[0.08] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.000986] Console: colour dummy device 80x30
[0.003960] console [tty1] enabled
[0.004000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar
[0.004063] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.004102] ... MAX_LOCK_DEPTH:  48
[0.004140] ... MAX_LOCKDEP_KEYS:8191
[0.004179] ... CLASSHASH_SIZE:  4096
[0.004218] ... MAX_LOCKDEP_ENTRIES: 32768
[0.004258] ... MAX_LOCKDEP_CHAINS:  65536
[0.004297] ... CHAINHASH_SIZE:  32768
[0.004336]  memory used by lock dependency info: 5167 kB
[0.004379]  per task-struct memory footprint: 1536 bytes
[0.004471] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 48.00 BogoMIPS (lpj=12)
[0.004557] pid_max: default: 32768 minimum: 301
[0.005348] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.005410] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.008857] CPU: Testing write buffer coherency: ok
[0.010644] CPU0: update cpu_capacity 448

KMS timings (Re: [PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation)

[Daniel Vetter]

On Tue, Jul 21, 2015 at 02:22:03PM +0300, Pekka Paalanen wrote:
> On Tue, 21 Jul 2015 11:02:58 +0200
> Daniel Vetter  wrote:
> 
> > On Tue, Jul 21, 2015 at 10:06:09AM +0300, Pekka Paalanen wrote:
> > > On Mon, 20 Jul 2015 10:32:31 -0700
> > > Stéphane Marchesin  wrote:

> > > If one does not ask for ASYNC with a page flip, does it mean flipping
> > > on the next vblank, or flipping such that it cannot tear but allowing
> > > techiques like scanline waits?
> > 
> > Since legacy page_flip is always for the full primary plane you can't do
> > scanline waits - it covers everything anyway.
> 
> Ah, nice. Obvious in hindsight, at least if the display server does
> not mark dirty regions.
> 
> But there seems to be drmModeDirtyFB(), can that not be used with page
> flip? If userspace provided dirty regions, would scanline-wait be
> possible in theory? If yes, would it be acceptable for drivers to do?

DirtyFB is exclusively for frontbuffer rendering. We could easily add a
dirty-x/y/w/h rectangle to atomic (I don't think a list makes sense, most
hw can only do one), but right now there's no way to do FlipWithDamage.
Definitely something we want to look into (and we should be able to make
it work on skl on at least in some cases).

> > I guess for bochs/udl and others we could create a small drm driver which
> > keeps track of the last vblank ts (we have those already) and suitable
> > delays the even/timestamp to keep up the illusion. Or we just rip out
> > pageflip support for those drivers. But if weston can't cope with that
> > that would be worse.
> 
> Now that you ask, I'm not even really sure what the non-page-flip KMS
> display update way is, so no, I would say Weston cannot deal with it as
> is.
> 
> Who's up for the job? :-)

Implement a drm_send_fake_vblank_event in drm_irq.c and then roll it out
shouldnt be too much work really. We can store crtc-private date needed
for this in the drm_vblank structure (just need a timer plus maybe a
high-res timestamp to make the illusion better). Then we could replace the
send_vblank_event call with that helper in bochs/udl/...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3 1/2] drm/i915: remove unnecessary null test

[Daniel Vetter]

On Tue, Jul 21, 2015 at 05:36:45PM +0530, Sudip Mukherjee wrote:
> While creating the debugfs file we are setting the inode->i_private to
> dev. That same dev is passed to these functions as private of struct
> seq_file via single_open(). Moreover single_open is setting
> file->private_data->private to dev.
> So at this point it can never be NULL.
> This check was added by commit eb3394faeb97 ("drm/i915: Add debugfs test
> control files for Displayport compliance testing")
> 

Still missing

Cc: Chris Wilson ...
Cc: Todd Previte ...

here to make sure reviewers/original authors are in the loop. Anyway this
is a simple enough patch, so I just pulled them both in.

Thanks, Daniel

> Signed-off-by: Sudip Mukherjee 
> ---
> 
> v3: removed the check in i915_displayport_test_active_write also
> v2: removed null check
> v1 was drm/i915: fix possible null pointer dereference
> 
>  drivers/gpu/drm/i915/i915_debugfs.c | 21 +
>  1 file changed, 1 insertion(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bc817da..ffce62e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4028,24 +4028,14 @@ static ssize_t 
> i915_displayport_test_active_write(struct file *file,
>  {
>   char *input_buffer;
>   int status = 0;
> - struct seq_file *m;
>   struct drm_device *dev;
>   struct drm_connector *connector;
>   struct list_head *connector_list;
>   struct intel_dp *intel_dp;
>   int val = 0;
>  
> - m = file->private_data;
> - if (!m) {
> - status = -ENODEV;
> - return status;
> - }
> - dev = m->private;
> + dev = ((struct seq_file *)file->private_data)->private;
>  
> - if (!dev) {
> - status = -ENODEV;
> - return status;
> - }
>   connector_list = >mode_config.connector_list;
>  
>   if (len == 0)
> @@ -4103,9 +4093,6 @@ static int i915_displayport_test_active_show(struct 
> seq_file *m, void *data)
>   struct list_head *connector_list = >mode_config.connector_list;
>   struct intel_dp *intel_dp;
>  
> - if (!dev)
> - return -ENODEV;
> -
>   list_for_each_entry(connector, connector_list, head) {
>  
>   if (connector->connector_type !=
> @@ -4150,9 +4137,6 @@ static int i915_displayport_test_data_show(struct 
> seq_file *m, void *data)
>   struct list_head *connector_list = >mode_config.connector_list;
>   struct intel_dp *intel_dp;
>  
> - if (!dev)
> - return -ENODEV;
> -
>   list_for_each_entry(connector, connector_list, head) {
>  
>   if (connector->connector_type !=
> @@ -4192,9 +4176,6 @@ static int i915_displayport_test_type_show(struct 
> seq_file *m, void *data)
>   struct list_head *connector_list = >mode_config.connector_list;
>   struct intel_dp *intel_dp;
>  
> - if (!dev)
> - return -ENODEV;
> -
>   list_for_each_entry(connector, connector_list, head) {
>  
>   if (connector->connector_type !=
> -- 
> 1.8.1.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH v3 1/2] drm/i915: remove unnecessary null test

[Sudip Mukherjee]

On Tue, Jul 21, 2015 at 03:51:40PM +0200, Daniel Vetter wrote:
> On Tue, Jul 21, 2015 at 05:36:45PM +0530, Sudip Mukherjee wrote:
> > While creating the debugfs file we are setting the inode->i_private to
> > dev. That same dev is passed to these functions as private of struct
> > seq_file via single_open(). Moreover single_open is setting
> > file->private_data->private to dev.
> > So at this point it can never be NULL.
> > This check was added by commit eb3394faeb97 ("drm/i915: Add debugfs test
> > control files for Displayport compliance testing")
> > 
> 
> Still missing
> 
> Cc: Chris Wilson ...
> Cc: Todd Previte ...
> 
> here to make sure reviewers/original authors are in the loop. Anyway this
> is a simple enough patch, so I just pulled them both in.
Sorry. did you mean to put Cc: here before the Signed-off-by: ?
I have put them in Cc list of the patches.
For my next patch you will not get these issues.

regards
sudip

[PATCH] tests: modetest: Accept connector names in addition to connector IDs

[Thierry Reding]

On Tue, Jul 21, 2015 at 03:27:25PM +0300, Laurent Pinchart wrote:
> Hi Thierry,
> 
> On Tuesday 21 July 2015 11:05:59 Thierry Reding wrote:
> > On Mon, Jul 20, 2015 at 07:56:20PM +0300, Laurent Pinchart wrote:
> > > From: Thierry Reding 
> > > 
> > > Allow connector names to be used in the specification of the -s option.
> > > This requires storing the string passed on the command-line so that it
> > > can later be resolved to a connector ID (after the DRM device has been
> > > opened).
> > > 
> > > Connector names are constructed from the connector type name and
> > > connector type ID using the same format as used internally in the
> > > Linux kernel.
> > > 
> > > Signed-off-by: Thierry Reding 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  tests/modetest/modetest.c | 94 --
> > >  1 file changed, 82 insertions(+), 12 deletions(-)
> > > 
> > > I've carried this patch in my tree for too long and I'm now tired of
> > > rebasing it. It's thus time to get it in mainline.
> > > 
> > > Compared to the original version developed by Thierry, I've
> > > 
> > > - rebased the patch on top of latest master
> > > - dropped dependencies on other WIP patches in Thierry's tree
> > > - fixed printf alignment
> > > - used asprintf to simplify name string allocation
> > > - constructed the connector name using the same format as the Linux kernel
> > 
> > Heh, I started to get all these patches into shape last week, and this
> > will probably give me more rebase headaches.
> 
> It shouldn't hurt too much as rebasing your patch on top of the master branch 
> without any other dependency was pretty easy.
> 
> > But I guess that's what I deserve for letting things slide...
> 
> Should I consider this as an Acked-by ? :-)

I don't think you need it since I authored it, but yeah, if this works,
just go ahead and I'll figure out what to do about it when rebasing on
top of your version.

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

likely signedness bug in drm and nvidia drivers

[Daniel Thompson]

On 21/07/15 03:44, Ilia Mirkin wrote:
 > I think you're right. The intent is to mask off the bits above> 
bits_per_pixel. So if bits_per_pixel is 24, the mask would be> 
0xff00. If it's 16, then the mask would be 0x. If it's 32,> 
then the mask is 0.> > In reality, bits_per_pixel is almost exclusively 
32, which will end up> with a mask of 0 (note that the shift result is 
inverted at the end).> So for the majority case, there's not bug... just 
a useless operation.> > I took a look at linux/bitops.h, and there's 
nothing particularly> great there. GENMASK, I guess, but it's not quite 
right. Just> switching to 0U should be fine there.
I really don't see GENMASK() isn't quite right.

Try:

uint32_t mask = GENMASK(32, info->var.bits_per_pixel);

Versus:

uint32_t mask = ~(~0u >> (32 - info->var.bits_per_pixel));

For me, the GENMASK() is obvious whilst the later takes a good bit of 
mental decoding.


Daniel.

[Bug 91371] Tonga HDMI Audio none on TV working on monitor - possible eld issue

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

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

--- Comment #9 from Andy Furniss  ---
Created attachment 117279
  --> https://bugs.freedesktop.org/attachment.cgi?id=117279=edit
debug/test diff

I played a bit more round this eld thing and it seems there is a bug - but it
looks like it's the same for older radeon dce as well, and "fixing" it doesn't
get me sound on the TV - it does of course make /proc/asound eld look saner.

The difference between my monitor and the TV is that the monitor has a speaker
layout block and the TV doesn't. So the monitor hits the the "if" in the
attached diff and the value of sadb[0] is 1. 

The TV hits the else and gets allocated a value of 5 which is commented as
stereo, but according to the edid sections of CEA B and D stereo is 1 and 5 is
just like I see in /proc/asound  Fl/Fr Fc.

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

[Bug 91416] vsync limits fps but still tearing in picture

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

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

Bug ID: 91416
   Summary: vsync limits fps but still tearing in picture
   Product: Mesa
   Version: 10.5
  Hardware: x86-64 (AMD64)
OS: other
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: markusmitsch86 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

i experimented with the vblank_mode in various applications and saw that it
limits the fps to 60 hz as my monitor is but the picture is torn apart.

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

[PATCH] drm/panel: auo novatek 1080p video mode panel

[Rob Clark]

This is one of several different panels that are used on the Sony Xperia
Z3 phone.  It can operate in either command or video mode, although so
far only video mode is implemented (since that is the mode that the
downstream kernel version I happened to be looking at was using, and
that is where I got the programming sequences for the panel).

Signed-off-by: Rob Clark 
---
Couple Notes:
 1) programming sequences and basically everything I know about the
panel came from downstream android kernel.  I've started a wiki
page to document how to translate from downstream kernel-msm way
of doing things to upstream panel framework, which may be useful
for others wanting to port downstream panel drivers for snapdragon
devices:

https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting

 2) The Sony phones at least (not sure if this is common) use one of
several different panels, with runtime probing.  Depending on the
device they seem to either use a gpio (simple) or send some DSI
commands to read back the panel-id.  My rough thinking here about
how to handle this is to implement a "panel-meta" driver (or maybe
one each for the different probing methods), which would take a
list of phandles to the actual candidate panels, and fwd the panel
fxn calls to the chosen panel after probing.

 .../bindings/panel/auo,novatek-1080p.txt   |  25 ++
 drivers/gpu/drm/panel/Kconfig  |   9 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c| 470 +
 4 files changed, 505 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
 create mode 100644 drivers/gpu/drm/panel/panel-auo-novatek-1080p.c

diff --git a/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt 
b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
new file mode 100644
index 000..8a53093
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,novatek-1080p.txt
@@ -0,0 +1,25 @@
+AU Optronics Corporation 1080x1920 DSI panel
+
+This panel supports both video and command mode (although currently only video
+mode is implemented in the driver.
+
+Required properties:
+- compatible: should be "auo,novatek-1080p-vid"
+
+Optional properties:
+- power-supply: phandle of the regulator that provides the supply voltage
+- reset-gpio: phandle of gpio for reset line
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   dsi at 5430 {
+   panel: panel at 0 {
+   compatible = "auo,novatek-1080p-vid";
+   reg = <0>;
+
+   power-supply = <...>;
+   reset-gpio = <...>;
+   backlight = <...>;
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6d64c7b..89f0e8c 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -43,4 +43,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.

+config DRM_PANEL_AUO_NOVATEK_1080P
+   tristate "AUO Novatek 1080p video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for AUO 1080p DSI panel
+ as found in some Sony XPERIA Z3 devices
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..cbcfedf 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
+obj-$(CONFIG_DRM_PANEL_AUO_NOVATEK_1080P) += panel-auo-novatek-1080p.o
diff --git a/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c 
b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
new file mode 100644
index 000..0db70dd
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-auo-novatek-1080p.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (C) 2015 Red Hat
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 

[Bug 90681] Radeon Kernel Oops & Lockup when switching on DisplayPort attached monitor

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

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

--- Comment #13 from Andreas Tunek  ---
Will this be in 4.2 rc3?

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

[Bug 90681] Radeon Kernel Oops & Lockup when switching on DisplayPort attached monitor

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to Andreas Tunek from comment #13)
> Will this be in 4.2 rc3?

Yes, they are in 4.1 as well.

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

[PATCH 11/16] drm/i915: Add pipe level Gamma correction for CHV/BSW

[Matt Roper]

On Tue, Jul 21, 2015 at 04:40:08PM +0530, Malladi, Kausal wrote:
> On Tuesday 21 July 2015 05:33 AM, Matt Roper wrote:
> >On Wed, Jul 15, 2015 at 06:39:35PM +0530, Kausal Malladi wrote:
...
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index 11d491e..9e994fc 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -13773,6 +13773,9 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> >>*crtc)
> >>if (!needs_modeset(crtc->state) && INTEL_INFO(dev)->gen >= 9)
> >>skl_detach_scalers(intel_crtc);
> >>+
> >>+   if (!needs_modeset(crtc->state))
> >>+   intel_color_manager_crtc_commit(dev, crtc->state);
> >It's not immediately clear to me why this is only for the
> >'!needs_modeset' case.  Does color management get setup somewhere else
> >in cases where a display update does involve a modeset?
> This is just an extra precaution. Do you think that we should remove it?
> 
> Kausal

It seems to me that if you updated your color settings in the process of
also doing a full modeset, then those new settings wouldn't take effect
until you followed up with another, non-modeset, pageflip.  Unless I'm
overlooking something that would cause them to be programmed on the
first frame anyway?


Matt

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

[PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it

[Eric B Munson]

The cost of faulting in all memory to be locked can be very high when
working with large mappings.  If only portions of the mapping will be
used this can incur a high penalty for locking.

For the example of a large file, this is the usage pattern for a large
statical language model (probably applies to other statical or graphical
models as well).  For the security example, any application transacting
in data that cannot be swapped out (credit card data, medical records,
etc).

This patch introduces the ability to request that pages are not
pre-faulted, but are placed on the unevictable LRU when they are finally
faulted in.  This can be done area at a time via the
mlock2(MLOCK_ONFAULT) or the mlockall(MCL_ONFAULT) system calls.  These
calls can be undone via munlock2(MLOCK_ONFAULT) or
munlockall2(MCL_ONFAULT).

Applying the VM_LOCKONFAULT flag to a mapping with pages that are
already present required the addition of a function in gup.c to pin all
pages which are present in an address range.  It borrows heavily from
__mm_populate().

To keep accounting checks out of the page fault path, users are billed
for the entire mapping lock as if MLOCK_LOCKED was used.

Signed-off-by: Eric B Munson 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: Jonathan Corbet 
Cc: linux-alpha at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: sparclinux at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-mm at kvack.org
Cc: linux-arch at vger.kernel.org
Cc: linux-api at vger.kernel.org
---
Changes from V3:
Do extensive search for VM_LOCKED and ensure that VM_LOCKONFAULT is also handled
 where appropriate

 arch/alpha/include/uapi/asm/mman.h   |  2 +
 arch/mips/include/uapi/asm/mman.h|  2 +
 arch/parisc/include/uapi/asm/mman.h  |  2 +
 arch/powerpc/include/uapi/asm/mman.h |  2 +
 arch/sparc/include/uapi/asm/mman.h   |  2 +
 arch/tile/include/uapi/asm/mman.h|  3 ++
 arch/xtensa/include/uapi/asm/mman.h  |  2 +
 drivers/gpu/drm/drm_vm.c |  8 ++-
 fs/proc/task_mmu.c   |  3 +-
 include/linux/mm.h   |  2 +
 include/uapi/asm-generic/mman.h  |  2 +
 kernel/events/uprobes.c  |  2 +-
 kernel/fork.c|  2 +-
 mm/debug.c   |  1 +
 mm/gup.c |  3 +-
 mm/huge_memory.c |  3 +-
 mm/hugetlb.c |  4 +-
 mm/internal.h|  5 +-
 mm/ksm.c |  2 +-
 mm/madvise.c |  4 +-
 mm/memory.c  |  5 +-
 mm/mlock.c   | 98 +---
 mm/mmap.c| 28 +++
 mm/mremap.c  |  6 +--
 mm/msync.c   |  2 +-
 mm/rmap.c| 12 ++---
 mm/shmem.c   |  2 +-
 mm/swap.c|  3 +-
 mm/vmscan.c  |  2 +-
 29 files changed, 145 insertions(+), 69 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/mman.h 
b/arch/alpha/include/uapi/asm/mman.h
index ec72436..77ae8db 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -37,8 +37,10 @@

 #define MCL_CURRENT 8192   /* lock all currently mapped pages */
 #define MCL_FUTURE 16384   /* lock all additions to address space 
*/
+#define MCL_ONFAULT32768   /* lock all pages that are faulted in */

 #define MLOCK_LOCKED   0x01/* Lock and populate the specified 
range */
+#define MLOCK_ONFAULT  0x02/* Lock pages in range after they are 
faulted in, do not prefault */

 #define MADV_NORMAL0   /* no further special treatment */
 #define MADV_RANDOM1   /* expect random page references */
diff --git a/arch/mips/include/uapi/asm/mman.h 
b/arch/mips/include/uapi/asm/mman.h
index 67c1cdf..71ed81d 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -61,11 +61,13 @@
  */
 #define MCL_CURRENT1   /* lock all current mappings */
 #define MCL_FUTURE 2   /* lock all future mappings */
+#define MCL_ONFAULT4   /* lock all pages that are faulted in */

 /*
  * Flags for mlock
  */
 #define MLOCK_LOCKED   0x01/* Lock and populate the specified 
range */
+#define MLOCK_ONFAULT  0x02/* Lock pages in range after they are 
faulted in, do not prefault */

 #define MADV_NORMAL0   /* no further special treatment */
 #define MADV_RANDOM1   /* expect random page references */
diff --git a/arch/parisc/include/uapi/asm/mman.h 
b/arch/parisc/include/uapi/asm/mman.h
index daab994..c0871ce 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++