[PATCH 2/3] drm/bridge: adv7533: Initialize regulators

[Archit Taneja]

Hi Laurent,

On 8/31/2016 9:23 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Wednesday 31 Aug 2016 16:22:09 Archit Taneja wrote:
>> ADV7533 requires supply to the AVDD, V1P2 and V3P3 pins for proper
>> functionality.
>>
>> Initialize and enable the regulators during probe itself. Controlling
>> these dynamically is left for later.
>
> You should document the power supplies in the DT bindings.

The DT bindings doc update was a part of the same series. I accidentally
Cc'd you only for this patch.

>
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: Laurent Pinchart 
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/bridge/adv7511/adv7511.h | 16 ++
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 34 +++--
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c | 45 +
>>   3 files changed, 86 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 161c923..3fcb202 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -12,6 +12,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #include 
>>   #include 
>> @@ -327,6 +328,10 @@ struct adv7511 {
>>
>>  struct gpio_desc *gpio_pd;
>>
>> +struct regulator *avdd;
>> +struct regulator *v1p2;
>> +struct regulator *v3p3;
>> +
>>  /* ADV7533 DSI RX related params */
>>  struct device_node *host_node;
>>  struct mipi_dsi_device *dsi;
>> @@ -343,6 +348,8 @@ void adv7533_mode_set(struct adv7511 *adv, struct
>> drm_display_mode *mode); int adv7533_patch_registers(struct adv7511 *adv);
>>   void adv7533_uninit_cec(struct adv7511 *adv);
>>   int adv7533_init_cec(struct adv7511 *adv);
>> +int adv7533_init_regulators(struct adv7511 *adv);
>> +void adv7533_uninit_regulators(struct adv7511 *adv);
>>   int adv7533_attach_dsi(struct adv7511 *adv);
>>   void adv7533_detach_dsi(struct adv7511 *adv);
>>   int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
>> @@ -374,6 +381,15 @@ static inline int adv7533_init_cec(struct adv7511 *adv)
>> return -ENODEV;
>>   }
>>
>> +static inline int adv7533_init_regulators(struct adv7511 *adv)
>> +{
>> +return -ENODEV;
>> +}
>> +
>> +static inline void adv7533_uninit_regulators(struct adv7511 *adv)
>> +{
>> +}
>> +
>>   static inline int adv7533_attach_dsi(struct adv7511 *adv)
>>   {
>>  return -ENODEV;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index ec8fb2e..221bc75
>> 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -941,6 +941,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id) if (!adv7511)
>>  return -ENOMEM;
>>
>> +adv7511->i2c_main = i2c;
>>  adv7511->powered = false;
>>  adv7511->status = connector_status_disconnected;
>>
>> @@ -958,13 +959,21 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id) if (ret)
>>  return ret;
>>
>> +if (adv7511->type == ADV7533) {
>> +ret = adv7533_init_regulators(adv7511);
>> +if (ret)
>> +return ret;
>> +}
>> +
>>  /*
>>   * The power down GPIO is optional. If present, toggle it from active
> to
>>   * inactive to wake up the encoder.
>>   */
>>  adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
>> -if (IS_ERR(adv7511->gpio_pd))
>> -return PTR_ERR(adv7511->gpio_pd);
>> +if (IS_ERR(adv7511->gpio_pd)) {
>> +ret = PTR_ERR(adv7511->gpio_pd);
>> +goto uninit_regulators;
>> +}
>>
>>  if (adv7511->gpio_pd) {
>>  mdelay(5);
>> @@ -972,12 +981,14 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id) }
>>
>>  adv7511->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
>> -if (IS_ERR(adv7511->regmap))
>> -return PTR_ERR(adv7511->regmap);
>> +if (IS_ERR(adv7511->regmap)) {
>> +ret = PTR_ERR(adv7511->regmap);
>> +goto uninit_regulators;
>> +}
>>
>>  ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, );
>>  if (ret)
>> -return ret;
>> +goto uninit_regulators;
>>  dev_dbg(dev, "Rev. %d\n", val);
>>
>>  if (adv7511->type == ADV7511)
>> @@ -987,7 +998,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id) else
>>  ret = adv7533_patch_registers(adv7511);
>>  if (ret)
>> -return ret;
>> +goto uninit_regulators;
>>
>>  regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
> edid_i2c_addr);
>>  regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> @@ -995,10 +1006,11 @@ static int adv7511_probe(struct 

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

On 08/31/16 22:06, Roland Singer wrote:
> Here is Peter Wu's reply, which was not send to the mailing list, because
> I had to resend my e-mail to him due to a failure...
> 
> 
>  Forwarded Message 
> Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS
> Date: Wed, 31 Aug 2016 18:08:53 +0200
> From: Peter Wu 
> To: Roland Singer 
> 
> On Wed, Aug 31, 2016 at 05:56:18PM +0200, Roland Singer wrote:
> 
>>> If you look at my notes.txt, you will see that _OFF always executes the
>>> same code. PGON differs. When the problem occurs, "Q0L0" somehow always
>>> reads back as non-zero and LNKS < 7.
>>>
>>
>> Oh you're Lekensteyn ^^
> 
> Yes, that's me :) I wrote bbswitch, did the Optimus and PR3 ACPI support
> in nouveau so I am fairly certain what happens behind the scenes.
> 

Awesome! Thanks for all your efforts! Great work :)


>> I don't have LNKS and no while loop after calling LKEN ?!
> 
> Yes that is what I said in
> https://www.spinics.net/lists/linux-pci/msg53694.html:
> 
> "Other affected devices have similar code, differences are small:
> No check for LNKS (avoids the infinite loop, but device is still off)"
>

Ah ok, missed that.


>> It might be, that lspci does not only power the GPU on, but triggers
>> another pci action which causes the race condition.
>> Does this have something to do with your quote about the retrain bit?
> 
> That is an interesting hypothesis. Even if you invoke `lspci -s01:00.0`
> for example, it will always probe for all devices. So maybe interaction
> with its parent device (PCI root port 00:02.0) causes issues.
> 
> However I also tested without lspci before, and the problem still
> exists. You can trigger runtime resume via (as root):
> 
> echo > /sys/bus/pci/:01:00.0/power/control on
> 
> Set it to "auto" to make it sleep again.
> 

Just tried it over and over again. I don't have any problems switching the GPU 
power state
with bbswitch. So, switching the GPU on is just fine. There must be something 
else, which
does not cooperate well while switching it on (lspci)...

I can confirm,, that `lspci -s01:00.0` also freezes the system.

Trying to trigger runtime resume with `/sys/bus/pci/:01:00.0/power/control`
did not work for me. The GPU just stayed off.
Any hints how to get some more information?

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Here is Peter Wu's reply, which was not send to the mailing list, because
I had to resend my e-mail to him due to a failure...


 Forwarded Message 
Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS
Date: Wed, 31 Aug 2016 18:08:53 +0200
From: Peter Wu 
To: Roland Singer 

On Wed, Aug 31, 2016 at 05:56:18PM +0200, Roland Singer wrote:

> > If you look at my notes.txt, you will see that _OFF always executes the
> > same code. PGON differs. When the problem occurs, "Q0L0" somehow always
> > reads back as non-zero and LNKS < 7.
> > 
> 
> Oh you're Lekensteyn ^^

Yes, that's me :) I wrote bbswitch, did the Optimus and PR3 ACPI support
in nouveau so I am fairly certain what happens behind the scenes.

> I don't have LNKS and no while loop after calling LKEN ?!

Yes that is what I said in
https://www.spinics.net/lists/linux-pci/msg53694.html:

"Other affected devices have similar code, differences are small:
No check for LNKS (avoids the infinite loop, but device is still off)"

> >>
> >> I noticed following:
> >>
> >> 1. Blacklist nouveau
> >> 2. Boot to GDM login manager (Wayland)
> >> 3. Switch to TTY with CTRL+ALT+FN2
> >> 4. Load bbswitch
> >> 5. Switch off GPU
> >> 6. run lspci -> no freeze
> >> 7. Switch to GDM
> >> 8. Login to a Wayland session (X11 won't work)
> >> 9. run lspci in a GUI terminal -> system freezes
> > 
> > Is nouveau somehow loaded anyway? All those extra components (X11,
> > Wayland, etc.) are unnecessary to reproduce the core problem. It occurs
> > whenever the device is being resumed (either via DSM/_PS0 or via power
> > resource PG00._ON).
> > 
> 
> Sorry that was nonsense. The steps to reproduce the problem are still valid.
> I didn't wait enough to power it down...
> 
> But whats interesting:
> 
> 1. Blacklist nouveau
> 2. Load bbswitch
> 3. Power off GPU with bbswitch
> 4. Power on GPU with bbswitch
> 5. Run lspci
> 6. Power off GPU with bbswitch
> 7. Run lspci -> freeze
> 
> So setting the GPU power state with bbswitch works as expected.
> Powering it on is also fine. I did this a couple of times.
> But powering it off and letting lspci powering it on, ends in a race.

In some cases I also found that it does always happen at the first try,
but with nouveau it always seem to happen.

> It might be, that lspci does not only power the GPU on, but triggers
> another pci action which causes the race condition.
> Does this have something to do with your quote about the retrain bit?

That is an interesting hypothesis. Even if you invoke `lspci -s01:00.0`
for example, it will always probe for all devices. So maybe interaction
with its parent device (PCI root port 00:02.0) causes issues.

However I also tested without lspci before, and the problem still
exists. You can trigger runtime resume via (as root):

echo > /sys/bus/pci/:01:00.0/power/control on

Set it to "auto" to make it sleep again.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

[Zanoni, Paulo R]

Hi

Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> > 
> > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > > 
> > > We seem to have an xrandr regression with skylake now.  What's
> > > happening is that I can get output on to a projector, but the 
> > > system is losing video when I change the xrandr sessions (like 
> > > going from a --above b to a --same-as b).  The main screen goes 
> > > blank, which is basically a reboot situation.  Unfortunately, I 
> > > can't seem to get the logs out of systemd to see if there was a 
> > > dump to dmesg (the system was definitely responding).
> > > 
> > > I fell back to 4.6.2 which worked perfectly, so this is
> > > definitely 
> > > some sort of regression.  I'll be able to debug more fully when
> > > I 
> > > get back home from the Linux Security Summit.
> > 
> > I'm home now.  Unfortunately, my monitor isn't as problematic as
> > the
> > projector, but by flipping between various modes and separating and
> > overlaying the panels with --above and --same-as (xrandr), I can
> > eventually get it to the point where the main LCD panel goes black 
> > and can only be restarted by specifying a different mode.
> > 
> > This seems to be associated with these lines in the X
> > 
> > [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument
> > [22]
> > 
> > But the curious thing is that even if this fails with the error 
> > message once, it may succeed a second time, so it looks to be a 
> > transient error translation problem from the kernel driver.
> > 
> > I've attached the full log below.
> > 
> > This is only with a VGA output.  I currently don't have a HDMI 
> > dongle, but I'm in the process of acquiring one.
> 
> After more playing around, I'm getting thousands of these in the
> kernel
> log (possibly millions: the log wraps very fast):
> 
> [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR* failed
> to train DP, aborting
> 
> And then finally it gives up with 
> 
> [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe B FIFO underrun
> [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
> 
> And the crtc for the VGA output becomes non-responsive to any
> configuration command.  This requires a reboot and sometimes a UEFI
> variable reset before it comes back.

Please see this discussion:
https://patchwork.freedesktop.org/patch/103237/

Do you have this patch on your tree? Does the problem go away if you
revert it?

Thanks,
Paulo

> 
> James
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

[Jyri Sarha]

On 08/31/16 21:04, Tony Lindgren wrote:
> * Jyri Sarha  [160831 06:19]:
>>   ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC
>> node
>>   ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node
>>   ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
>>   ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node
> 
> If some of these dts changes are OK for me to apply separately already,
> please let me know.
> 
> Otherwise I'll tag this thread as read and assume you'll send the dts
> changes separately when ready :)
> 

According to my plan the drm side changes should go into 4.9.

The commit messages and the comments may look confusing without the
implementation, but otherwise there should be no harm in applying these
already. The new properties in dts simply wont have any effect. On the
other hand, not having the dts changes won't have any dramatic effect
either. The supported colour formats will just remain in the same
incorrect state as they have always been until the dts changes are
there. So what ever is more convenient for you.

Thanks,
Jyri

[PATCH] drm/omapdrm: Remove double gamma table write in omap_crtc_atomic_flush()

[Jyri Sarha]

Remove double gamma table write in omap_crtc_atomic_flush().
Fixes commit 492a426a2fc53
("drm/omapdrm: Implement gamma_lut atomic crtc properties")

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 180f644..bdbbe3d 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -411,19 +411,6 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
dispc_mgr_set_gamma(omap_crtc->channel, lut, length);
}

-   if (crtc->state->color_mgmt_changed) {
-   struct drm_color_lut *lut = NULL;
-   uint length = 0;
-
-   if (crtc->state->gamma_lut) {
-   lut = (struct drm_color_lut *)
-   crtc->state->gamma_lut->data;
-   length = crtc->state->gamma_lut->length /
-   sizeof(*lut);
-   }
-   dispc_mgr_set_gamma(omap_crtc->channel, lut, length);
-   }
-
if (dispc_mgr_is_enabled(omap_crtc->channel)) {

DBG("%s: GO", omap_crtc->name);
-- 
1.9.1

[PATCH] modetest: Also print the pixel clock

[Stéphane Marchesin]

This can be useful for debugging. xrandr prints it, so why not.
---
 tests/modetest/modetest.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 21d5438..dedd286 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -198,7 +198,7 @@ static void dump_encoders(struct device *dev)

 static void dump_mode(drmModeModeInfo *mode)
 {
-   printf("  %s %d %d %d %d %d %d %d %d %d",
+   printf("  %s %d %d %d %d %d %d %d %d %d %d",
   mode->name,
   mode->vrefresh,
   mode->hdisplay,
@@ -208,7 +208,8 @@ static void dump_mode(drmModeModeInfo *mode)
   mode->vdisplay,
   mode->vsync_start,
   mode->vsync_end,
-  mode->vtotal);
+  mode->vtotal,
+  mode->clock);

printf(" flags: ");
mode_flag_str(mode->flags);
-- 
2.8.0.rc3.226.g39d4020

[PATCH] drm/sun4i: Clear encoder->bridge if a bridge is not found

[Chen-Yu Tsai]

Hi Maxime,

On Tue, Aug 30, 2016 at 11:51 PM, Chen-Yu Tsai  wrote:
> On Tue, Aug 30, 2016 at 8:56 PM, Maxime Ripard
>  wrote:
>> Hi,
>>
>> On Tue, Aug 30, 2016 at 08:22:23PM +0800, Chen-Yu Tsai wrote:
>>> The KMS helpers (drm_atomic_helper_check_modeset/mode_fixup) pass
>>> encoder->bridge directly to drm_bridge_mode_fixup, which expects a
>>> valid pointer, or NULL (in which case it just returns).
>>>
>>> Clear encoder->bridge if a bridge is not found, instead of keeping
>>> the ERR_PTR value.
>>>
>>> Since other drm_bridge functions also follow this pattern of checking
>>> for a non-NULL pointer, we can drop the ifs around the calls and just
>>> pass the pointer directly.
>>>
>>> Fixes: 894f5a9f4b4a ("drm/sun4i: Add bridge support")
>>> Signed-off-by: Chen-Yu Tsai 
>>> ---
>>>  drivers/gpu/drm/sun4i/sun4i_rgb.c | 11 ++-
>>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
>>> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
>>> index d4e52522ec53..ee0795152a33 100644
>>> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
>>> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
>>> @@ -154,8 +154,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder 
>>> *encoder)
>>>   if (!IS_ERR(tcon->panel))
>>>   drm_panel_enable(tcon->panel);
>>>
>>> - if (!IS_ERR(encoder->bridge))
>>> - drm_bridge_enable(encoder->bridge);
>>> + drm_bridge_enable(encoder->bridge);
>>>
>>>   sun4i_tcon_channel_enable(tcon, 0);
>>>  }
>>> @@ -170,8 +169,7 @@ static void sun4i_rgb_encoder_disable(struct 
>>> drm_encoder *encoder)
>>>
>>>   sun4i_tcon_channel_disable(tcon, 0);
>>>
>>> - if (!IS_ERR(encoder->bridge))
>>> - drm_bridge_disable(encoder->bridge);
>>> + drm_bridge_disable(encoder->bridge);
>>
>> I'd rather keep those changes, it makes it obvious that it's something
>> optionnal, that can be set to NULL.
>
> OK.

What about having a comment instead? Saves an extra branch condition,
while still showing that it's optional.

ChenYu

>
>>>   if (!IS_ERR(tcon->panel))
>>>   drm_panel_disable(tcon->panel);
>>> @@ -230,6 +228,9 @@ int sun4i_rgb_init(struct drm_device *drm)
>>>   return 0;
>>>   }
>>>
>>> + if (IS_ERR(encoder->bridge))
>>> + encoder->bridge = NULL;
>>> +
>>
>> And that could be the else condition of the if statement below.
>
> That would be a bit confusing, changing it after calling drm_encoder_init.
> The code says it ok to do though.
>
> ChenYu
>
>> Thanks!
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com

[PATCH 2/3] drm/bridge: adv7533: Initialize regulators

[Laurent Pinchart]

Hi Archit,

Thank you for the patch.

On Wednesday 31 Aug 2016 16:22:09 Archit Taneja wrote:
> ADV7533 requires supply to the AVDD, V1P2 and V3P3 pins for proper
> functionality.
> 
> Initialize and enable the regulators during probe itself. Controlling
> these dynamically is left for later.

You should document the power supplies in the DT bindings.

> Cc: dri-devel at lists.freedesktop.org
> Cc: Laurent Pinchart 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511.h | 16 ++
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 34 +++--
>  drivers/gpu/drm/bridge/adv7511/adv7533.c | 45 +
>  3 files changed, 86 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 161c923..3fcb202 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -327,6 +328,10 @@ struct adv7511 {
> 
>   struct gpio_desc *gpio_pd;
> 
> + struct regulator *avdd;
> + struct regulator *v1p2;
> + struct regulator *v3p3;
> +
>   /* ADV7533 DSI RX related params */
>   struct device_node *host_node;
>   struct mipi_dsi_device *dsi;
> @@ -343,6 +348,8 @@ void adv7533_mode_set(struct adv7511 *adv, struct
> drm_display_mode *mode); int adv7533_patch_registers(struct adv7511 *adv);
>  void adv7533_uninit_cec(struct adv7511 *adv);
>  int adv7533_init_cec(struct adv7511 *adv);
> +int adv7533_init_regulators(struct adv7511 *adv);
> +void adv7533_uninit_regulators(struct adv7511 *adv);
>  int adv7533_attach_dsi(struct adv7511 *adv);
>  void adv7533_detach_dsi(struct adv7511 *adv);
>  int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
> @@ -374,6 +381,15 @@ static inline int adv7533_init_cec(struct adv7511 *adv)
> return -ENODEV;
>  }
> 
> +static inline int adv7533_init_regulators(struct adv7511 *adv)
> +{
> + return -ENODEV;
> +}
> +
> +static inline void adv7533_uninit_regulators(struct adv7511 *adv)
> +{
> +}
> +
>  static inline int adv7533_attach_dsi(struct adv7511 *adv)
>  {
>   return -ENODEV;
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index ec8fb2e..221bc75
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -941,6 +941,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) if (!adv7511)
>   return -ENOMEM;
> 
> + adv7511->i2c_main = i2c;
>   adv7511->powered = false;
>   adv7511->status = connector_status_disconnected;
> 
> @@ -958,13 +959,21 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) if (ret)
>   return ret;
> 
> + if (adv7511->type == ADV7533) {
> + ret = adv7533_init_regulators(adv7511);
> + if (ret)
> + return ret;
> + }
> +
>   /*
>* The power down GPIO is optional. If present, toggle it from active 
to
>* inactive to wake up the encoder.
>*/
>   adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
> - if (IS_ERR(adv7511->gpio_pd))
> - return PTR_ERR(adv7511->gpio_pd);
> + if (IS_ERR(adv7511->gpio_pd)) {
> + ret = PTR_ERR(adv7511->gpio_pd);
> + goto uninit_regulators;
> + }
> 
>   if (adv7511->gpio_pd) {
>   mdelay(5);
> @@ -972,12 +981,14 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) }
> 
>   adv7511->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
> - if (IS_ERR(adv7511->regmap))
> - return PTR_ERR(adv7511->regmap);
> + if (IS_ERR(adv7511->regmap)) {
> + ret = PTR_ERR(adv7511->regmap);
> + goto uninit_regulators;
> + }
> 
>   ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, );
>   if (ret)
> - return ret;
> + goto uninit_regulators;
>   dev_dbg(dev, "Rev. %d\n", val);
> 
>   if (adv7511->type == ADV7511)
> @@ -987,7 +998,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) else
>   ret = adv7533_patch_registers(adv7511);
>   if (ret)
> - return ret;
> + goto uninit_regulators;
> 
>   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, 
edid_i2c_addr);
>   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
> @@ -995,10 +1006,11 @@ static int adv7511_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id) regmap_write(adv7511->regmap,
> ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr); adv7511_packet_disable(adv7511,
> 0x);
> 
> - adv7511->i2c_main = i2c;
>   adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, 

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

More -misc stuff
- moar drm_crtc.c split up
- some fixes for the simple kms helpers (Andrea)
- I included all the dri1 patches from David - we're not removing any code
  or drivers, and it seems to have worked as a wake-up call to motivate a
  few more people to upstream kms conversions for these. Feel free to
  revert if you disagree strongly.
- a few other single patches

I'll be on vacation next 2 weeks, but there's nothing big outstanding in
drm core afaikj, and Sean/Archit/Sumit and Thierry can take care of the
small bits. I'll wrap it all up in a pull request when I'm back (well,
probably when I'm at XDC already ...). Same for drm-intel, you'll get pull
request for the final 4.9 feature piles when I'm back again. A bit later
than usual, but still comfortably before the merge window opens I think.
Otherwise I don't think anything needs to be done, but Jani's around in
case of a real fire.

Cheers, Daniel


The following changes since commit 0d42204f374380b6334de7dd2fe7e7d795250290:

  drm/doc: Document uapi requirements in DRM (2016-08-24 07:13:08 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-08-31

for you to fetch changes up to 339fd36238dd3494bc4617d181e7a37922c29ee9:

  drm: drm_probe_helper: Fix output_poll_work scheduling (2016-08-31 13:23:30 
+0200)


Andrea Merello (3):
  drm/bridge: introduce bridge detaching mechanism
  drm: simple_kms_helper: make connector optional at init time
  drm: simple_kms_helper: add support for bridges

Arnd Bergmann (1):
  drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && 
DRM=y

Daniel Vetter (11):
  drm/doc: Fix vga_switcheroo xref
  drm/simple-helpers: Always add planes to the state update
  drm: Extract drm_encoder.[hc]
  drm/doc: Polish kerneldoc for encoders
  drm: Extract drm_mode_object.[hc]
  drm: Remove drm_mode_object->atomic_count
  drm/doc: Polish docs for drm_mode_object
  drm: move drm_mode_legacy_fb_format to drm_fourcc.c
  drm: Extract drm_property.[hc]
  drm: Unify handling of blob and object properties
  drm/doc: Polish docs for drm_property_property_blob

David Herrmann (3):
  drm: hide legacy drivers with CONFIG_DRM_LEGACY
  drm: make DRI1 drivers depend on BROKEN
  drm: reduce GETCLIENT to a minimum

Jose Abreu (1):
  drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

Liu Ying (3):
  drm/atomic-helper: Add atomic_disable CRTC helper callback
  drm/atomic-helper: Disable appropriate planes in disable_planes_on_crtc()
  drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane 
commit

Masahiro Yamada (1):
  drm/gma500: remove unnecessary config_enabled() guard

Peter Ujfalusi (1):
  drm: drm_probe_helper: Fix output_poll_work scheduling

 Documentation/gpu/drm-kms.rst|  159 +--
 Documentation/gpu/vga-switcheroo.rst |2 +
 drivers/gpu/drm/Kconfig  |  136 ++-
 drivers/gpu/drm/Makefile |3 +-
 drivers/gpu/drm/arm/malidp_drv.c |3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |2 +-
 drivers/gpu/drm/bridge/dw-hdmi.c |7 +-
 drivers/gpu/drm/drm_atomic_helper.c  |   61 +-
 drivers/gpu/drm/drm_bridge.c |   29 +-
 drivers/gpu/drm/drm_crtc.c   | 1625 +-
 drivers/gpu/drm/drm_crtc_internal.h  |   90 +-
 drivers/gpu/drm/drm_encoder.c|  232 
 drivers/gpu/drm/drm_fourcc.c |   43 +
 drivers/gpu/drm/drm_ioctl.c  |5 +-
 drivers/gpu/drm/drm_mode_object.c|  437 +++
 drivers/gpu/drm/drm_probe_helper.c   |8 +-
 drivers/gpu/drm/drm_property.c   |  899 ++
 drivers/gpu/drm/drm_simple_kms_helper.c  |   58 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |2 +-
 drivers/gpu/drm/gma500/opregion.c|5 +-
 drivers/gpu/drm/imx/imx-drm-core.c   |3 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |6 +-
 drivers/gpu/drm/msm/msm_atomic.c |2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |3 +-
 drivers/gpu/drm/sti/sti_drv.c|2 +-
 drivers/gpu/drm/tegra/drm.c  |3 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |2 +-
 drivers/gpu/drm/vc4/vc4_kms.c|2 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |3 +-
 include/drm/drm_atomic_helper.h  |   11 +-
 include/drm/drm_connector.h  |2 +-
 include/drm/drm_crtc.h   |  262 +
 include/drm/drm_encoder.h|  227 
 include/drm/drm_fb_helper.h  

[PATCH] drm/sun4i: Clear encoder->bridge if a bridge is not found

[Maxime Ripard]

On Wed, Aug 31, 2016 at 06:27:08PM +0200, Daniel Vetter wrote:
> > > >> + if (IS_ERR(encoder->bridge))
> > > >> + encoder->bridge = NULL;
> > > >> +
> > > >
> > > > And that could be the else condition of the if statement below.
> > > 
> > > That would be a bit confusing, changing it after calling drm_encoder_init.
> > > The code says it ok to do though.
> > 
> > The magic really happens only after the encoder has been attached to
> > something, so it's really safe.
> 
> s/attached/registered using drm_dev_register(). Which should
> happen _way_ later for all drivers which have gotten rid of their ->load
> callback and implemented the recommend driver load sequence.

My bad, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160831/39904c8d/attachment.sig>

[PATCH] drm/sun4i: Clear encoder->bridge if a bridge is not found

[Maxime Ripard]

On Wed, Aug 31, 2016 at 07:09:23PM +0800, Chen-Yu Tsai wrote:
> >>>   sun4i_tcon_channel_disable(tcon, 0);
> >>>
> >>> - if (!IS_ERR(encoder->bridge))
> >>> - drm_bridge_disable(encoder->bridge);
> >>> + drm_bridge_disable(encoder->bridge);
> >>
> >> I'd rather keep those changes, it makes it obvious that it's something
> >> optionnal, that can be set to NULL.
> >
> > OK.
> 
> What about having a comment instead? Saves an extra branch condition,
> while still showing that it's optional.

I'm not sure we have to worry about an extra branch condition, but
yeah, that works for me.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160831/05fc9ca6/attachment.sig>

[PATCH] drm/sun4i: Clear encoder->bridge if a bridge is not found

[Daniel Vetter]

On Wed, Aug 31, 2016 at 05:40:02PM +0200, Maxime Ripard wrote:
> On Tue, Aug 30, 2016 at 11:51:26PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Aug 30, 2016 at 8:56 PM, Maxime Ripard
> >  wrote:
> > > Hi,
> > >
> > > On Tue, Aug 30, 2016 at 08:22:23PM +0800, Chen-Yu Tsai wrote:
> > >> The KMS helpers (drm_atomic_helper_check_modeset/mode_fixup) pass
> > >> encoder->bridge directly to drm_bridge_mode_fixup, which expects a
> > >> valid pointer, or NULL (in which case it just returns).
> > >>
> > >> Clear encoder->bridge if a bridge is not found, instead of keeping
> > >> the ERR_PTR value.
> > >>
> > >> Since other drm_bridge functions also follow this pattern of checking
> > >> for a non-NULL pointer, we can drop the ifs around the calls and just
> > >> pass the pointer directly.
> > >>
> > >> Fixes: 894f5a9f4b4a ("drm/sun4i: Add bridge support")
> > >> Signed-off-by: Chen-Yu Tsai 
> > >> ---
> > >>  drivers/gpu/drm/sun4i/sun4i_rgb.c | 11 ++-
> > >>  1 file changed, 6 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> > >> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > >> index d4e52522ec53..ee0795152a33 100644
> > >> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > >> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > >> @@ -154,8 +154,7 @@ static void sun4i_rgb_encoder_enable(struct 
> > >> drm_encoder *encoder)
> > >>   if (!IS_ERR(tcon->panel))
> > >>   drm_panel_enable(tcon->panel);
> > >>
> > >> - if (!IS_ERR(encoder->bridge))
> > >> - drm_bridge_enable(encoder->bridge);
> > >> + drm_bridge_enable(encoder->bridge);
> > >>
> > >>   sun4i_tcon_channel_enable(tcon, 0);
> > >>  }
> > >> @@ -170,8 +169,7 @@ static void sun4i_rgb_encoder_disable(struct 
> > >> drm_encoder *encoder)
> > >>
> > >>   sun4i_tcon_channel_disable(tcon, 0);
> > >>
> > >> - if (!IS_ERR(encoder->bridge))
> > >> - drm_bridge_disable(encoder->bridge);
> > >> + drm_bridge_disable(encoder->bridge);
> > >
> > > I'd rather keep those changes, it makes it obvious that it's something
> > > optionnal, that can be set to NULL.
> > 
> > OK.
> > 
> > >>   if (!IS_ERR(tcon->panel))
> > >>   drm_panel_disable(tcon->panel);
> > >> @@ -230,6 +228,9 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >>   return 0;
> > >>   }
> > >>
> > >> + if (IS_ERR(encoder->bridge))
> > >> + encoder->bridge = NULL;
> > >> +
> > >
> > > And that could be the else condition of the if statement below.
> > 
> > That would be a bit confusing, changing it after calling drm_encoder_init.
> > The code says it ok to do though.
> 
> The magic really happens only after the encoder has been attached to
> something, so it's really safe.

s/attached/registered using drm_dev_register(). Which should
happen _way_ later for all drivers which have gotten rid of their ->load
callback and implemented the recommend driver load sequence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] drm/udl: fix a NULL pointer reference in udl_gem_free_object().

[Haixia Shi]

Daniel

Thanks! I agree the PATCH 1/2 needs some more work.

What do you think about the PATCH 2/2 (suspend/resume) -- would it
make sense to review it as a single standalone patch?

Regards, Haixia

On Wed, Aug 31, 2016 at 2:17 PM, Daniel Vetter  wrote:
> On Wed, Aug 31, 2016 at 11:05 PM, Daniel Vetter  wrote:
>> On Wed, Aug 31, 2016 at 10:45 PM, Haixia Shi  wrote:
>>> For details see https://bugs.chromium.org/p/chromium/issues/detail?id=468050
>>>
>>> So drm_mode_config_cleanup() is called from udl_driver_unload() in
>>> which we found there's still a framebuffer left, hence the WARN in
>>> drm_crtc.c:5495. This also forcefully releases all the buffers.
>>>
>>> A bit later the actual drm_buf_release comes in which attempts to
>>> release the buffer again.
>>
>> Leaving a drm_framebuffer behind on unload is definitely a bug, but
>> not fixed with this patch here I think.
>>
>> The dma-buf lifetime issue is far worse, since we simply don't
>> handling those leaking past the lifetime of the exporting drm_device
>> at all. The dma-buf has references to a lot more than just the vma
>> manager. What we probably need is that every exported dma-buf holds a
>> ref on the underlying drm_device, but that means untangling the
>> refcounting of that vs unplugging it.
>
> Just noticed that these problems started only when dma-buf export
> support was added (by you) to udl. That dma-buf support is a bit
> hack-ish (e.g. it leaks sg mappings since udl_unmap_dma_buf isn't
> implemented. Rough sketch of a fix:
>
> - fix up udl_dmabuf.c. We could/should probably put most of these into
> the core as a set of helpers for drivers which use plain shmem gem
> objects.
>
> - fix udl load/unload to no longer be midlayered, i.e. get rid of the
> ->load/unload hooks. There's tons of examples and drivers out there
> for templates.
>
> - fix up the unplug hook to correctly unregister everything. With the
> fixed load/unload all the unplugged tracking is probably no longer
> neeeded. Also with this you can drop the drm_global_mutex dance from
> drm_unplug_dev. Also the sequence in drm_unplug_dev is wrong like the
> midlayered ->unload. First it should do all the unregistering, then
> release internal resources. Atm it's the other way round.
>
> - make sure _all_ public objects (open files, counted by
> dev->open_count, dma-bufs, ...) hold a full reference onto the
> drm_device. For the dma-buf case this probably needs changes in
> drm_prime.c.
>
> - Fix that little ordering issue with the leaking fb. It's probably
> not getting cleanup up as it should in udl_fbdev_unplug.
>
> tada, bug fixed for real!
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v7 2/8] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

[Heiko Stübner]

Am Montag, 22. August 2016, 11:36:18 schrieb Lin Huang:
> Signed-off-by: Lin Huang 

applied to my shared clock-id branch for 4.9

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

[Daniel Vetter]

We removed it in

commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
Author: Daniel Vetter 
Date:   Fri Aug 12 22:48:45 2016 +0200

drm/kms: Nuke dirty_info property

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/kms-properties.csv | 1 -
 1 file changed, 1 deletion(-)

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

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

[Daniel Vetter]

Again move it from the unmaintainable csv into DOC free-form overview
sections.

Cc: Lionel Landwerlin 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst| 12 +
 Documentation/gpu/kms-properties.csv |  5 
 drivers/gpu/drm/drm_color_mgmt.c | 48 
 include/drm/drm_color_mgmt.h | 11 ++---
 4 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 6be8d3359620..53b872c105d2 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -296,6 +296,18 @@ Plane Composition Properties
 .. kernel-doc:: drivers/gpu/drm/drm_blend.c
:export:

+Color Management Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_color_mgmt.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+   :export:
+
 Existing KMS Properties
 ---

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

 #include "drm_crtc_internal.h"

+/**
+ * DOC: overview
+ *
+ * Color management or color space adjustements is supported through a set of 5
+ * properties on the _crtc object. They are set up by calling
+ * drm_crtc_enable_color_mgmt().
+ *
+ * "DEGAMMA_LUT”:
+ * Blob property to set the degamma lookup table (LUT) mapping pixel data
+ * from the framebuffer before it is given to the transformation matrix.
+ * The data is an interpreted as an array of struct _color_lut 
elements.
+ * Hardware might choose not to use the full precision of the LUT elements
+ * nor use all the elements of the LUT (for example the hardware might
+ * choose to interpolate between LUT[0] and LUT[4]).
+ *
+ * “DEGAMMA_LUT_SIZE”:
+ * Unsinged range property to gives the size of the lookup table to be set
+ * on the DEGAMMA_LUT property (the size depends on the underlying
+ * hardware). If drivers support multiple LUT sizes then they should
+ * publish the largest size, and sub-sample smaller sized LUTs (e.g. for
+ * split-gamma modes) 

[PATCH 08/10] drm: Extract drm_color_mgmt.[hc]

[Daniel Vetter]

For both the new degamm/lut/gamma atomic combo, and the old legacy
gamma tables.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_color_mgmt.c| 248 
 drivers/gpu/drm/drm_crtc.c  | 220 
 drivers/gpu/drm/drm_crtc_internal.h |   4 +
 include/drm/drm_color_mgmt.h|  56 
 include/drm/drm_crtc.h  |  28 +---
 6 files changed, 310 insertions(+), 248 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_color_mgmt.c
 create mode 100644 include/drm/drm_color_mgmt.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8eeb07a35798..25c720454017 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -15,7 +15,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
-   drm_plane.o
+   drm_plane.o drm_color_mgmt.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
new file mode 100644
index ..aca1b7a6397c
--- /dev/null
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -0,0 +1,248 @@
+/*
+ * Copyright (c) 2016 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include "drm_crtc_internal.h"
+
+
+/**
+ * drm_crtc_enable_color_mgmt - enable color management properties
+ * @crtc: DRM CRTC
+ * @degamma_lut_size: the size of the degamma lut (before CSC)
+ * @has_ctm: whether to attach ctm_property for CSC matrix
+ * @gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a CRTC. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
+   uint degamma_lut_size,
+   bool has_ctm,
+   uint gamma_lut_size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+
+   if (degamma_lut_size) {
+   drm_object_attach_property(>base,
+  config->degamma_lut_property, 0);
+   drm_object_attach_property(>base,
+  config->degamma_lut_size_property,
+  degamma_lut_size);
+   }
+
+   if (has_ctm)
+   drm_object_attach_property(>base,
+  config->ctm_property, 0);
+
+   if (gamma_lut_size) {
+   drm_object_attach_property(>base,
+  config->gamma_lut_property, 0);
+   drm_object_attach_property(>base,
+  config->gamma_lut_size_property,
+  gamma_lut_size);
+   }
+}
+EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
+
+/**
+ * drm_mode_crtc_set_gamma_size - set the gamma table size
+ * @crtc: CRTC to set the gamma table size for
+ * @gamma_size: size of the gamma table
+ *
+ * Drivers which support gamma tables should set this to the supported gamma
+ * table size when initializing the CRTC. Currently the drm core only supports 
a
+ * fixed gamma table size.
+ *
+ * Returns:
+ * 

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

[Daniel Vetter]

Try to spec a bit more precisely how they all fit together, now that
at least the code is for all the additional properties is in one
place.

Also remove the entries for the standardized properties from the
table, because that thing is supremely unmaintaineable.

Cc: Ville Syrjälä 
Cc: Sean Paul 
Cc: Benjamin Gaignard 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst|   7 +-
 Documentation/gpu/kms-properties.csv |  15 
 drivers/gpu/drm/drm_blend.c  | 146 ++-
 drivers/gpu/drm/drm_plane.c  |   3 +
 4 files changed, 136 insertions(+), 35 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index b1029e292e5c..6be8d3359620 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -287,8 +287,11 @@ Property Types and Blob Property Support
 .. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:

-Blending and Z-Position properties
---
+Plane Composition Properties
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_blend.c
+   :doc: overview

 .. kernel-doc:: drivers/gpu/drm/drm_blend.c
:export:
diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 4c5ce3edcfd9..1aa2493d1ef9 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -1,23 +1,10 @@
 Owner Module/Drivers,Group,Property Name,Type,Property Values,Object 
attached,Description/Restrictions
-DRM,Generic,“rotation”,BITMASK,"{ 0, ""rotate-0"" }, { 1, ""rotate-90"" }, 
{ 2, ""rotate-180"" }, { 3, ""rotate-270"" }, { 4, ""reflect-x"" }, { 5, 
""reflect-y"" }","CRTC, Plane",rotate-(degrees) rotates the image by the 
specified amount in degrees in counter clockwise direction. reflect-x and 
reflect-y reflects the image along the specified axis prior to rotation
 ,,“scaling mode”,ENUM,"{ ""None"", ""Full"", ""Center"", ""Full aspect"" 
}",Connector,"Supported by: amdgpu, gma500, i915, nouveau and radeon."
 ,Connector,“EDID”,BLOB | IMMUTABLE,0,Connector,Contains id of edid blob 
ptr object.
 ,,“DPMS”,ENUM,"{ “On”, “Standby”, “Suspend”, “Off” 
}",Connector,Contains DPMS operation mode value.
 ,,“PATH”,BLOB | IMMUTABLE,0,Connector,Contains topology path to a 
connector.
 ,,“TILE”,BLOB | IMMUTABLE,0,Connector,Contains tiling information for a 
connector.
 ,,“CRTC_ID”,OBJECT,DRM_MODE_OBJECT_CRTC,Connector,CRTC that connector is 
attached to (atomic)
-,Plane,“type”,ENUM | IMMUTABLE,"{ ""Overlay"", ""Primary"", ""Cursor"" 
}",Plane,Plane type
-,,“SRC_X”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source x coordinate in 
16.16 fixed point (atomic)
-,,“SRC_Y”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source y coordinate in 
16.16 fixed point (atomic)
-,,“SRC_W”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source width in 16.16 
fixed point (atomic)
-,,“SRC_H”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout source height in 16.16 
fixed point (atomic)
-,,“CRTC_X”,SIGNED_RANGE,"Min=INT_MIN, Max=INT_MAX",Plane,Scanout CRTC 
(destination) x coordinate (atomic)
-,,“CRTC_Y”,SIGNED_RANGE,"Min=INT_MIN, Max=INT_MAX",Plane,Scanout CRTC 
(destination) y coordinate (atomic)
-,,“CRTC_W”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination) 
width (atomic)
-,,“CRTC_H”,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination) 
height (atomic)
-,,“FB_ID”,OBJECT,DRM_MODE_OBJECT_FB,Plane,Scanout framebuffer (atomic)
-,,“CRTC_ID”,OBJECT,DRM_MODE_OBJECT_CRTC,Plane,CRTC that plane is attached 
to (atomic)
-,,“zpos”,RANGE,"Min=0, Max=UINT_MAX","Plane,Z-order of the plane.Planes 
with higher Z-order values are displayed on top, planes with identical Z-order 
values are display in an undefined order"
 ,DVI-I,“subconnector”,ENUM,"{ “Unknown”, “DVI-D”, “DVI-A” 
}",Connector,TBD
 ,,“select subconnector”,ENUM,"{ “Automatic”, “DVI-D”, “DVI-A” 
}",Connector,TBD
 ,TV,“subconnector”,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", 
""Component"", ""SCART"" }",Connector,TBD
@@ -95,7 +82,6 @@ armada,CRTC,"""CSC_YUV""",ENUM,"{ ""Auto"" , ""CCIR601"", 
""CCIR709"" }",CRTC,TB
 ,,"""contrast""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
 ,,"""saturation""",RANGE,"Min=0, Max=0x7fff",Plane,TBD
 exynos,CRTC,“mode”,ENUM,"{ ""normal"", ""blank"" }",CRTC,TBD
-,Overlay,“zpos”,RANGE,"Min=0, Max=MAX_PLANE-1",Plane,TBD
 i2c/ch7006_drv,Generic,“scale”,RANGE,"Min=0, Max=2",Connector,TBD
 ,TV,“mode”,ENUM,"{ ""PAL"", ""PAL-M"",""PAL-N""}, ”PAL-Nc"" , 
""PAL-60"", ""NTSC-M"", ""NTSC-J"" }",Connector,TBD
 nouveau,NV10 Overlay,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
@@ -126,4 +112,3 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, 
Max=1",Connector,TBD
 ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
 rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
 

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

[Daniel Vetter]

Imo zpos, rotatation, blending eq (once we have it) and all that
should be in drm_blend.c, since those are all about how exactly the
pixels are rendered onto the CRTC's visible area. Also noticed that
one exported function accidentally ended up in drm_crtc_internal.h,
move it to the right place too.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_blend.c | 51 ++--
 drivers/gpu/drm/drm_crtc.c  | 49 --
 drivers/gpu/drm/drm_crtc_internal.h |  3 --
 include/drm/drm_blend.h | 59 +
 include/drm/drm_crtc.h  | 27 +
 5 files changed, 109 insertions(+), 80 deletions(-)
 create mode 100644 include/drm/drm_blend.h

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0813b7e021be..ab39245a21c4 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -25,12 +25,59 @@
  */
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

-#include "drm_internal.h"
+struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
+  unsigned int 
supported_rotations)
+{
+   static const struct drm_prop_enum_list props[] = {
+   { __builtin_ffs(DRM_ROTATE_0) - 1,   "rotate-0" },
+   { __builtin_ffs(DRM_ROTATE_90) - 1,  "rotate-90" },
+   { __builtin_ffs(DRM_ROTATE_180) - 1, "rotate-180" },
+   { __builtin_ffs(DRM_ROTATE_270) - 1, "rotate-270" },
+   { __builtin_ffs(DRM_REFLECT_X) - 1,  "reflect-x" },
+   { __builtin_ffs(DRM_REFLECT_Y) - 1,  "reflect-y" },
+   };
+
+   return drm_property_create_bitmask(dev, 0, "rotation",
+  props, ARRAY_SIZE(props),
+  supported_rotations);
+}
+EXPORT_SYMBOL(drm_mode_create_rotation_property);
+
+/**
+ * drm_rotation_simplify() - Try to simplify the rotation
+ * @rotation: Rotation to be simplified
+ * @supported_rotations: Supported rotations
+ *
+ * Attempt to simplify the rotation to a form that is supported.
+ * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * one could call this function like this:
+ *
+ * drm_rotation_simplify(rotation, DRM_ROTATE_0 |
+ *   DRM_ROTATE_90 | DRM_ROTATE_180 |
+ *   DRM_ROTATE_270 | DRM_REFLECT_Y);
+ *
+ * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
+ * transforms the hardware supports, this function may not
+ * be able to produce a supported transform, so the caller should
+ * check the result afterwards.
+ */
+unsigned int drm_rotation_simplify(unsigned int rotation,
+  unsigned int supported_rotations)
+{
+   if (rotation & ~supported_rotations) {
+   rotation ^= DRM_REFLECT_X | DRM_REFLECT_Y;
+   rotation = (rotation & DRM_REFLECT_MASK) |
+  BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
+   }
+
+   return rotation;
+}
+EXPORT_SYMBOL(drm_rotation_simplify);

 /**
  * drm_plane_create_zpos_property - create mutable zpos property
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9ef7955032db..e5229b48d5d5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1218,37 +1218,6 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
 }

 /**
- * drm_rotation_simplify() - Try to simplify the rotation
- * @rotation: Rotation to be simplified
- * @supported_rotations: Supported rotations
- *
- * Attempt to simplify the rotation to a form that is supported.
- * Eg. if the hardware supports everything except DRM_REFLECT_X
- * one could call this function like this:
- *
- * drm_rotation_simplify(rotation, DRM_ROTATE_0 |
- *   DRM_ROTATE_90 | DRM_ROTATE_180 |
- *   DRM_ROTATE_270 | DRM_REFLECT_Y);
- *
- * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
- * transforms the hardware supports, this function may not
- * be able to produce a supported transform, so the caller should
- * check the result afterwards.
- */
-unsigned int drm_rotation_simplify(unsigned int rotation,
-  unsigned int supported_rotations)
-{
-   if (rotation & ~supported_rotations) {
-   rotation ^= DRM_REFLECT_X | DRM_REFLECT_Y;
-   rotation = (rotation & DRM_REFLECT_MASK) |
-  BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
-   }
-
-   return rotation;
-}
-EXPORT_SYMBOL(drm_rotation_simplify);
-
-/**
  * drm_mode_config_init - initialize DRM mode_configuration structure
  * @dev: DRM device
  *
@@ -1364,24 +1333,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);

-struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
- 

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

[Daniel Vetter]

Just pure code movement, cleanup and polish will happen in later
patches.

v2: Don't forget all the ioctl! To extract those cleanly I decided to
put check_src_coords into drm_framebuffer.c (and give it a
drm_framebuffer_ prefix), since that just checks framebuffer
constraints.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst   |  12 +
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_crtc.c  | 939 +---
 drivers/gpu/drm/drm_crtc_internal.h |  38 +-
 drivers/gpu/drm/drm_framebuffer.c   |  26 +
 drivers/gpu/drm/drm_plane.c | 937 +++
 include/drm/drm_atomic.h| 154 ++
 include/drm/drm_crtc.h  | 583 +-
 include/drm/drm_plane.h | 470 ++
 9 files changed, 1628 insertions(+), 1534 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_plane.c
 create mode 100644 include/drm/drm_plane.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index f9a991bb87d4..33181be97151 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -110,6 +110,18 @@ Note that dumb objects may not be used for gpu 
acceleration, as has been
 attempted on some ARM embedded platforms. Such drivers really must have
 a hardware-specific ioctl to allocate suitable buffer objects.

+Plane Abstraction
+=
+
+Plane Functions Reference
+-
+
+.. kernel-doc:: include/drm/drm_plane.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+   :export:
+
 Display Modes Function Reference
 

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 439d89b25ae0..8eeb07a35798 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
-   drm_encoder.o drm_mode_object.o drm_property.o
+   drm_encoder.o drm_mode_object.o drm_property.o \
+   drm_plane.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0fad433f4d2d..513ab4729683 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -251,255 +251,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_cleanup);

-static unsigned int drm_num_planes(struct drm_device *dev)
-{
-   unsigned int num = 0;
-   struct drm_plane *tmp;
-
-   drm_for_each_plane(tmp, dev) {
-   num++;
-   }
-
-   return num;
-}
-
-/**
- * drm_universal_plane_init - Initialize a new universal plane object
- * @dev: DRM device
- * @plane: plane object to init
- * @possible_crtcs: bitmask of possible CRTCs
- * @funcs: callbacks for the new plane
- * @formats: array of supported formats (DRM_FORMAT\_\*)
- * @format_count: number of elements in @formats
- * @type: type of plane (overlay, primary, cursor)
- * @name: printf style format string for the plane name, or NULL for default 
name
- *
- * Initializes a plane object of type @type.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
-unsigned long possible_crtcs,
-const struct drm_plane_funcs *funcs,
-const uint32_t *formats, unsigned int format_count,
-enum drm_plane_type type,
-const char *name, ...)
-{
-   struct drm_mode_config *config = >mode_config;
-   int ret;
-
-   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
-   if (ret)
-   return ret;
-
-   drm_modeset_lock_init(>mutex);
-
-   plane->base.properties = >properties;
-   plane->dev = dev;
-   plane->funcs = funcs;
-   plane->format_types = kmalloc_array(format_count, sizeof(uint32_t),
-   GFP_KERNEL);
-   if (!plane->format_types) {
-   DRM_DEBUG_KMS("out of memory when allocating plane\n");
-   drm_mode_object_unregister(dev, >base);
-   return -ENOMEM;
-   }
-
-   if (name) {
-   va_list ap;
-
-   va_start(ap, name);
-   plane->name = kvasprintf(GFP_KERNEL, name, ap);
-   va_end(ap);
-   } else {
-   plane->name = kasprintf(GFP_KERNEL, "plane-%d",
-   drm_num_planes(dev));
-   }
-   if (!plane->name) {
-   kfree(plane->format_types);
-   drm_mode_object_unregister(dev, >base);
-   

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

[Daniel Vetter]

Some were still left in drm_crtc.h. Also include drm_edid.h in the
rst files.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |  3 +++
 include/drm/drm_crtc.h| 30 +-
 include/drm/drm_edid.h| 30 ++
 3 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 48fc5a96bf95..bb4254d19cbb 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -208,6 +208,9 @@ Output Probing Helper Functions Reference
 EDID Helper Functions Reference
 ===

+.. kernel-doc:: include/drm/drm_edid.h
+   :internal:
+
 .. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bf9ee1b97c26..7bb3aa87a8be 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 

 struct drm_device;
 struct drm_mode_set;
@@ -1992,33 +1993,4 @@ assert_drm_connector_list_read_locked(struct 
drm_mode_config *mode_config)
!drm_modeset_is_locked(_config->connection_mutex));
 }

-/* drm_edid.c */
-bool drm_probe_ddc(struct i2c_adapter *adapter);
-struct edid *drm_get_edid(struct drm_connector *connector,
- struct i2c_adapter *adapter);
-struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
-struct i2c_adapter *adapter);
-struct edid *drm_edid_duplicate(const struct edid *edid);
-int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
-
-u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
-enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
-bool drm_detect_hdmi_monitor(struct edid *edid);
-bool drm_detect_monitor_audio(struct edid *edid);
-bool drm_rgb_quant_range_selectable(struct edid *edid);
-int drm_add_modes_noedid(struct drm_connector *connector,
-int hdisplay, int vdisplay);
-void drm_set_preferred_mode(struct drm_connector *connector,
-   int hpref, int vpref);
-
-int drm_edid_header_is_valid(const u8 *raw_edid);
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
- bool *edid_corrupt);
-bool drm_edid_is_valid(struct edid *edid);
-void drm_edid_get_monitor_name(struct edid *edid, char *name,
-  int buflen);
-struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
-  int hsize, int vsize, int fresh,
-  bool rb);
-
 #endif /* __DRM_CRTC_H__ */
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d1beb4..c3a7d440bc11 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -25,6 +25,9 @@

 #include 

+struct drm_device;
+struct i2c_adapter;
+
 #define EDID_LENGTH 128
 #define DDC_ADDR 0x50
 #define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */
@@ -423,9 +426,36 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld)
return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK;
 }

+bool drm_probe_ddc(struct i2c_adapter *adapter);
 struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
  size_t len),
void *data);
+struct edid *drm_get_edid(struct drm_connector *connector,
+ struct i2c_adapter *adapter);
+struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
+struct i2c_adapter *adapter);
+struct edid *drm_edid_duplicate(const struct edid *edid);
+int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
+
+u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
+enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
+bool drm_detect_hdmi_monitor(struct edid *edid);
+bool drm_detect_monitor_audio(struct edid *edid);
+bool drm_rgb_quant_range_selectable(struct edid *edid);
+int drm_add_modes_noedid(struct drm_connector *connector,
+int hdisplay, int vdisplay);
+void drm_set_preferred_mode(struct drm_connector *connector,
+   int hpref, int vpref);
+
+int drm_edid_header_is_valid(const u8 *raw_edid);
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *edid_corrupt);
+bool drm_edid_is_valid(struct edid *edid);
+void drm_edid_get_monitor_name(struct edid *edid, char *name,
+  int buflen);
+struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
+  int hsize, int vsize, int fresh,
+  bool rb);

 #endif /* 

[PATCH 02/10] drm: Extract drm_bridge.h

[Daniel Vetter]

We don't want to burry the bridge structures kerneldoc in drm_crtc.h.

Cc: Archit Taneja 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |   7 ++
 drivers/gpu/drm/drm_bridge.c  |   5 +-
 include/drm/drm_bridge.h  | 218 ++
 include/drm/drm_connector.h   |   4 +
 include/drm/drm_crtc.h| 187 +
 include/drm/drm_mode_object.h |   1 +
 include/drm/drm_modes.h   |   4 +
 7 files changed, 237 insertions(+), 189 deletions(-)
 create mode 100644 include/drm/drm_bridge.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 59fa3c11efab..48fc5a96bf95 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -126,6 +126,13 @@ Default bridge callback sequence
 .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: bridge callbacks

+
+Bridge Helper Reference
+-
+
+.. kernel-doc:: include/drm/drm_bridge.h
+   :internal:
+
 .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 484046664d6c..0ee052b7c21a 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -23,10 +23,9 @@

 #include 
 #include 
+#include 

-#include 
-
-#include "drm/drmP.h"
+#include 

 /**
  * DOC: overview
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
new file mode 100644
index ..530a1d6e8cde
--- /dev/null
+++ b/include/drm/drm_bridge.h
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2016 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#ifndef __DRM_BRIDGE_H__
+#define __DRM_BRIDGE_H__
+
+#include 
+#include 
+#include 
+#include 
+
+struct drm_bridge;
+
+/**
+ * struct drm_bridge_funcs - drm_bridge control functions
+ */
+struct drm_bridge_funcs {
+   /**
+* @attach:
+*
+* This callback is invoked whenever our bridge is being attached to a
+* _encoder.
+*
+* The attach callback is optional.
+*
+* RETURNS:
+*
+* Zero on success, error code on failure.
+*/
+   int (*attach)(struct drm_bridge *bridge);
+
+   /**
+* @detach:
+*
+* This callback is invoked whenever our bridge is being detached from a
+* _encoder.
+*
+* The detach callback is optional.
+*/
+   void (*detach)(struct drm_bridge *bridge);
+
+   /**
+* @mode_fixup:
+*
+* This callback is used to validate and adjust a mode. The paramater
+* mode is the display mode that should be fed to the next element in
+* the display chain, either the final _connector or the next
+* _bridge. The parameter adjusted_mode is the input mode the bridge
+* requires. It can be modified by this callback and does not need to
+* match mode.
+*
+* This is the only hook that allows a bridge to reject a modeset. If
+* this function passes all other callbacks must succeed for this
+* configuration.
+*
+* The mode_fixup callback is optional.
+*
+* NOTE:
+*
+* This function is called in the check phase of atomic modesets, which
+* can be aborted for any reason (including on userspace's request to
+* just check whether a configuration would be possible). Drivers MUST
+* NOT touch any persistent state (hardware or software) or data
+* structures except the passed in @state parameter.
+*
+* RETURNS:
+*
+* True if an acceptable configuration is possible, false if the modeset
+* operation should be rejected.
+*/
+   bool 

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

[Daniel Vetter]

Now that there's less stuff in there I noticed that I overlooked them.
Sprinkle some docs over them while at it.

Signed-off-by: Daniel Vetter 
---
 include/drm/drm_connector.h   | 24 ++--
 include/drm/drm_crtc.h| 32 
 include/drm/drm_encoder.h | 22 ++
 include/drm/drm_framebuffer.h | 17 +
 include/drm/drm_modes.h   |  2 ++
 include/drm/drm_property.h|  1 +
 6 files changed, 64 insertions(+), 34 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 66b7d6744dd2..e4e545e9516d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -181,14 +181,19 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 /**
  * struct drm_connector_state - mutable connector state
  * @connector: backpointer to the connector
- * @crtc: CRTC to connect connector to, NULL if disabled
  * @best_encoder: can be used by helpers and drivers to select the encoder
  * @state: backpointer to global drm_atomic_state
  */
 struct drm_connector_state {
struct drm_connector *connector;

-   struct drm_crtc *crtc;  /* do not write directly, use 
drm_atomic_set_crtc_for_connector() */
+   /**
+* @crtc: CRTC to connect connector to, NULL if disabled.
+*
+* Do not change this directly, use drm_atomic_set_crtc_for_connector()
+* instead.
+*/
+   struct drm_crtc *crtc;

struct drm_encoder *best_encoder;

@@ -744,4 +749,19 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
+
+/**
+ * drm_for_each_connector - iterate over all connectors
+ * @connector: the loop cursor
+ * @dev: the DRM device
+ *
+ * Iterate over all connectors of @dev.
+ */
+#define drm_for_each_connector(connector, dev) \
+   for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
\
+connector = list_first_entry(&(dev)->mode_config.connector_list,   
\
+ struct drm_connector, head);  
\
+>head != (&(dev)->mode_config.connector_list);  
\
+connector = list_next_entry(connector, head))
+
 #endif
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4880606e2ffd..2a642ae96127 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1991,22 +1991,7 @@ struct drm_mode_config {
list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))

-/**
- * drm_for_each_encoder_mask - iterate over encoders specified by bitmask
- * @encoder: the loop cursor
- * @dev: the DRM device
- * @encoder_mask: bitmask of encoder indices
- *
- * Iterate over all encoders specified by bitmask.
- */
-#define drm_for_each_encoder_mask(encoder, dev, encoder_mask) \
-   list_for_each_entry((encoder), &(dev)->mode_config.encoder_list, head) \
-   for_each_if ((encoder_mask) & (1 << drm_encoder_index(encoder)))
-
 #define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
-#define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
-#define obj_to_fb(x) container_of(x, struct drm_framebuffer, base)
-#define obj_to_blob(x) container_of(x, struct drm_property_blob, base)
 #define obj_to_plane(x) container_of(x, struct drm_plane, base)

 extern __printf(6, 7)
@@ -2174,23 +2159,6 @@ assert_drm_connector_list_read_locked(struct 
drm_mode_config *mode_config)
!drm_modeset_is_locked(_config->connection_mutex));
 }

-#define drm_for_each_connector(connector, dev) \
-   for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
\
-connector = list_first_entry(&(dev)->mode_config.connector_list,   
\
- struct drm_connector, head);  
\
->head != (&(dev)->mode_config.connector_list);  
\
-connector = list_next_entry(connector, head))
-
-#define drm_for_each_encoder(encoder, dev) \
-   list_for_each_entry(encoder, &(dev)->mode_config.encoder_list, head)
-
-#define drm_for_each_fb(fb, dev) \
-   for (WARN_ON(!mutex_is_locked(&(dev)->mode_config.fb_lock)),
\
-fb = list_first_entry(&(dev)->mode_config.fb_list, \
- struct drm_framebuffer, head);
\
->head != (&(dev)->mode_config.fb_list);
\
-fb = list_next_entry(fb, head))
-
 /* drm_edid.c */
 bool drm_probe_ddc(struct i2c_adapter *adapter);
 struct edid *drm_get_edid(struct drm_connector *connector,
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 

[PATCH 00/10] More splitting for drm_crtc.c

[Daniel Vetter]

Hi all,

It's not entirely done yet, there's a few (very small bits) left in drm_crtc.c
which aren't for struct drm_crtc. But I figured it's better to keep things in
manageable pieces.

More important this now contains my proposal for how to best document (atomic)
property extensions. I grouped and documented both all properties related to
blending planes, and for color management. I think having separate
chapters, with lots more space for free-form prose (rst-formatted!), close to
the support functions for these properties is a much better than the massive CSV
we have right.

We could probably go even fancier (using some form of ascii-arts, where it makes
sense), but I think this here is a good baseline at least.

Comments and ideas highly welcome.

Thanks, Daniel

Daniel Vetter (10):
  drm: Move a few macros away from drm_crtc.h
  drm: Extract drm_bridge.h
  drm: Move all decl for drm_edid.c to drm_edid.h
  drm: Extract drm_plane.[hc]
  drm/doc: Polish for drm_plane.[hc]
  drm: Conslidate blending properties in drm_blend.[hc]
  drm/doc: Polish plane composition property docs
  drm: Extract drm_color_mgmt.[hc]
  drm/doc: Document color space handling
  drm: Remove dirty property from docs

 Documentation/gpu/drm-kms-helpers.rst |   10 +
 Documentation/gpu/drm-kms.rst |   78 +-
 Documentation/gpu/kms-properties.csv  |   21 -
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_blend.c   |  197 +++-
 drivers/gpu/drm/drm_bridge.c  |5 +-
 drivers/gpu/drm/drm_color_mgmt.c  |  296 ++
 drivers/gpu/drm/drm_crtc.c| 1618 +
 drivers/gpu/drm/drm_crtc_internal.h   |   45 +-
 drivers/gpu/drm/drm_framebuffer.c |   26 +
 drivers/gpu/drm/drm_plane.c   |  854 +
 include/drm/drm_atomic.h  |  154 
 include/drm/drm_blend.h   |   59 ++
 include/drm/drm_bridge.h  |  218 +
 include/drm/drm_color_mgmt.h  |   61 ++
 include/drm/drm_connector.h   |   28 +-
 include/drm/drm_crtc.h|  887 +-
 include/drm/drm_edid.h|   30 +
 include/drm/drm_encoder.h |   22 +
 include/drm/drm_framebuffer.h |   17 +
 include/drm/drm_mode_object.h |1 +
 include/drm/drm_modes.h   |6 +
 include/drm/drm_plane.h   |  523 +++
 include/drm/drm_property.h|1 +
 24 files changed, 2759 insertions(+), 2401 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_color_mgmt.c
 create mode 100644 drivers/gpu/drm/drm_plane.c
 create mode 100644 include/drm/drm_blend.h
 create mode 100644 include/drm/drm_bridge.h
 create mode 100644 include/drm/drm_color_mgmt.h
 create mode 100644 include/drm/drm_plane.h

-- 
2.9.3

[PATCH] drm/sun4i: Clear encoder->bridge if a bridge is not found

[Maxime Ripard]

On Tue, Aug 30, 2016 at 11:51:26PM +0800, Chen-Yu Tsai wrote:
> On Tue, Aug 30, 2016 at 8:56 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Tue, Aug 30, 2016 at 08:22:23PM +0800, Chen-Yu Tsai wrote:
> >> The KMS helpers (drm_atomic_helper_check_modeset/mode_fixup) pass
> >> encoder->bridge directly to drm_bridge_mode_fixup, which expects a
> >> valid pointer, or NULL (in which case it just returns).
> >>
> >> Clear encoder->bridge if a bridge is not found, instead of keeping
> >> the ERR_PTR value.
> >>
> >> Since other drm_bridge functions also follow this pattern of checking
> >> for a non-NULL pointer, we can drop the ifs around the calls and just
> >> pass the pointer directly.
> >>
> >> Fixes: 894f5a9f4b4a ("drm/sun4i: Add bridge support")
> >> Signed-off-by: Chen-Yu Tsai 
> >> ---
> >>  drivers/gpu/drm/sun4i/sun4i_rgb.c | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> >> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> >> index d4e52522ec53..ee0795152a33 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> >> @@ -154,8 +154,7 @@ static void sun4i_rgb_encoder_enable(struct 
> >> drm_encoder *encoder)
> >>   if (!IS_ERR(tcon->panel))
> >>   drm_panel_enable(tcon->panel);
> >>
> >> - if (!IS_ERR(encoder->bridge))
> >> - drm_bridge_enable(encoder->bridge);
> >> + drm_bridge_enable(encoder->bridge);
> >>
> >>   sun4i_tcon_channel_enable(tcon, 0);
> >>  }
> >> @@ -170,8 +169,7 @@ static void sun4i_rgb_encoder_disable(struct 
> >> drm_encoder *encoder)
> >>
> >>   sun4i_tcon_channel_disable(tcon, 0);
> >>
> >> - if (!IS_ERR(encoder->bridge))
> >> - drm_bridge_disable(encoder->bridge);
> >> + drm_bridge_disable(encoder->bridge);
> >
> > I'd rather keep those changes, it makes it obvious that it's something
> > optionnal, that can be set to NULL.
> 
> OK.
> 
> >>   if (!IS_ERR(tcon->panel))
> >>   drm_panel_disable(tcon->panel);
> >> @@ -230,6 +228,9 @@ int sun4i_rgb_init(struct drm_device *drm)
> >>   return 0;
> >>   }
> >>
> >> + if (IS_ERR(encoder->bridge))
> >> + encoder->bridge = NULL;
> >> +
> >
> > And that could be the else condition of the if statement below.
> 
> That would be a bit confusing, changing it after calling drm_encoder_init.
> The code says it ok to do though.

The magic really happens only after the encoder has been attached to
something, so it's really safe.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160831/6f45c0e7/attachment.sig>

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

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

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

--- Comment #5 from Luke A. Guest  ---
I can also confirm that the pagefaults above are back with this patch
reversion.

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

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

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

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

--- Comment #4 from Luke A. Guest  ---
(In reply to Shawn Starr from comment #3)
> Revert this patch to fix VDPAU corruption:
> 
> "radeonsi: increase performance for DRI PRIME offloading if 2nd GPU is CIK
> or VI"
> 5ee3cac1380fec6971e9d25267589a586da0ecd8.

I reverted this, rebuilt mesa, ran the ffmpeg command, played it back, the
first 4 seconds is corrupt in the same way as before, then it's fine.

Rebuilt obs-studio, the window now shows an uncorrupted screen! REbuilt ffmpeg
and no corruption.

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

[PATCH 4/6] ARM: sunxi: Support the Nextthing GR8

[Chen-Yu Tsai]

On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
 wrote:
> The GR8 is an SoC made by Nextthing Co, loosely based on the sun5i family.
>
> It has a number of new controllers compared to the A10s and A13 (SPDIF, I2S),
> but some controllers missing too (Ethernet, less I2C, less UARTs).
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
>  MAINTAINERS | 1 +
>  arch/arm/mach-sunxi/sunxi.c | 1 +

Please update Documentation/arm/sunxi/README as well. I don't suppose
there's a datasheet available?

ChenYu

>  3 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 7e79fcc36b0d..3975d0a0e4c2 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,3 +14,4 @@ using one of the following compatible strings:
>allwinner,sun8i-a83t
>allwinner,sun8i-h3
>allwinner,sun9i-a80
> +  nextthing,gr8
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d00098c..c6a9e6fda1d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -982,6 +982,7 @@ M:  Chen-Yu Tsai 
>  L: linux-arm-kernel at lists.infradead.org (moderated for 
> non-subscribers)
>  S: Maintained
>  N: sun[x456789]i
> +F: arch/arm/boot/dts/gr8*
>
>  ARM/Allwinner SoC Clock Support
>  M: Emilio López 
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 95dca8c2c9ed..2e2bde271205 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -22,6 +22,7 @@ static const char * const sunxi_board_dt_compat[] = {
> "allwinner,sun5i-a10s",
> "allwinner,sun5i-a13",
> "allwinner,sun5i-r8",
> +   "nextthing,gr8",
> NULL,
>  };
>
> --
> 2.9.2
>

[PATCH 2/3] drm/bridge: adv7533: Initialize regulators

[Archit Taneja]

ADV7533 requires supply to the AVDD, V1P2 and V3P3 pins for proper
functionality.

Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.

Cc: dri-devel at lists.freedesktop.org
Cc: Laurent Pinchart 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/bridge/adv7511/adv7511.h | 16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 34 +++--
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 45 
 3 files changed, 86 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..3fcb202 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -327,6 +328,10 @@ struct adv7511 {

struct gpio_desc *gpio_pd;

+   struct regulator *avdd;
+   struct regulator *v1p2;
+   struct regulator *v3p3;
+
/* ADV7533 DSI RX related params */
struct device_node *host_node;
struct mipi_dsi_device *dsi;
@@ -343,6 +348,8 @@ void adv7533_mode_set(struct adv7511 *adv, struct 
drm_display_mode *mode);
 int adv7533_patch_registers(struct adv7511 *adv);
 void adv7533_uninit_cec(struct adv7511 *adv);
 int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_init_regulators(struct adv7511 *adv);
+void adv7533_uninit_regulators(struct adv7511 *adv);
 int adv7533_attach_dsi(struct adv7511 *adv);
 void adv7533_detach_dsi(struct adv7511 *adv);
 int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,6 +381,15 @@ static inline int adv7533_init_cec(struct adv7511 *adv)
return -ENODEV;
 }

+static inline int adv7533_init_regulators(struct adv7511 *adv)
+{
+   return -ENODEV;
+}
+
+static inline void adv7533_uninit_regulators(struct adv7511 *adv)
+{
+}
+
 static inline int adv7533_attach_dsi(struct adv7511 *adv)
 {
return -ENODEV;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ec8fb2e..221bc75 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -941,6 +941,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (!adv7511)
return -ENOMEM;

+   adv7511->i2c_main = i2c;
adv7511->powered = false;
adv7511->status = connector_status_disconnected;

@@ -958,13 +959,21 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
return ret;

+   if (adv7511->type == ADV7533) {
+   ret = adv7533_init_regulators(adv7511);
+   if (ret)
+   return ret;
+   }
+
/*
 * The power down GPIO is optional. If present, toggle it from active to
 * inactive to wake up the encoder.
 */
adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
-   if (IS_ERR(adv7511->gpio_pd))
-   return PTR_ERR(adv7511->gpio_pd);
+   if (IS_ERR(adv7511->gpio_pd)) {
+   ret = PTR_ERR(adv7511->gpio_pd);
+   goto uninit_regulators;
+   }

if (adv7511->gpio_pd) {
mdelay(5);
@@ -972,12 +981,14 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
}

adv7511->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
-   if (IS_ERR(adv7511->regmap))
-   return PTR_ERR(adv7511->regmap);
+   if (IS_ERR(adv7511->regmap)) {
+   ret = PTR_ERR(adv7511->regmap);
+   goto uninit_regulators;
+   }

ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, );
if (ret)
-   return ret;
+   goto uninit_regulators;
dev_dbg(dev, "Rev. %d\n", val);

if (adv7511->type == ADV7511)
@@ -987,7 +998,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
else
ret = adv7533_patch_registers(adv7511);
if (ret)
-   return ret;
+   goto uninit_regulators;

regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
@@ -995,10 +1006,11 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
adv7511_packet_disable(adv7511, 0x);

-   adv7511->i2c_main = i2c;
adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
-   if (!adv7511->i2c_edid)
-   return -ENOMEM;
+   if (!adv7511->i2c_edid) {
+   ret = -ENOMEM;
+   goto uninit_regulators;
+   }

if (adv7511->type == ADV7533) {
 

[PATCH v3 8/8] ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node

[Jyri Sarha]

Add blue-and-red-wiring -property to lcdc node. The am335x-evmsk has
blue and red wires crossed to get 24-bit RGB (and 16-bit BGR)
support. After this patch am335x-evmsk supports BGR565, RGB888, and
XRGB color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evmsk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 23b94e7..034e117 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -712,4 +712,6 @@

  {
status = "okay";
+
+   blue-and-red-wiring = "crossed";
 };
-- 
1.9.1

[PATCH v3 7/8] ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes

[Jyri Sarha]

Whitespace cleanup of lcdc related nodes. Do all indentation and
alignment with tabs instead of spaces.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evmsk.dts | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 09308d6..23b94e7 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -170,29 +170,29 @@
pinctrl-1 = <_pins_sleep>;
status = "okay";
panel-info {
-   ac-bias   = <255>;
-   ac-bias-intrpt= <0>;
-   dma-burst-sz  = <16>;
-   bpp   = <32>;
-   fdd   = <0x80>;
-   sync-edge = <0>;
-   sync-ctrl = <1>;
-   raster-order  = <0>;
-   fifo-th   = <0>;
+   ac-bias = <255>;
+   ac-bias-intrpt  = <0>;
+   dma-burst-sz= <16>;
+   bpp = <32>;
+   fdd = <0x80>;
+   sync-edge   = <0>;
+   sync-ctrl   = <1>;
+   raster-order= <0>;
+   fifo-th = <0>;
};
display-timings {
480x272 {
-   hactive = <480>;
-   vactive = <272>;
-   hback-porch = <43>;
-   hfront-porch= <8>;
-   hsync-len   = <4>;
-   vback-porch = <12>;
-   vfront-porch= <4>;
-   vsync-len   = <10>;
+   hactive = <480>;
+   vactive = <272>;
+   hback-porch = <43>;
+   hfront-porch= <8>;
+   hsync-len   = <4>;
+   vback-porch = <12>;
+   vfront-porch= <4>;
+   vsync-len   = <10>;
clock-frequency = <900>;
-   hsync-active= <0>;
-   vsync-active= <0>;
+   hsync-active= <0>;
+   vsync-active= <0>;
};
};
};
@@ -711,5 +711,5 @@
 };

  {
-  status = "okay";
+   status = "okay";
 };
-- 
1.9.1

[PATCH v3 6/8] ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node

[Jyri Sarha]

Add blue-and-red-wiring -property to lcdc node. The am335x-evm has
blue and red wires crossed to get 24-bit RGB (and 16-bit BGR)
support. After this patch am335x-evm supports BGR565, RGB888, and
XRGB color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evm.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 5d28712..c3cbce0 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -497,6 +497,8 @@

  {
status = "okay";
+
+   blue-and-red-wiring = "crossed";
 };

  {
-- 
1.9.1

[PATCH v3 5/8] ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC node

[Jyri Sarha]

Add blue-and-red-wiring -property to LCDC node. Also adds comments on
how to get support 24 bit RGB mode. After this patch am335x-boneblack
support RGB565, BGR888, and XBGR color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.

The BBB has straight color wiring from am335x to tda19988, however the
tda19988 can be configured to cross the blue and red wires. The
comments show how to do that with video-ports property of tda19988
node and how to tell LCDC that blue and red wires are crossed, with
blue-and-red-wiring LCDC node property. This changes supported color
formats from 16 bit RGB and 24 bit BGR to 16 bit BGR and 24 bit RGB.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 528559b..8b87164 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -90,6 +90,14 @@

  {
status = "okay";
+
+   /* If you want to get 24 bit RGB and 16 BGR mode instead of
+* current 16 bit RGB and 24 BGR modes, set the propety
+* below to "crossed" and uncomment the video-ports -property
+*in tda19988 node.
+*/
+   blue-and-red-wiring = "straight";
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <_0>;
@@ -106,6 +114,9 @@
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;

+   /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
+   /* video-ports = <0x234501>; */
+
#sound-dai-cells = <0>;
audio-ports = < TDA998x_I2S 0x03>;

-- 
1.9.1

[PATCH v3 4/8] drm/tilcdc: Choose console BPP that supports RGB

[Jyri Sarha]

Choose console BPP that supports RGB and remove the old fbdev bpp
selection code. LCDC on AM335x has red and blue wires switched between
24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16
bit format is wired for BGR. drm_fbdev_cma_init() does not currently
like anything else but RGB formats, so we must choose such bytes per
pixel value that supports RGB.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 14 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  7 +++
 drivers/gpu/drm/tilcdc/tilcdc_external.h |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  2 --
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  2 --
 6 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 4371537..9a55ea2 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -240,7 +240,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
-   struct tilcdc_module *mod;
struct resource *res;
u32 bpp = 0;
int ret;
@@ -336,6 +335,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
DBG("Revision 1 LCDC supports only RGB565 format");
priv->pixelformats = tilcdc_rev1_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+   bpp = 16;
} else {
const char *str = "\0";

@@ -345,18 +345,21 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
priv->pixelformats = tilcdc_crossed_formats;
priv->num_pixelformats =
ARRAY_SIZE(tilcdc_crossed_formats);
+   bpp = 32; /* Choose bpp with RGB support for fbdef */
} else if(0 == strcmp(str, "default") ||
  0 == strcmp(str, "straight")) {
DBG("Configured for straight blue and red wires");
priv->pixelformats = tilcdc_straight_formats;
priv->num_pixelformats =
ARRAY_SIZE(tilcdc_straight_formats);
+   bpp = 16; /* Choose bpp with RGB support for fbdef */
} else {
DBG("Blue and red wiring '%s' unknown, use legacy mode",
str);
priv->pixelformats = tilcdc_legacy_formats;
priv->num_pixelformats =
ARRAY_SIZE(tilcdc_legacy_formats);
+   bpp = 16; /* This is just a guess */
}
}

@@ -373,7 +376,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
if (ret < 0)
goto fail_mode_config_cleanup;

-   ret = tilcdc_add_external_encoders(dev, );
+   ret = tilcdc_add_external_encoders(dev);
if (ret < 0)
goto fail_component_cleanup;
}
@@ -396,13 +399,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
goto fail_vblank_cleanup;
}

-   list_for_each_entry(mod, _list, list) {
-   DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
-   bpp = mod->preferred_bpp;
-   if (bpp > 0)
-   break;
-   }
-
drm_mode_config_reset(dev);

priv->fbdev = drm_fbdev_cma_init(dev, bpp,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0e19c14..a6e5e6d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
-   unsigned int preferred_bpp;
 };

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 849b23e..68e8950 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -52,7 +52,7 @@ static int tilcdc_external_mode_valid(struct drm_connector 
*connector,
return MODE_OK;
 }

-static int tilcdc_add_external_encoder(struct drm_device *dev, int *bpp,
+static int tilcdc_add_external_encoder(struct drm_device *dev,
   struct drm_connector *connector)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -64,7 +64,6 @@ static int tilcdc_add_external_encoder(struct drm_device 
*dev, int *bpp,
/* Only tda998x is supported at the moment. */
  

[PATCH v3 3/8] drm/tilcdc: Add blue-and-red-crossed devicetree property

[Jyri Sarha]

Add "blue-and-red-wiring"-device tree property and update devicetree
binding document. The red and blue components are reversed between 24
and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the
red and blue wires has to be crossed and this in turn causes 16 colors
output to be in BGR format. With straight wiring the 16 color is RGB
and 24 bit is BGR. The new property describes whether the red and blue
wires are crossed or not. If the property is not present or its value
is not recognized the legacy mode is assumed. The legacy configuration
supports RGB565, RGB888 and XRGB formats. However, depending on
wiring, the red and blue colors are swapped in either 16 or 24-bit
color modes.

For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/tilcdc/tilcdc.txt  | 22 
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 42 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  4 +++
 drivers/gpu/drm/tilcdc/tilcdc_plane.c  |  9 ++---
 4 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 6efa4c5..5b7b5f8 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -17,6 +17,18 @@ Optional properties:
the lcd controller.
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+ - blue-and-red-wiring: Recognized values "default", "straight" or
+   "crossed". This property deals with the LCDC revision 2 (found on
+   AM335x) color errata [1].
+ - "default" and "straight" indicates normal wiring that supports
+  RGB565, BGR888, and XBGR color formats.
+- "crossed" indicates wiring that has blue and red wires
+  crossed. This setup supports BGR565, RGB888 and XRGB
+  formats.
+- If the property is not present or its value is not recognized
+  the legacy mode is assumed. This configuration supports RGB565,
+  RGB888 and XRGB formats. However, depending on wiring, the red
+  and blue colors are swapped in either 16 or 24-bit color modes.

 Optional nodes:

@@ -28,6 +40,14 @@ Optional nodes:
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
tfp410 DVI encoder or lcd panel to lcdc

+[1] There is an errata about AM335x color wiring. For 16-bit color mode
+the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]),
+but for 24 bit color modes the wiring of blue and red components is
+crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
+for Blue[3-7]. For more details see section 3.1.1 in AM335x
+Silicon Errata:
+
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
+
 Example:

fb: fb at 4830e000 {
@@ -37,6 +57,8 @@ Example:
interrupts = <36>;
ti,hwmods = "lcdc";

+   blue-and-red-wiring = "crossed";
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <_0>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index e45c268..4371537 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -33,6 +33,20 @@

 static LIST_HEAD(module_list);

+static const u32 tilcdc_rev1_formats[] = { DRM_FORMAT_RGB565 };
+
+static const u32 tilcdc_straight_formats[] = { DRM_FORMAT_RGB565,
+  DRM_FORMAT_BGR888,
+  DRM_FORMAT_XBGR };
+
+static const u32 tilcdc_crossed_formats[] = { DRM_FORMAT_BGR565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_XRGB };
+
+static const u32 tilcdc_legacy_formats[] = { DRM_FORMAT_RGB565,
+DRM_FORMAT_RGB888,
+DRM_FORMAT_XRGB };
+
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
 {
@@ -318,6 +332,34 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

pm_runtime_put_sync(dev->dev);

+   if (priv->rev == 1) {
+   DBG("Revision 1 LCDC supports only RGB565 format");
+   priv->pixelformats = tilcdc_rev1_formats;
+   priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+   } else {
+   const char *str = "\0";
+
+   of_property_read_string(node, "blue-and-red-wiring", );
+   if (0 == strcmp(str, "crossed")) {
+   DBG("Configured for crossed 

[PATCH v3 2/8] drm/tilcdc: Write DMA base and ceiling address with single instruction

[Jyri Sarha]

Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  9 +++--
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 14 ++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6350f2a..41ec5b3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -70,6 +70,7 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
struct drm_gem_cma_object *gem;
unsigned int depth, bpp;
dma_addr_t start, end;
+   u64 dma_base_and_ceiling;

drm_fb_get_bpp_depth(fb->pixel_format, , );
gem = drm_fb_cma_get_gem_obj(fb, 0);
@@ -80,8 +81,12 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)

end = start + (crtc->mode.vdisplay * fb->pitches[0]);

-   tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, start);
-   tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, end - 1);
+   /* Write DMA base and ceiling address with a single insruction,
+* if available. This should make it more unlikely that LCDC would
+* fetch the DMA addresses in the middle of an update.
+*/
+   dma_base_and_ceiling = (u64)(end - 1) << 32 | start;
+   tilcdc_write64(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_base_and_ceiling);

if (tilcdc_crtc->curr_fb)
drm_flip_work_queue(_crtc->unref_work,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 1bf5e25..61a9c2a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -119,6 +119,20 @@ static inline void tilcdc_write(struct drm_device *dev, 
u32 reg, u32 data)
iowrite32(data, priv->mmio + reg);
 }

+static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)
+{
+   struct tilcdc_drm_private *priv = dev->dev_private;
+   volatile void __iomem *addr = priv->mmio + reg;
+
+#ifdef iowrite64
+   iowrite64(data, addr);
+#else
+   /* This compiles to strd (=64-bit write) on ARM7 */
+   __iowmb();
+   *(volatile u64 __force *)addr = __cpu_to_le64(data);
+#endif
+}
+
 static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-- 
1.9.1

[PATCH v3 1/8] drm/tilcdc: Remove drm_helper_disable_unused_functions() call

[Jyri Sarha]

drm_helper_disable_unused_functions() should not be called by atomic
drivers.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3404d24..e45c268 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -361,8 +361,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
break;
}

-   drm_helper_disable_unused_functions(dev);
-
drm_mode_config_reset(dev);

priv->fbdev = drm_fbdev_cma_init(dev, bpp,
-- 
1.9.1

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

[Jyri Sarha]

Changes since v2:
- Fiddle with color wiring propety once more, now it follows this Tomi's
  comment:
  - No property set: driver advertises RG16 and RG24. This is
wrong, but that's what the current status is, right?
  - Property set to "default" or "straight" or whatever: driver
says RG16 and BG24
  - Property set to "crossed": driver says BG16 and RG24
- Add v2 version of "drm/tilcdc: Write DMA base and ceiling address with..."
  - The first version was sent individually, this second version has
__iowmb(); and __cpu_to_le64(); added to tilcdc_write64()

Changes since v1:
- Change the blue-and-red-wiring property to boolean blue-and-red-crossed
  - This breaks to little backward compatibility the earlier series had, but
makes the binding more straight forward
  - This changes requires changes to am335x-evm and am335x-evmsk dts-files
  - The old beaglebone-black dts files remain compatible, but the patch
suggests in commenst on how to support 24-bit RGB mode with BBB

The first patch ("drm/tilcdc: Remove drm_helper_disable_unused_functions()
call") is completely independent fix.

The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the wires red and
blue wires has to be crossed and this in turn causes 16 colors output
to be in BGR format. With straight wiring the 16 color is RGB and 24
bit is BGR. These patches try to deal with the issue in reasonable
manner.

For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360

Jyri Sarha (8):
  drm/tilcdc: Remove drm_helper_disable_unused_functions() call
  drm/tilcdc: Write DMA base and ceiling address with single instruction
  drm/tilcdc: Add blue-and-red-crossed devicetree property
  drm/tilcdc: Choose console BPP that supports RGB
  ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC
node
  ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node
  ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
  ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node

 .../devicetree/bindings/display/tilcdc/tilcdc.txt  | 22 
 arch/arm/boot/dts/am335x-boneblack.dts | 11 
 arch/arm/boot/dts/am335x-evm.dts   |  2 +
 arch/arm/boot/dts/am335x-evmsk.dts | 42 
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  9 +++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 58 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  5 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   |  7 ++-
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  |  2 -
 drivers/gpu/drm/tilcdc/tilcdc_plane.c  |  9 ++--
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 14 ++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  2 -
 13 files changed, 136 insertions(+), 49 deletions(-)

-- 
1.9.1

[pull] drm/msm: fixes for 4.8

[Rob Clark]

The following changes since commit 969af80f770a86e65bf8be1f72b218b5f8556b56:

  Merge tag 'drm-intel-fixes-2016-08-25' of
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-08-26
05:18:40 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.8

for you to fetch changes up to d78d383ab354b0b9e1d23404ae0d9fbdeb9aa035:

  drm/msm: protect against faults from copy_from_user() in submit
ioctl (2016-08-28 12:49:39 -0400)


Rob Clark (2):
  drm/msm: fix use of copy_from_user() while holding spinlock
  drm/msm: protect against faults from copy_from_user() in submit ioctl

 drivers/gpu/drm/msm/msm_drv.h|  6 ++
 drivers/gpu/drm/msm/msm_gem.c|  9 +
 drivers/gpu/drm/msm/msm_gem_submit.c | 30 +-
 3 files changed, 40 insertions(+), 5 deletions(-)

[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

[James Bottomley]

On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote:
> Hi
> 
> Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> > > 
> > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > > > 
> > > > We seem to have an xrandr regression with skylake now.  What's
> > > > happening is that I can get output on to a projector, but the 
> > > > system is losing video when I change the xrandr sessions (like 
> > > > going from a --above b to a --same-as b).  The main screen goes
> > > > blank, which is basically a reboot situation.  Unfortunately, I
> > > > can't seem to get the logs out of systemd to see if there was a
> > > > dump to dmesg (the system was definitely responding).
> > > > 
> > > > I fell back to 4.6.2 which worked perfectly, so this is
> > > > definitely 
> > > > some sort of regression.  I'll be able to debug more fully when
> > > > I 
> > > > get back home from the Linux Security Summit.
> > > 
> > > I'm home now.  Unfortunately, my monitor isn't as problematic as
> > > the
> > > projector, but by flipping between various modes and separating
> > > and
> > > overlaying the panels with --above and --same-as (xrandr), I can
> > > eventually get it to the point where the main LCD panel goes
> > > black 
> > > and can only be restarted by specifying a different mode.
> > > 
> > > This seems to be associated with these lines in the X
> > > 
> > > [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument
> > > [22]
> > > 
> > > But the curious thing is that even if this fails with the error 
> > > message once, it may succeed a second time, so it looks to be a 
> > > transient error translation problem from the kernel driver.
> > > 
> > > I've attached the full log below.
> > > 
> > > This is only with a VGA output.  I currently don't have a HDMI 
> > > dongle, but I'm in the process of acquiring one.
> > 
> > After more playing around, I'm getting thousands of these in the
> > kernel
> > log (possibly millions: the log wraps very fast):
> > 
> > [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR*
> > failed
> > to train DP, aborting
> > 
> > And then finally it gives up with 
> > 
> > [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> > *ERROR* CPU pipe B FIFO underrun
> > [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> > *ERROR* CPU pipe A FIFO underrun
> > 
> > And the crtc for the VGA output becomes non-responsive to any
> > configuration command.  This requires a reboot and sometimes a UEFI
> > variable reset before it comes back.
> 
> Please see this discussion:
> https://patchwork.freedesktop.org/patch/103237/
> 
> Do you have this patch on your tree? Does the problem go away if you
> revert it?

Yes, I've got it, it went in in 4.8-rc3 according to git:

commit 58e311b09c319183254d9220c50a533e7157c9ab
Author: Matt Roper 
Date:   Thu Aug 4 14:08:00 2016 -0700

drm/i915/gen9: Give one extra block per line for SKL plane WM
calculations

Reverting it causes the secondary display not to sync pretty much at
all.  However, in the flickers I can see, it does work OK and doesn't
now crash switching from --same-as to --above and back

I also still get the logs filling up with the link training errors.

On balance, although the behaviour is different, it's not an
improvement because if I can't sync with the projector, I can't really
use this as a fix.

James

[PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Milo Kim]

Hi Krzysztof,

On 08/25/2016 04:05 AM, Krzysztof Kozlowski wrote:
> First of all - it looks like these DTS patches do not depend on DRM
> part, do they?

I just sent the v4 patch for DTS. DRM patch-set was sent separately. 
Thanks for your advise.

Best regards,
Milo

[PATCH v4 3/3] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer

[Milo Kim]

The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
so this code can be ignored.

Reviewed-by: Andrzej Hajda 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 42b0b98..e8fb6ef 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
if (ret)
return ret;

-   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+   for (i = 0; i < ARRAY_SIZE(supply); ++i)
hdata->regul_bulk[i].supply = supply[i];
-   hdata->regul_bulk[i].consumer = NULL;
-   }
+
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), 
hdata->regul_bulk);
if (ret) {
if (ret != -EPROBE_DEFER)
-- 
2.9.3

[PATCH v4 2/3] gpu: drm: exynos_hdmi: Move PHY logic into single function

[Milo Kim]

Paring DT properties and getting PHY IO (memory mapped or I2C) in one
function.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 63 +++-
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 1440dfd..42b0b98 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1790,16 +1790,44 @@ static int hdmi_get_ddc_adapter(struct hdmi_context 
*hdata)
return 0;
 }

-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static int hdmi_get_phy_io(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+   struct device_node *np;
+   int ret = 0;
+
+   np = of_find_compatible_node(NULL, NULL, compatible_str);
+   if (!np) {
+   np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
+   if (!np) {
+   DRM_ERROR("Failed to find hdmiphy node in device 
tree\n");
+   return -ENODEV;
+   }
+   }
+
+   if (hdata->drv_data->is_apb_phy) {
+   hdata->regs_hdmiphy = of_iomap(np, 0);
+   if (!hdata->regs_hdmiphy) {
+   DRM_ERROR("failed to ioremap hdmi phy\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+   } else {
+   hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
+   if (!hdata->hdmiphy_port) {
+   DRM_INFO("Failed to get hdmi phy i2c client\n");
+   ret = -EPROBE_DEFER;
+   goto out;
+   }
+   }

-   return of_find_compatible_node(NULL, NULL, compatible_str);
+out:
+   of_node_put(np);
+   return ret;
 }

 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *phy_node;
struct device *dev = >dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1833,34 +1861,9 @@ static int hdmi_probe(struct platform_device *pdev)
if (ret)
return ret;

-   phy_node = hdmi_legacy_phy_dt_binding(dev);
-   if (phy_node)
-   goto out_get_phy_port;
-
-   phy_node = of_parse_phandle(dev->of_node, "phy", 0);
-   if (!phy_node) {
-   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
-   ret = -ENODEV;
+   ret = hdmi_get_phy_io(hdata);
+   if (ret)
goto err_ddc;
-   }
-   of_node_put(dev->of_node);
-
-out_get_phy_port:
-   if (hdata->drv_data->is_apb_phy) {
-   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
-   if (!hdata->regs_hdmiphy) {
-   DRM_ERROR("failed to ioremap hdmi phy\n");
-   ret = -ENOMEM;
-   goto err_ddc;
-   }
-   } else {
-   hdata->hdmiphy_port = of_find_i2c_device_by_node(phy_node);
-   if (!hdata->hdmiphy_port) {
-   DRM_ERROR("Failed to get hdmi phy i2c client\n");
-   ret = -EPROBE_DEFER;
-   goto err_ddc;
-   }
-   }

INIT_DELAYED_WORK(>hotplug_work, hdmi_hotplug_work_func);

-- 
2.9.3

[PATCH v4 1/3] gpu: drm: exynos_hdmi: Move DDC logic into single function

[Milo Kim]

Paring DT properties and getting the I2C adapter in one function.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 46 
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..1440dfd 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
 };

-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
+   struct i2c_adapter *adpt;

np = of_find_compatible_node(NULL, NULL, compatible_str);
if (np)
-   return of_get_next_parent(np);
+   np = of_get_next_parent(np);
+   else
+   np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
+
+   if (!np) {
+   DRM_ERROR("Failed to find ddc node in device tree\n");
+   return -ENODEV;
+   }
+
+   adpt = of_find_i2c_adapter_by_node(np);
+   of_node_put(np);

-   return NULL;
+   if (!adpt) {
+   DRM_INFO("Failed to get ddc i2c adapter by node\n");
+   return -EPROBE_DEFER;
+   }
+
+   hdata->ddc_adpt = adpt;
+
+   return 0;
 }

 static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1781,7 +1799,7 @@ static struct device_node 
*hdmi_legacy_phy_dt_binding(struct device *dev)

 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *ddc_node, *phy_node;
+   struct device_node *phy_node;
struct device *dev = >dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}

-   ddc_node = hdmi_legacy_ddc_dt_binding(dev);
-   if (ddc_node)
-   goto out_get_ddc_adpt;
-
-   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
-   if (!ddc_node) {
-   DRM_ERROR("Failed to find ddc node in device tree\n");
-   return -ENODEV;
-   }
-   of_node_put(dev->of_node);
-
-out_get_ddc_adpt:
-   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdata->ddc_adpt) {
-   DRM_ERROR("Failed to get ddc i2c adapter by node\n");
-   return -EPROBE_DEFER;
-   }
+   ret = hdmi_get_ddc_adapter(hdata);
+   if (ret)
+   return ret;

phy_node = hdmi_legacy_phy_dt_binding(dev);
if (phy_node)
-- 
2.9.3

[PATCH v4 0/3] gpu: drm: exynos_hdmi: Code refactoring on hdmi ddc and phy

[Milo Kim]

v4:
  Only DRM patchset is sent, DTS patch was sent separately.

Milo Kim (3):
  gpu: drm: exynos_hdmi: Move DDC logic into single function
  gpu: drm: exynos_hdmi: Move PHY logic into single function
  gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator
bulk consumer

 drivers/gpu/drm/exynos/exynos_hdmi.c | 112 ++-
 1 file changed, 59 insertions(+), 53 deletions(-)

-- 
2.9.3

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

>>
>> Thanks. Right now I am overriding the DSDT, but I am not able to override
>> the SSDT, because I have to fix and compile all the SSDT files. There
>> are too many compile errors... Wanted to find the exact line which
>> is responsible for the hickup.
> 
> Have you disassembled with externs included? That is,
> 
> iasl -e *.dat -d ssdtX.dat
> 
> If you are sure that the remaining errors are harmless, you can use the
> '-f' option to ignore errors. You can also use the `-ve` option to
> suppress warnings and remarks so you can focus on the errors.
> 

Thanks, I'll try that.


> If you look at my notes.txt, you will see that _OFF always executes the
> same code. PGON differs. When the problem occurs, "Q0L0" somehow always
> reads back as non-zero and LNKS < 7.
> 

Oh you're Lekensteyn ^^

I don't have LNKS and no while loop after calling LKEN ?!


>>
>> I noticed following:
>>
>> 1. Blacklist nouveau
>> 2. Boot to GDM login manager (Wayland)
>> 3. Switch to TTY with CTRL+ALT+FN2
>> 4. Load bbswitch
>> 5. Switch off GPU
>> 6. run lspci -> no freeze
>> 7. Switch to GDM
>> 8. Login to a Wayland session (X11 won't work)
>> 9. run lspci in a GUI terminal -> system freezes
> 
> Is nouveau somehow loaded anyway? All those extra components (X11,
> Wayland, etc.) are unnecessary to reproduce the core problem. It occurs
> whenever the device is being resumed (either via DSM/_PS0 or via power
> resource PG00._ON).
> 

Sorry that was nonsense. The steps to reproduce the problem are still valid.
I didn't wait enough to power it down...

But whats interesting:

1. Blacklist nouveau
2. Load bbswitch
3. Power off GPU with bbswitch
4. Power on GPU with bbswitch
5. Run lspci
6. Power off GPU with bbswitch
7. Run lspci -> freeze

So setting the GPU power state with bbswitch works as expected.
Powering it on is also fine. I did this a couple of times.
But powering it off and letting lspci powering it on, ends in a race.

It might be, that lspci does not only power the GPU on, but triggers
another pci action which causes the race condition.
Does this have something to do with your quote about the retrain bit?

[PATCH 0/3] drm/tilcdc: Some fixes for LCDC rev1

[Kevin Hilman]

Hi Jyri,

Jyri Sarha  writes:

> On 08/23/16 15:56, Karl Beldan wrote:
>> Hi,
>> 
>> I found some missing bits for rev1 of the LCDC and here are some of the
>> changes I am using to use the DRM driver on an LCDCK (which has a rev1).
>> 1/3 seems required by rev1 of the IP and without it my the LCDC on my
>> LCDK keeps can't sync, 2/3 is required by the driver logic, while 3/3
>> is less of a requirement.
>
> I'll drop 3/3, because my recent patches should take care of that:
> http://www.spinics.net/lists/devicetree/msg138885.html
>
> However, there will be v2 round of those patches. Only the DT binding
> and its default value should change.
>
>> Although 1,2/3 would have fitted drm-fixes I based them on drm-next as
>> 2/3 would conflict with the recent changes in drm-next.
>> 
>
> I'll pick these two up for my next pull request. Thanks!
>

Can you share a branch which has your current series and these fixes
included, so we can use that as a baseline for further development?

Thanks,

Kevin

[RFC v4 3/3] drm/fence: add out-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

Support DRM out-fences creating a sync_file with a fence for each crtc
update with the DRM_MODE_ATOMIC_OUT_FENCE flag.

We then send an struct drm_out_fences array with the out-fences fds back in
the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.

struct drm_out_fences {
__u32   crtc_id;
__u32   fd;
};

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic.c | 214 ++-
 include/drm/drm_crtc.h   |  10 ++
 include/uapi/drm/drm_mode.h  |  15 ++-
 3 files changed, 217 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9e6c4e7..8732c3d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1483,11 +1483,9 @@ EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
  */

 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv,
-   struct fence *fence, uint64_t user_data)
+   struct drm_device *dev, uint64_t user_data)
 {
struct drm_pending_vblank_event *e = NULL;
-   int ret;

e = kzalloc(sizeof *e, GFP_KERNEL);
if (!e)
@@ -1497,17 +1495,6 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
e->event.base.length = sizeof(e->event);
e->event.user_data = user_data;

-   if (file_priv) {
-   ret = drm_event_reserve_init(dev, file_priv, >base,
->event.base);
-   if (ret) {
-   kfree(e);
-   return NULL;
-   }
-   }
-
-   e->base.fence = fence;
-
return e;
 }

@@ -1612,6 +1599,147 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_clean_old_fb);

+static struct drm_out_fence_state *get_out_fence(struct drm_device *dev,
+struct drm_atomic_state *state,
+uint32_t __user 
*out_fences_ptr,
+uint64_t count_out_fences,
+uint64_t user_data)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_out_fences *out_fences;
+   struct drm_out_fence_state *fence_state;
+   int i, ret;
+
+   if (count_out_fences > dev->mode_config.num_crtc)
+   return ERR_PTR(-EINVAL);
+
+   out_fences = kcalloc(count_out_fences, sizeof(*out_fences),
+GFP_KERNEL);
+   if (!out_fences)
+   return ERR_PTR(-ENOMEM);
+
+   if (copy_from_user(out_fences, out_fences_ptr,
+  count_out_fences * sizeof(*out_fences))) {
+   kfree(out_fences);
+   return ERR_PTR(-EFAULT);
+   }
+
+   fence_state = kcalloc(count_out_fences, sizeof(*fence_state),
+GFP_KERNEL);
+   if (!fence_state) {
+   kfree(out_fences);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   for (i = 0 ; i < count_out_fences ; i++)
+   fence_state[i].fd = -1;
+
+   for (i = 0 ; i < count_out_fences ; i++) {
+   struct fence *fence;
+
+   if (out_fences[i].fd != -1) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   crtc = drm_crtc_find(dev, out_fences[i].crtc_id);
+   if (!crtc) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto out;
+   }
+
+   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+   if (!fence) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   fence_init(fence, _crtc_fence_ops, >fence_lock,
+  crtc->fence_context, ++crtc->fence_seqno);
+
+   fence_state[i].fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fence_state[i].fd < 0) {
+   fence_put(fence);
+   ret = fence_state[i].fd;
+   goto out;
+   }
+
+   fence_state[i].sync_file = sync_file_create(fence);
+   if(!fence_state[i].sync_file) {
+   

[RFC v4 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_crtc.c | 31 +++
 include/drm/drm_crtc.h | 19 +++
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6eaeb73..28e49a5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -141,6 +141,32 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
}
 }

+static const char *drm_crtc_fence_get_driver_name(struct fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct fence *fence)
+{
+   return true;
+}
+
+const struct fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -194,6 +220,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}

+   crtc->fence_context = fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"drm_crtc-%d", crtc->base.id);
+
crtc->base.properties = >properties;

list_add_tail(>head, >crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2dc7e79..e92fcb2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -542,6 +544,9 @@ struct drm_crtc_funcs {
  * @gamma_store: gamma ramp values
  * @helper_private: mid-layer private data
  * @properties: property tracking for this CRTC
+ * @fence_context: context for fence signalling
+ * @fence_lock: fence lock for the fence context
+ * @fence_seqno: seqno variable to create fences
  *
  * Each CRTC may have one or more connectors associated with it.  This 
structure
  * allows the CRTC to be controlled.
@@ -634,8 +639,22 @@ struct drm_crtc {
 * context.
 */
struct drm_modeset_acquire_ctx *acquire_ctx;
+
+   /* fence timelines info for DRM out-fences */
+   unsigned int fence_context;
+   spinlock_t fence_lock;
+   unsigned long fence_seqno;
+   char timeline_name[32];
 };

+extern const struct fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
 /**
  * struct drm_plane_state - mutable plane state
  * @plane: backpointer to the plane
-- 
2.5.5

[RFC v4 1/3] drm/fence: add in-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

There is now a new property called FENCE_FD attached to every plane
state that receives the sync_file fd from userspace via the atomic commit
IOCTL.

The fd is then translated to a fence (that may be a fence_collection
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.

v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.

v3: WARN_ON if fence is set but state has no FB

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_atomic.c| 19 +++
 drivers/gpu/drm/drm_atomic_helper.c |  3 +++
 drivers/gpu/drm/drm_crtc.c  |  7 +++
 include/drm/drm_crtc.h  |  4 
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c02be6a..07f9c60 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5cb2e22..9e6c4e7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drm_crtc_internal.h"

@@ -690,6 +691,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+   } else if (property == config->prop_fence_fd) {
+   if (U642I64(val) == -1)
+   return 0;
+
+   if (state->fence)
+   fence_put(state->fence);
+
+   state->fence = sync_file_get_fence(val);
+   if (!state->fence)
+   return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -749,6 +761,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,

if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+   } else if (property == config->prop_fence_fd) {
+   *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
@@ -824,6 +838,11 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
return -EINVAL;
}

+   if (WARN_ON(state->fence && !state->fb)) {
+   DRM_DEBUG_ATOMIC("in-fence set but no FB\n");
+   return -EINVAL;
+   }
+
/* if disabled, we don't care about the rest of the state: */
if (!state->crtc)
return 0;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index dff2389..f817452 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3156,6 +3156,9 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 {
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+   if (state->fence)
+   fence_put(state->fence);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b95c48ac..6eaeb73 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -338,6 +338,7 @@ int drm_universal_plane_init(struct drm_device *dev, struct 
drm_plane *plane,

if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, config->prop_fb_id, 0);
+   drm_object_attach_property(>base, config->prop_fence_fd, 
-1);
drm_object_attach_property(>base, config->prop_crtc_id, 
0);
drm_object_attach_property(>base, config->prop_crtc_x, 
0);
drm_object_attach_property(>base, config->prop_crtc_y, 
0);
@@ -610,6 +611,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;

+   prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+   "FENCE_FD", -1, INT_MAX);
+   

[RFC v4 0/3] drm: add fences support through Sync Files

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

Currently the Linux Kernel only have an implicit fencing mechanism where the
fence are attached directly to buffers and userspace is unaware of the inner
kernel workings. However by enabling explicit fencing, where fences travels
all the way up the userspace we can provide insightful information to
compositors so smarter decisions when scheduling framebuffers.

For that we adapted the Android Sync Framework[1], a explicit fencing mechanism
that helps the userspace handles fences directly. It has the concept of
sync_file (called sync_fence in Android) that expose the driver's fences to
userspace via file descriptors, than can then be shared between process.

With explicit fencing we have a global mechanism that optimizes the flow of
buffers between consumers and producers, avoid a lot of waiting. So instead
of waiting for a buffer to be processed by the GPU before sending it to DRM/KMS
in an Atomic IOCTL we can get a sync_file fd from the GPU driver at the moment
we submit the buffer processing. The compositor then passes these fds to 
DRM/KMS 
in a Atomic Commit request, that will not be displayed until the fences signal,
i.e, the GPU finished processing the buffer and it is ready to be displayed.

In DRM/KMS the fences we wait on before displaying a buffer are called
*in-fences*.  Vice-versa, we have *out-fences*, to sychronize the return of
buffers to GPU (producer) to be processed again. When DRM/KMS receives an
atomic request with a special flag set it generates one fence per-crtc and
attach it to a per-crtc sync_file.  It then returns the array of sync_file fds
to userspace as an atomic_ioctl out arg. With the fences available userspace
can forward these fences to the GPU, where it will wait the fence to signal
before starting to process on the shared buffer again.

Explicit fencing with the Sync Framework provides better traceability and 
debuggabilty of the kernel and allows efficient buffer suballocation by
Mesa/Vulkan.

DRM/KMS explicit fences are opt-in, as the default will still be implicit
fencing.  To enable explicit in-fences one just need to pass a sync_file fd in
the FENCE_FD plane property. *In-fences are per-plane*, i.e., per framebuffer.

For out-fences, just enabling DRM_MODE_ATOMIC_OUT_FENCE flag is enough.
*Out-fences are per-crtc*.

In-fences
-

In the first discussions on #dri-devel on IRC we decided to hide the Sync
Framework from DRM drivers to reduce complexity, so as soon we get the fd
via FENCE_FD plane property we convert the sync_file fd to a struct fence.

Then we just use the already in place fence support to wait on those fences.
Once the producer calls fence_signal() for all fences on wait we can proceed
with the atomic commit and scanout the framebuffers.

Out-fences
--

Passing the DRM_MODE_ATOMIC_OUT_FENCE flag to an atomic request enables
out-fences. The kernel then creates a fence, attach it to a sync_file and
install this file on a unused fd. The process is repeated for each crtc.
Userspace get the fence back as an array of per-crtc sync_file fds.

DRM core use the already in place drm_event infrastructure to help signal
fences, we've added a fence pointer to struct drm_pending_event. On vblank we
just call fence_signal() to signal that the buffer related to this fence is
*now* on the screen. Note that this is exactly the opposite behaviour from
Android, where the fences are signaled when they are not on display anymore, so
free to be reused.

No changes are required to DRM drivers to have out-fences support, apart from
atomic support of course.

Kernel tree
---

For those who want all patches on this RFC are in my tree. The tree includes a
few other patches necessary to run it, like the interruptible wait_for_fences
patch that I sent last week to the mainling list:

https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=fences


Testing
---

For testing it Rob Clark add fences support to mesa and kmscube, Rob has
patch for the Mesa core native fence work and freedeno and I have added 
support of virgl as well:

git://github.com/freedreno/libdrm.git fences

git://git.collabora.com/git/user/padovan/mesa.git fences

git://github.com/robclark/kmscube.git atomic-fence


Changes in RFC v4
-

Rebased against latest drm-misc

Regards,

Gustavo
---

[1] https://source.android.com/devices/graphics/implement.html#vsync


Gustavo Padovan (3):
  drm/fence: add in-fences support
  drm/fence: add fence timeline to drm_crtc
  drm/fence: add out-fences support

 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c| 233 
 drivers/gpu/drm/drm_atomic_helper.c |   3 +
 drivers/gpu/drm/drm_crtc.c  |  38 ++
 include/drm/drm_crtc.h  |  33 +
 include/uapi/drm/drm_mode.h |  15 ++-
 6 files changed, 301 insertions(+), 22 deletions(-)

-- 
2.5.5

[PATCH 6/6] media: s5p-jpeg: fix system and runtime pm integration

[Marek Szyprowski]

Use generic helpers instead of open-coding usage of runtime pm for system
sleep pm, which was potentially broken for some corner cases.

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 785e6936c881..739ee49b9790 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2996,27 +2996,11 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */

-#ifdef CONFIG_PM_SLEEP
-static int s5p_jpeg_suspend(struct device *dev)
-{
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return s5p_jpeg_runtime_suspend(dev);
-}
-
-static int s5p_jpeg_resume(struct device *dev)
-{
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return s5p_jpeg_runtime_resume(dev);
-}
-#endif
-
 static const struct dev_pm_ops s5p_jpeg_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(s5p_jpeg_suspend, s5p_jpeg_resume)
-   SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume, 
NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
+   SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume,
+  NULL)
 };

 static struct s5p_jpeg_variant s5p_jpeg_drvdata = {
-- 
1.9.1

[PATCH 5/6] media: s5p-cec: fix system and runtime pm integration

[Marek Szyprowski]

Use generic helpers instead of open-coding usage of runtime pm for system
sleep pm, which was potentially broken for some corner cases.

Signed-off-by: Marek Szyprowski 
---
 drivers/staging/media/s5p-cec/s5p_cec.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c 
b/drivers/staging/media/s5p-cec/s5p_cec.c
index 78333273c4e5..77d9887801b8 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/staging/media/s5p-cec/s5p_cec.c
@@ -250,22 +250,9 @@ static int s5p_cec_runtime_resume(struct device *dev)
return 0;
 }

-static int __maybe_unused s5p_cec_suspend(struct device *dev)
-{
-   if (pm_runtime_suspended(dev))
-   return 0;
-   return s5p_cec_runtime_suspend(dev);
-}
-
-static int __maybe_unused s5p_cec_resume(struct device *dev)
-{
-   if (pm_runtime_suspended(dev))
-   return 0;
-   return s5p_cec_runtime_resume(dev);
-}
-
 static const struct dev_pm_ops s5p_cec_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(s5p_cec_suspend, s5p_cec_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(s5p_cec_runtime_suspend, s5p_cec_runtime_resume,
   NULL)
 };
-- 
1.9.1

[PATCH 4/6] drm/exynos: g2d: fix system and runtime pm integration

[Marek Szyprowski]

Move code from system sleep pm to runtime pm callbacks to ensure proper
driver state preservation when device is under power domain. Then, use
generic helpers for using runtime pm for system sleep pm.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 4bf00f57ffe8..6eca8bb88648 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1475,8 +1475,8 @@ static int g2d_remove(struct platform_device *pdev)
return 0;
 }

-#ifdef CONFIG_PM_SLEEP
-static int g2d_suspend(struct device *dev)
+#ifdef CONFIG_PM
+static int g2d_runtime_suspend(struct device *dev)
 {
struct g2d_data *g2d = dev_get_drvdata(dev);

@@ -1490,25 +1490,6 @@ static int g2d_suspend(struct device *dev)

flush_work(>runqueue_work);

-   return 0;
-}
-
-static int g2d_resume(struct device *dev)
-{
-   struct g2d_data *g2d = dev_get_drvdata(dev);
-
-   g2d->suspended = false;
-   g2d_exec_runqueue(g2d);
-
-   return 0;
-}
-#endif
-
-#ifdef CONFIG_PM
-static int g2d_runtime_suspend(struct device *dev)
-{
-   struct g2d_data *g2d = dev_get_drvdata(dev);
-
clk_disable_unprepare(g2d->gate_clk);

return 0;
@@ -1523,12 +1504,16 @@ static int g2d_runtime_resume(struct device *dev)
if (ret < 0)
dev_warn(dev, "failed to enable clock.\n");

+   g2d->suspended = false;
+   g2d_exec_runqueue(g2d);
+
return ret;
 }
 #endif

 static const struct dev_pm_ops g2d_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(g2d_suspend, g2d_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(g2d_runtime_suspend, g2d_runtime_resume, NULL)
 };

-- 
1.9.1

[PATCH 3/6] drm/exynos: rotator: fix system and runtime pm integration

[Marek Szyprowski]

Use generic helpers instead of open-coding usage of runtime pm for system
sleep pm, which was potentially broken for some corner cases.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 26 ++
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 404367a430b5..6591e406084c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -794,29 +794,6 @@ static int rotator_clk_crtl(struct rot_context *rot, bool 
enable)
return 0;
 }

-
-#ifdef CONFIG_PM_SLEEP
-static int rotator_suspend(struct device *dev)
-{
-   struct rot_context *rot = dev_get_drvdata(dev);
-
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return rotator_clk_crtl(rot, false);
-}
-
-static int rotator_resume(struct device *dev)
-{
-   struct rot_context *rot = dev_get_drvdata(dev);
-
-   if (!pm_runtime_suspended(dev))
-   return rotator_clk_crtl(rot, true);
-
-   return 0;
-}
-#endif
-
 static int rotator_runtime_suspend(struct device *dev)
 {
struct rot_context *rot = dev_get_drvdata(dev);
@@ -833,7 +810,8 @@ static int rotator_runtime_resume(struct device *dev)
 #endif

 static const struct dev_pm_ops rotator_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(rotator_suspend, rotator_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(rotator_runtime_suspend, rotator_runtime_resume,
NULL)
 };
-- 
1.9.1

[PATCH 2/6] drm/exynos: gsc: fix system and runtime pm integration

[Marek Szyprowski]

Use generic helpers instead of open-coding usage of runtime pm for system
sleep pm, which was potentially broken for some corner cases.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

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

-#ifdef CONFIG_PM_SLEEP
-static int gsc_suspend(struct device *dev)
-{
-   struct gsc_context *ctx = get_gsc_context(dev);
-
-   DRM_DEBUG_KMS("id[%d]\n", ctx->id);
-
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return gsc_clk_ctrl(ctx, false);
-}
-
-static int gsc_resume(struct device *dev)
-{
-   struct gsc_context *ctx = get_gsc_context(dev);
-
-   DRM_DEBUG_KMS("id[%d]\n", ctx->id);
-
-   if (!pm_runtime_suspended(dev))
-   return gsc_clk_ctrl(ctx, true);
-
-   return 0;
-}
-#endif
-
 #ifdef CONFIG_PM
 static int gsc_runtime_suspend(struct device *dev)
 {
@@ -1807,7 +1781,8 @@ static int gsc_runtime_resume(struct device *dev)
 #endif

 static const struct dev_pm_ops gsc_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
 };

-- 
1.9.1

[PATCH 1/6] drm/exynos: fimc: fix system and runtime pm integration

[Marek Szyprowski]

Use generic helpers instead of open-coding usage of runtime pm for system
sleep pm, which was potentially broken for some corner cases.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 0525c56145db..147ef0d298cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1753,32 +1753,6 @@ static int fimc_clk_ctrl(struct fimc_context *ctx, bool 
enable)
return 0;
 }

-#ifdef CONFIG_PM_SLEEP
-static int fimc_suspend(struct device *dev)
-{
-   struct fimc_context *ctx = get_fimc_context(dev);
-
-   DRM_DEBUG_KMS("id[%d]\n", ctx->id);
-
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return fimc_clk_ctrl(ctx, false);
-}
-
-static int fimc_resume(struct device *dev)
-{
-   struct fimc_context *ctx = get_fimc_context(dev);
-
-   DRM_DEBUG_KMS("id[%d]\n", ctx->id);
-
-   if (!pm_runtime_suspended(dev))
-   return fimc_clk_ctrl(ctx, true);
-
-   return 0;
-}
-#endif
-
 static int fimc_runtime_suspend(struct device *dev)
 {
struct fimc_context *ctx = get_fimc_context(dev);
@@ -1799,7 +1773,8 @@ static int fimc_runtime_resume(struct device *dev)
 #endif

 static const struct dev_pm_ops fimc_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(fimc_suspend, fimc_resume)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(fimc_runtime_suspend, fimc_runtime_resume, NULL)
 };

-- 
1.9.1

[PATCH 0/6] Exynos: runtime/sleep pm fixes for gfx and media drivers

[Marek Szyprowski]

Dear all,

This is a quick fix of the incorrect usage of runtime pm for system sleep
pm purposes. Patches introduce usage of the generic helpers
pm_runtime_force_{suspend,resume} instead of open-coding them, which was
potentially broken for some corner cases. The side-effect of this patch
set is noticable code reduction. Patches 1-4 should go via exynos drm
kernel tree, while patches 5-6 are aimed for media tree.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Marek Szyprowski (6):
  drm/exynos: fimc: fix system and runtime pm integration
  drm/exynos: gsc: fix system and runtime pm integration
  drm/exynos: rotator: fix system and runtime pm integration
  drm/exynos: g2d: fix system and runtime pm integration
  media: s5p-cec: fix system and runtime pm integration
  media: s5p-jpeg: fix system and runtime pm integration

 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 29 ++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 29 +++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 29 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 26 ++
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 24 
 drivers/staging/media/s5p-cec/s5p_cec.c | 17 ++---
 6 files changed, 19 insertions(+), 135 deletions(-)

-- 
1.9.1

[Bug 97025] flip queue failed: Device or resource busy

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

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

--- Comment #17 from Bernd Steinhauser  ---
Created attachment 126132
  --> https://bugs.freedesktop.org/attachment.cgi?id=126132=edit
plasmashell backtrace

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

[Bug 97025] flip queue failed: Device or resource busy

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

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

--- Comment #16 from Bernd Steinhauser  ---
Created attachment 126131
  --> https://bugs.freedesktop.org/attachment.cgi?id=126131=edit
irc conversiaton with Martin Grässlin

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

[Bug 97025] flip queue failed: Device or resource busy

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

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

--- Comment #15 from Bernd Steinhauser  ---
I tried a few things, but wasn't really able to nail this down.
I downgraded to mesa 11.2 to see if that helps, but it does not.

However, today I had plasmashell freezing after unlocking the screen.
Only plasmashell froze, everything else kept working as expected.

I contacted Martin on IRC and he thought it might be related to this.
I'll attach the log from the conversation as well as the backtrace.

He might be right, because around the time when this happened, I get these
messages in dmesg:
[88765.431890] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[88765.436865] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[88765.441940] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[88765.446861] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[88765.451865] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[88765.456903] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[89579.510005] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[89579.514998] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[89579.520053] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[89579.525158] [drm:amdgpu_crtc_page_flip] *ERROR* failed to reserve new rbo
buffer before flip
[113833.139104] [drm:amdgpu_atombios_dp_link_train] *ERROR* displayport link
status failed
[113833.139117] [drm:amdgpu_atombios_dp_link_train] *ERROR* clock recovery
failed
[113833.361471] [drm:amdgpu_atombios_dp_link_train] *ERROR* displayport link
status failed
[113833.361484] [drm:amdgpu_atombios_dp_link_train] *ERROR* clock recovery
failed
[113836.962993] [drm:amdgpu_crtc_page_flip] *ERROR* failed to get vblank before
flip

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

Skylake graphics regression: projector failure with 4.8-rc3

[James Bottomley]

On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > We seem to have an xrandr regression with skylake now.  What's
> > happening is that I can get output on to a projector, but the 
> > system is losing video when I change the xrandr sessions (like 
> > going from a --above b to a --same-as b).  The main screen goes 
> > blank, which is basically a reboot situation.  Unfortunately, I 
> > can't seem to get the logs out of systemd to see if there was a 
> > dump to dmesg (the system was definitely responding).
> > 
> > I fell back to 4.6.2 which worked perfectly, so this is definitely 
> > some sort of regression.  I'll be able to debug more fully when I 
> > get back home from the Linux Security Summit.
> 
> I'm home now.  Unfortunately, my monitor isn't as problematic as the
> projector, but by flipping between various modes and separating and
> overlaying the panels with --above and --same-as (xrandr), I can
> eventually get it to the point where the main LCD panel goes black 
> and can only be restarted by specifying a different mode.
> 
> This seems to be associated with these lines in the X
> 
> [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument [22]
> 
> But the curious thing is that even if this fails with the error 
> message once, it may succeed a second time, so it looks to be a 
> transient error translation problem from the kernel driver.
> 
> I've attached the full log below.
> 
> This is only with a VGA output.  I currently don't have a HDMI 
> dongle, but I'm in the process of acquiring one.

After more playing around, I'm getting thousands of these in the kernel
log (possibly millions: the log wraps very fast):

[23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train 
DP, aborting

And then finally it gives up with 

[25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe B FIFO underrun
[25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun

And the crtc for the VGA output becomes non-responsive to any
configuration command.  This requires a reboot and sometimes a UEFI
variable reset before it comes back.

James

Kernel Freeze with American Megatrends BIOS

[Peter Wu]

On Wed, Aug 31, 2016 at 02:21:31PM +0200, Roland Singer wrote:
> Am 31.08.2016 um 13:46 schrieb Peter Wu:
> > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
> >> Am 30.08.2016 um 21:53 schrieb Peter Wu:
> >>> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
>  [+cc linux-acpi, linux-kernel, dri-devel]
> 
>  Hi Roland,
> 
>  I have no idea how to debug this problem.  Are you seeing something
>  that suggests it may be a PCI problem?
> >>>
> >>> Yes I suspect there is an ACPI and/ or PCI problem, possibly
> >>> device-specific. Steps to reproduce on the affected machines:
> >>>
> >>>  1. Load nouveau.
> >>>  2. Wait for it to runtime suspend.
> >>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> >>> reported.
> >>>
> >>
> >> I can confirm this. Same result on my machine.
> >>
> >> Here is a link to my ACPI tables:
> >> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz
> >>
> >> The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
> >>
> >>
> >> Method (PGON, 1, Serialized)
> >> {
> >> /* ... */
> >>
> >> GPPR (PION, One)
> >> If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
> >> Windows 2009 only works! */
> >> {
> > [..]
> >> }
> >> Else
> >> {
> >> LKEN (PION)
> >> }
> >>
> >> /* ... */
> >> 
> >> Return (Zero)
> >> }
> >>
> >>
> >>
> >> If not set to Windows 2009, then this is triggered:
> >>
> >>
> >> Method (LKEN, 1, NotSerialized)
> >> {
> > [..]
> >> }
> > 
> > Yep, this is the same code. I stripped out irrelevant parts from the
> > previous mail for brevity.
> > 
> >> Is it possible to override the specific ACPI table functions (SSDT) in the 
> >> DSDT?
> >> This way I could try to debug to find some more information...
> > 
> > See Documentation/acpi/initrd_table_override.txt and note that it is
> > important that the tables are really located at /kernel/firmware/acpi/
> > in your initrd (which must be the first, even before any possible
> > microcode updates).
> > 
> > What are you trying to do? For ACPI method tracing, see
> > Documentation/acpi/method-tracing.txt
> > 
> 
> Oh, you're right.
> 
> Thanks. Right now I am overriding the DSDT, but I am not able to override
> the SSDT, because I have to fix and compile all the SSDT files. There
> are too many compile errors... Wanted to find the exact line which
> is responsible for the hickup.

Have you disassembled with externs included? That is,

iasl -e *.dat -d ssdtX.dat

If you are sure that the remaining errors are harmless, you can use the
'-f' option to ignore errors. You can also use the `-ve` option to
suppress warnings and remarks so you can focus on the errors.

If you look at my notes.txt, you will see that _OFF always executes the
same code. PGON differs. When the problem occurs, "Q0L0" somehow always
reads back as non-zero and LNKS < 7.

> >>> Yes I suspect there is an ACPI and/ or PCI problem, possibly
> >>> device-specific. Steps to reproduce on the affected machines:
> >>>
> >>>  1. Load nouveau.
> >>>  2. Wait for it to runtime suspend.
> >>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> >>> reported.
> 
> I noticed following:
> 
> 1. Blacklist nouveau
> 2. Boot to GDM login manager (Wayland)
> 3. Switch to TTY with CTRL+ALT+FN2
> 4. Load bbswitch
> 5. Switch off GPU
> 6. run lspci -> no freeze
> 7. Switch to GDM
> 8. Login to a Wayland session (X11 won't work)
> 9. run lspci in a GUI terminal -> system freezes

Is nouveau somehow loaded anyway? All those extra components (X11,
Wayland, etc.) are unnecessary to reproduce the core problem. It occurs
whenever the device is being resumed (either via DSM/_PS0 or via power
resource PG00._ON).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

[PATCH RFC] ARM: dts: samsung: add rga-lvds panel in itop elite

[Andrzej Hajda]

Hi,


On 08/30/2016 12:50 AM, Randy Li wrote:
> It is actually a lvds panel connected through a rga-lvds bridge.
> But I really have no idea about what does a port mean in fimd node.
>
> Also how should I configure this panel size? I think the i2c found
> on the panel schematic, but it more likely to be used a touch screen
> touth. Also the touch screen is not supported in currently driver.
>
> Signed-off-by: Randy Li 
> ---
>  arch/arm/boot/dts/exynos4412-itop-elite.dts | 35 
> ++---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
> b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> index e1cda54..2d67385 100644
> --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
> @@ -139,6 +139,20 @@
>   assigned-clocks = < CLK_MOUT_CAM0>;
>   assigned-clock-parents = < CLK_XUSBXTI>;
>   };
> + 
> + vcc_sys_lcd: sys-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < 4 GPIO_ACTIVE_HIGH>;
> + };
> +
> + panel: panel {
> + ddc-i2c-bus = <_3>;
> + power-supply = <_sys_lcd>;
> + enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };

Panel has no compatible string, which driver will handle this node?

Regards
Andrzej

>  };
>  
>  _1 {
> @@ -221,9 +235,6 @@
>  };
>  
>   {
> - pinctrl-0 = <_out>;
> - pinctrl-names = "default";
> - samsung,pwm-outputs = <1>;
>   status = "okay";
>  };
>  
> @@ -239,3 +250,21 @@
>   assigned-clock-parents = < CLK_MOUT_MPLL_USER_T>;
>   assigned-clock-rates = <0>, <17600>;
>  };
> +
> +_3 {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-0 = <_clk _data24 _out>;
> + pinctrl-names = "default";
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 0 {
> + reg = <0>;
> + rga_lvds: endpoint {
> + remote-endpoint = <>;
> + };
> + };
> +};

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Am 31.08.2016 um 13:46 schrieb Peter Wu:
> On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
>> Am 30.08.2016 um 21:53 schrieb Peter Wu:
>>> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
 [+cc linux-acpi, linux-kernel, dri-devel]

 Hi Roland,

 I have no idea how to debug this problem.  Are you seeing something
 that suggests it may be a PCI problem?
>>>
>>> Yes I suspect there is an ACPI and/ or PCI problem, possibly
>>> device-specific. Steps to reproduce on the affected machines:
>>>
>>>  1. Load nouveau.
>>>  2. Wait for it to runtime suspend.
>>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
>>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
>>> reported.
>>>
>>
>> I can confirm this. Same result on my machine.
>>
>> Here is a link to my ACPI tables:
>> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz
>>
>> The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
>>
>>
>> Method (PGON, 1, Serialized)
>> {
>> /* ... */
>>
>> GPPR (PION, One)
>> If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
>> Windows 2009 only works! */
>> {
> [..]
>> }
>> Else
>> {
>> LKEN (PION)
>> }
>>
>> /* ... */
>> 
>> Return (Zero)
>> }
>>
>>
>>
>> If not set to Windows 2009, then this is triggered:
>>
>>
>> Method (LKEN, 1, NotSerialized)
>> {
> [..]
>> }
> 
> Yep, this is the same code. I stripped out irrelevant parts from the
> previous mail for brevity.
> 
>> Is it possible to override the specific ACPI table functions (SSDT) in the 
>> DSDT?
>> This way I could try to debug to find some more information...
> 
> See Documentation/acpi/initrd_table_override.txt and note that it is
> important that the tables are really located at /kernel/firmware/acpi/
> in your initrd (which must be the first, even before any possible
> microcode updates).
> 
> What are you trying to do? For ACPI method tracing, see
> Documentation/acpi/method-tracing.txt
> 

Oh, you're right.

Thanks. Right now I am overriding the DSDT, but I am not able to override
the SSDT, because I have to fix and compile all the SSDT files. There
are too many compile errors... Wanted to find the exact line which
is responsible for the hickup.

>>> Yes I suspect there is an ACPI and/ or PCI problem, possibly
>>> device-specific. Steps to reproduce on the affected machines:
>>>
>>>  1. Load nouveau.
>>>  2. Wait for it to runtime suspend.
>>>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
>>>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
>>> reported.

I noticed following:

1. Blacklist nouveau
2. Boot to GDM login manager (Wayland)
3. Switch to TTY with CTRL+ALT+FN2
4. Load bbswitch
5. Switch off GPU
6. run lspci -> no freeze
7. Switch to GDM
8. Login to a Wayland session (X11 won't work)
9. run lspci in a GUI terminal -> system freezes

[pull] amdgpu drm-fixes-4.8

[Alex Deucher]

Hi Dave,

Fixes for 4.8:
- 2 CI S4 fixes
- error handling fix

I have additional features for 4.9, but I'll be out of
the office next week, so I probably won't get to send them out
until the following week.

The following changes since commit 279cf3f23870f7eb8ca071115e06d3d5ca0a2b9e:

  drm/nouveau/acpi: use DSM if bridge does not support D3cold (2016-08-31 
16:54:05 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.8

for you to fetch changes up to 1f703e6679f373f5bba4efe7093aa82e91af4037:

  drm/amdgpu: record error code when ring test failed (2016-08-31 12:45:56 
-0400)


Chunming Zhou (1):
  drm/amdgpu: record error code when ring test failed

jimqu (2):
  drm/amd/amdgpu: sdma resume fail during S4 on CI
  drm/amd/amdgpu: compute ring test fail during S4 on CI

 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  5 +++--
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  3 +++
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 12 +---
 3 files changed, 15 insertions(+), 5 deletions(-)

[PATCH v2] drm: drm_probe_helper: Fix output_poll_work scheduling

[Peter Ujfalusi]

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

Signed-off-by: Peter Ujfalusi 
---
Hi,

Changes since v1:
- dropped the last paragraph from the commit message.

Regards,
Peter

 drivers/gpu/drm/drm_probe_helper.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index a0df377d7d1c..f6b64d7d3528 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
 {
bool poll = false;
struct drm_connector *connector;
+   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;

WARN_ON(!mutex_is_locked(>mode_config.mutex));

@@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
*dev)
poll = true;
}

+   if (dev->mode_config.delayed_event) {
+   poll = true;
+   delay = 0;
+   }
+
if (poll)
-   schedule_delayed_work(>mode_config.output_poll_work, 
DRM_OUTPUT_POLL_PERIOD);
+   schedule_delayed_work(>mode_config.output_poll_work, 
delay);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);

--
2.9.3

Kernel Freeze with American Megatrends BIOS

[Peter Wu]

On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
> Am 30.08.2016 um 21:53 schrieb Peter Wu:
> > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
> >> [+cc linux-acpi, linux-kernel, dri-devel]
> >>
> >> Hi Roland,
> >>
> >> I have no idea how to debug this problem.  Are you seeing something
> >> that suggests it may be a PCI problem?
> > 
> > Yes I suspect there is an ACPI and/ or PCI problem, possibly
> > device-specific. Steps to reproduce on the affected machines:
> > 
> >  1. Load nouveau.
> >  2. Wait for it to runtime suspend.
> >  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
> >  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> > reported.
> > 
> 
> I can confirm this. Same result on my machine.
> 
> Here is a link to my ACPI tables:
> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz
> 
> The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
> 
> 
> Method (PGON, 1, Serialized)
> {
> /* ... */
> 
> GPPR (PION, One)
> If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
> Windows 2009 only works! */
> {
[..]
> }
> Else
> {
> LKEN (PION)
> }
> 
> /* ... */
> 
> Return (Zero)
> }
> 
> 
> 
> If not set to Windows 2009, then this is triggered:
> 
> 
> Method (LKEN, 1, NotSerialized)
> {
[..]
> }

Yep, this is the same code. I stripped out irrelevant parts from the
previous mail for brevity.

> Is it possible to override the specific ACPI table functions (SSDT) in the 
> DSDT?
> This way I could try to debug to find some more information...

See Documentation/acpi/initrd_table_override.txt and note that it is
important that the tables are really located at /kernel/firmware/acpi/
in your initrd (which must be the first, even before any possible
microcode updates).

What are you trying to do? For ACPI method tracing, see
Documentation/acpi/method-tracing.txt
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

[PATCH 1/2] drm/udl: fix a NULL pointer reference in udl_gem_free_object().

[Haixia Shi]

For details see https://bugs.chromium.org/p/chromium/issues/detail?id=468050

So drm_mode_config_cleanup() is called from udl_driver_unload() in
which we found there's still a framebuffer left, hence the WARN in
drm_crtc.c:5495. This also forcefully releases all the buffers.

A bit later the actual drm_buf_release comes in which attempts to
release the buffer again.

On Wed, Aug 31, 2016 at 12:55 AM, Daniel Vetter  wrote:
>
> On Tue, Aug 30, 2016 at 02:50:20PM -0700, Haixia Shi wrote:
> > Previously this function had a NULL pointer check for gem->map_list.map, but
> > that line was refactored after commit 
> > 0de23977cfeb5b357ec884ba15417ae118ff9e9bb
> > ("drm/gem: convert to new unified vma manager").
> >
> > After the refactor it is still necessasry to check that the vma manager is 
> > not
> > NULL because udl_gem_free_object() may come in after the vma manager is 
> > destroyed.
>
> When/how does this happen? Backtrace? Destroying the vma manager before
> the objects are all gone sounds a bit fishy.
> -Daniel
>
> >
> > Signed-off-by: Haixia Shi 
> > Reviewed-by: Stéphane Marchesin 
> > ---
> >  drivers/gpu/drm/udl/udl_gem.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> > index 818e707..72e1bd4 100644
> > --- a/drivers/gpu/drm/udl/udl_gem.c
> > +++ b/drivers/gpu/drm/udl/udl_gem.c
> > @@ -204,7 +204,8 @@ void udl_gem_free_object(struct drm_gem_object *gem_obj)
> >   if (obj->pages)
> >   udl_gem_put_pages(obj);
> >
> > - drm_gem_free_mmap_offset(gem_obj);
> > + if (gem_obj->dev->vma_offset_manager)
> > + drm_gem_free_mmap_offset(gem_obj);
> >  }
> >
> >  /* the dumb interface doesn't work with the GEM straight MMAP
> > --
> > 2.8.0.rc3.226.g39d4020
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH v2 0/3] drm/i2c: tda998x ASoC hdmi-codec support + BeagleBoneBlack audio support

[Russell King - ARM Linux]

On Tue, Aug 09, 2016 at 10:00:03PM +0300, Jyri Sarha wrote:
> Changes since first version [1] of this series:
> - "drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata"
>   - Change audio in tda998x pdata to audio_params to match the naming in
> private data struct
>   - Skip IEC958_AES2 byte when writing status bytes to registers 
>   - Turn AFMT-macros to enum
>   - include linux/hdmi.h in drm/i2c/tda998x.h
> - "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
>   - Fix macronaming naming in dt-bindings/display/tda998x.h
>   - Turn AFMT-macros to enum
>   - Add locking to protect access to audio registers from ASoC thread
> - "dts/am335x-boneblack: SQUASH"
>   - Use corrected macros from dt-bindings/display/tda998x.h

Thanks, series queued.

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

[Bug 97460] [drm][amdgpu][CIK] drm_sysfs_connector - BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

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

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #6 from Alex Deucher  ---
Workaround committed.

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

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Russell King - ARM Linux]

On Tue, Aug 23, 2016 at 10:05:45AM +0200, Hans Verkuil wrote:
> 
> 
> On 08/23/16 09:59, Russell King - ARM Linux wrote:
> > On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 08/12/2016 04:15 PM, Russell King wrote:
> >>> Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> >>> implementation.
> >>>
> >>> Signed-off-by: Russell King 
> >>> ---
> >>>  drivers/gpu/drm/bridge/Kconfig|   7 +
> >>>  drivers/gpu/drm/bridge/Makefile   |   1 +
> >>>  drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 344 
> >>> ++
> >>>  drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
> >>>  include/linux/platform_data/dw_hdmi-cec.h |  16 ++
> >>>  5 files changed, 421 insertions(+), 11 deletions(-)
> >>>  create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
> >>>  create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
> >>>
> >>
> >> 
> >>
> >>> +static unsigned int parse_hdmi_addr(const struct edid *edid)
> >>> +{
> >>> + if (!edid || edid->extensions == 0)
> >>> + return (u16)~0;
> >>> +
> >>> + return cec_get_edid_phys_addr((u8 *)edid,
> >>> + EDID_LENGTH * (edid->extensions + 1), NULL);
> >>> +}
> >>> +
> >>> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long 
> >>> event,
> >>> +   void *data)
> >>> +{
> >>> + struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> >>> + union hdmi_event *event_block = data;
> >>> + unsigned int phys;
> >>> +
> >>> + dev_info(event_block->base.source, "event %lu\n", event);
> >>> +
> >>> + if (event_block->base.source != cec->adap->devnode.parent)
> >>> + return NOTIFY_OK;
> >>> +
> >>> + switch (event) {
> >>> + case HDMI_CONNECTED:
> >>> + break;
> >>> +
> >>> + case HDMI_DISCONNECTED:
> >>> + cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> >>> + break;
> >>> +
> >>> + case HDMI_NEW_EDID:
> >>> + phys = parse_hdmi_addr(event_block->edid.edid);
> >>> + cec_s_phys_addr(cec->adap, phys, false);
> >>> + break;
> >>> + }
> >>> +
> >>> + return NOTIFY_OK;
> >>> +}
> >>
> >> Wouldn't it make a lot of sense to integrate this into the cec framework?
> >>
> >> All you need is to pass an hdmi_notifier_dev as argument to 
> >> cec_allocate_adapter()
> >> and you can integrate this.
> >>
> >> If you are OK with that, then I can make patches for that.
> > 
> > It's not just about CEC.  It's also used for passing information between
> > the video and audio parts, so tying this into CEC is wrong.
> 
> I'm not saying that the hdmi notifier should be integrated, just that the
> CEC core can register itself as a notifier and handle cec_s_phys_addr.

Yes, that would decrease the amount of code duplication.

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

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

[Russell King - ARM Linux]

On Tue, Aug 23, 2016 at 10:03:03AM +0200, Hans Verkuil wrote:
> Hi Russell,
> 
> On 08/12/16 16:15, Russell King wrote:
> > +   ret = devm_request_threaded_irq(>dev, cec->irq,
> > +   dw_hdmi_cec_hardirq,
> > +   dw_hdmi_cec_thread, IRQF_SHARED,
> > +   DEV_NAME, cec->adap);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = cec_register_adapter(cec->adap);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   /*
> > +* CEC documentation says we must not call cec_delete_adapter
> > +* after a successful call to cec_register_adapter().
> > +*/
> > +   devm_remove_action(>dev, dw_hdmi_cec_del, cec);
> > +
> > +   hdmi_register_notifier(>nb);
> 
> The notifier is registered here, but who provides CEC with the initial
> physical address? As I understand it, it only tells you when things change,
> not what the initial state is.

Correct, that's a short-coming of this.  Solving that is not really
an easy problem - the hdmi notifiers don't track the state (they
aren't really aware of state themselves), nor do they track who the
originator of the messages is (again, because they don't track state.)

Fixing that requires a much more complex solution - I don't think I've
time to solve that (as illustrated by this reply taking over a week.)

So, we can either decide that we're not going to merge any CEC drivers
and other HDMI audio drivers until we solve this problem, denying people
the ability to use CEC, or we can merge what we have now and work on
solving the problem later.

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

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Am 30.08.2016 um 21:53 schrieb Peter Wu:
> On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
>> [+cc linux-acpi, linux-kernel, dri-devel]
>>
>> Hi Roland,
>>
>> I have no idea how to debug this problem.  Are you seeing something
>> that suggests it may be a PCI problem?
> 
> Yes I suspect there is an ACPI and/ or PCI problem, possibly
> device-specific. Steps to reproduce on the affected machines:
> 
>  1. Load nouveau.
>  2. Wait for it to runtime suspend.
>  2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
>  3. lspci never returns, few moments later an AML_INFINITE_LOOP is
> reported.
> 

I can confirm this. Same result on my machine.

Here is a link to my ACPI tables:
https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+files/Razer-Blade.tar.gz

The specific source for the NVIDIA card can be found in the ssdt5.dsl file.


Method (PGON, 1, Serialized)
{
/* ... */

GPPR (PION, One)
If ((OSYS == 0x07D9))  /* Is Windows 2009 - In my case, setting to 
Windows 2009 only works! */
{
If ((PION == Zero))
{
P0AP = Zero
P0RM = Zero
}
ElseIf ((PION == One))
{
P1AP = Zero
P1RM = Zero
}
ElseIf ((PION == 0x02))
{
P2AP = Zero
P2RM = Zero
}

If ((PBGE != Zero))
{
If (SBDL (PION))
{
PUAB (PION)
CBDL = GUBC (PION)
MBDL = GMXB (PION)
If ((CBDL > MBDL))
{
CBDL = MBDL /* \_SB_.PCI0.MBDL */
}

PDUB (PION, CBDL)
}
}

If ((PION == Zero))
{
P0LD = Zero
P0TR = One
TCNT = Zero
While ((TCNT < LDLY))
{
If ((P0VC == Zero))
{
Break
}

Sleep (0x10)
TCNT += 0x10
}
}
ElseIf ((PION == One))
{
P1LD = Zero
P1TR = One
TCNT = Zero
While ((TCNT < LDLY))
{
If ((P1VC == Zero))
{
Break
}

Sleep (0x10)
TCNT += 0x10
}
}
ElseIf ((PION == 0x02))
{
P2LD = Zero
P2TR = One
TCNT = Zero
While ((TCNT < LDLY))
{
If ((P2VC == Zero))
{
Break
}

Sleep (0x10)
TCNT += 0x10
}
}
}
Else
{
LKEN (PION)
}

/* ... */

Return (Zero)
}



If not set to Windows 2009, then this is triggered:


Method (LKEN, 1, NotSerialized)
{
Local3 = (CPEX & 0x0F)
If ((Local3 == Zero))
{
If ((Arg0 == Zero))
{
P0L0 = One
Sleep (0x10)
Local0 = Zero
While (P0L0)
{
If ((Local0 > 0x04))
{
Break
}

Sleep (0x10)
Local0++
}
}
ElseIf ((Arg0 == One))
{
P1L0 = One
Sleep (0x10)
Local0 = Zero
While (P0L0)
{
If ((Local0 > 0x04))
{
Break
}

Sleep (0x10)
Local0++
}
}
ElseIf ((Arg0 == 0x02))
{
P2L0 = One
Sleep (0x10)
Local0 = Zero
While (P0L0)
{
If ((Local0 > 0x04))
{
Break
}

Sleep (0x10)
Local0++
}
}
}
ElseIf ((Local3 != Zero))
{
If ((Arg0 == Zero))
{
Q0L0 = One
Sleep (0x10)
Local0 = Zero
While (Q0L0)
{
If ((Local0 > 0x04))
{
Break
}

Sleep (0x10)
Local0++
}
}
ElseIf ((Arg0 == 

[Bug 97548] DPM states not working

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

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

--- Comment #1 from Jarkko K  ---
Created attachment 126129
  --> https://bugs.freedesktop.org/attachment.cgi?id=126129=edit
bug in freesync code too?

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

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

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

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

--- Comment #26 from Marek Olšák  ---
(In reply to AmarildoJr from comment #25)
> Marek, since you work for AMD, I wonder if you could get a few hints for the
> fix on Catalyst's sources?

It's not so simple. This is a bug somewhere in the Mesa driver such that
looking at other drivers won't likely help.

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

[PATCH 1/6] backlight: pwm_bl: Handle gpio that can sleep

[Lee Jones]

On Wed, 31 Aug 2016, Maxime Ripard wrote:

> Some backlight GPIOs might be connected to some i2c based expanders whose
> access might sleep.
> 
> Since it's not in any critical path, use the cansleep variant of the GPIO
> API.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/video/backlight/pwm_bl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index b2b366bb0f97..12614006211e 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -55,7 +55,7 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, 
> int brightness)
>   dev_err(pb->dev, "failed to enable power supply\n");
>  
>   if (pb->enable_gpio)
> - gpiod_set_value(pb->enable_gpio, 1);
> + gpiod_set_value_cansleep(pb->enable_gpio, 1);
>  
>   pwm_enable(pb->pwm);
>   pb->enabled = true;
> @@ -70,7 +70,7 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
>   pwm_disable(pb->pwm);
>  
>   if (pb->enable_gpio)
> - gpiod_set_value(pb->enable_gpio, 0);
> + gpiod_set_value_cansleep(pb->enable_gpio, 0);
>  
>   regulator_disable(pb->power_supply);
>   pb->enabled = false;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2] drm: drm_probe_helper: Fix output_poll_work scheduling

[Daniel Vetter]

On Wed, Aug 31, 2016 at 02:09:05PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
> 
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
> already registered to be handled. The detection will be delayd by
> DRM_OUTPUT_POLL_PERIOD in any case.
> Furthermore if none of the connectors are marked as POLL_CONNECT or
> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
> always connected: the output_poll_work will not run at all even if we
> have delayed event marked.
> 
> When none of the connectors require polling, their initial status change
> from unknown to connected/disconnected is not going to be handled until
> the first kms application starts or if we have fb console enabled.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Hi,
> 
> Changes since v1:
> - dropped the last paragraph from the commit message.

I added a few more words to the commit message to explain when exactly
this is a problem and applied your patch to drm-misc.

Thanks, Daniel
> 
> Regards,
> Peter
> 
>  drivers/gpu/drm/drm_probe_helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index a0df377d7d1c..f6b64d7d3528 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
> *dev)
>  {
>   bool poll = false;
>   struct drm_connector *connector;
> + unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
> 
>   WARN_ON(!mutex_is_locked(>mode_config.mutex));
> 
> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device 
> *dev)
>   poll = true;
>   }
> 
> + if (dev->mode_config.delayed_event) {
> + poll = true;
> + delay = 0;
> + }
> +
>   if (poll)
> - schedule_delayed_work(>mode_config.output_poll_work, 
> DRM_OUTPUT_POLL_PERIOD);
> + schedule_delayed_work(>mode_config.output_poll_work, 
> delay);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
> 
> --
> 2.9.3
> 

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

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Am 30.08.2016 um 21:21 schrieb Peter Wu:
> On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote:
>> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
>>  wrote:
>>> I configured bbswitch to not set any states automatically...
>>> So it's possible to obtain and verify the GPU power state.
>>>
>>> However I removed the bbswitch module and booted with nouveau.
>>>
>>> Kernel 4.7.2: nouveau switches the discrete GPU off.
>>>   I can't trigger the freeze, because bbswitch is missing.
>>>   I'll work with the system and see if it will freeze.
>>>
>>> Kernel 4.8-rc4: nouveau does not care about the power state and
>>> the discrete GPU is never switched off. I will notice
>>> this, because the second cooling FAN will stop...
>>> Same log messages as send before.
>>
>> That's surprising. I believe there's an issue with the new logic when
>> there's an HDMI audio subdevice. However that only appears if there's
>> a cable plugged in, at least in the systems Peter tested. You should
>> be able to see whether it's there or not with 'lspci'.
> 
> I doubt that the audio device is responsible here, that should only show
> up after following very specific steps (runtime suspend/resume (PCI or
> ACPI magic), remove PCI device, rescan bus).
> 
>> You can check for sure by looking in the vgaswitcheroo state. It
>> should say DynOff when it's powered off.
>>
>> Either way, I think using bbswitch + nouveau isn't supported by
>> anyone, so if you want to use it that way, you're on your own. (You
>> may want to load nouveau with runpm=0 so that nouveau doesn't try to
>> manage the GPU suspend stuff.)
> 
> I understood that Roland's intent is to check the power state, not use
> the suspend functionality of bbswitch, if you load bbswitch without
> module options amd do not write to /proc/bbswitch, then it allows you to
> read out the actual status (you could also just use lspci -H1 for that
> though).
> 

lspci -H1 works perfect. Thanks.
Just tried to verify the output with lspci -H1. I unloaded the nouveau
module and modprobe freezed with:

  $ modprobe -r nouveau
nouveau :01:00.0: pci: failed to adjust lnkctl speed
nouveau :01:00.0: fb: init failed. -22
nouveau :01:00.0: init failed with -22
nouveau: DRM::: init failed with -22
nouveau: DRM::: init failed with -22

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Am 30.08.2016 um 20:13 schrieb Ilia Mirkin:
> On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
>  wrote:
>> I configured bbswitch to not set any states automatically...
>> So it's possible to obtain and verify the GPU power state.
>>
>> However I removed the bbswitch module and booted with nouveau.
>>
>> Kernel 4.7.2: nouveau switches the discrete GPU off.
>>   I can't trigger the freeze, because bbswitch is missing.
>>   I'll work with the system and see if it will freeze.
>>
>> Kernel 4.8-rc4: nouveau does not care about the power state and
>> the discrete GPU is never switched off. I will notice
>> this, because the second cooling FAN will stop...
>> Same log messages as send before.
> 
> That's surprising. I believe there's an issue with the new logic when
> there's an HDMI audio subdevice. However that only appears if there's
> a cable plugged in, at least in the systems Peter tested. You should
> be able to see whether it's there or not with 'lspci'.
> 
> You can check for sure by looking in the vgaswitcheroo state. It
> should say DynOff when it's powered off.
> 
> Either way, I think using bbswitch + nouveau isn't supported by
> anyone, so if you want to use it that way, you're on your own. (You
> may want to load nouveau with runpm=0 so that nouveau doesn't try to
> manage the GPU suspend stuff.)
> 
>   -ilia
> 

Kernel 4.8-rc4:

While running lspci, following kernel log message was printed on the TTY:

  nouveau: :01:00:0: priv: HUB0: 6013d4 573f (1f408200)
  nouveau: :01:00:0: priv: HUB0: 10ecc0  (1940822c)

This is my output of lspci:

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 
07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal 
subsystem (rev 31)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial 
IO I2C Controller #0 (rev 31)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial 
IO I2C Controller #1 (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI 
#1 (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 
(rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 
(rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 
(rev f1)
00:1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13 
(rev f1)
00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial 
IO UART #0 (rev 31)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev a1)
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network 
Adapter (rev 32)
3d:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 
Controller (rev 01)

[Bug 97548] DPM states not working

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

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

Bug ID: 97548
   Summary: DPM states not working
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jarkko_korpi at hotmail.com

I am using 4.6-staging because I need the audio driver it provides.

I have been trying to lower the voltages of the card by bios editing and there
seems to be no issues with windows, but I dont seem to get higher DPM states in
use at linux. Something is broken.


dmesg is spammed with these

amdgpu-pro, mint 18, rx480. Latest 4.6 kernel from git (agd5f/linux).

[ 1214.592256] VM fault (0x14, vmid 6) at page 1071080, write from 'CB0'
(0x43423000) (96)
[ 1214.592262] amdgpu :01:00.0: GPU fault detected: 146 0x059aa504
[ 1214.592262] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057D2
[ 1214.592263] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D0D0014
[ 1214.592264] VM fault (0x14, vmid 6) at page 1071058, write from 'CB7'
(0x43423700) (208)
[ 1214.592269] amdgpu :01:00.0: GPU fault detected: 146 0x059a5504
[ 1214.592270] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057D8
[ 1214.592271] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D020014
[ 1214.592271] VM fault (0x14, vmid 6) at page 1071064, write from 'CB2'
(0x43423200) (32)
[ 1214.592642] amdgpu :01:00.0: GPU fault detected: 146 0x0f2ad014
[ 1214.592643] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057E9
[ 1214.592643] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C0D000C
[ 1214.592644] VM fault (0x0c, vmid 6) at page 1071081, read from 'CB7'
(0x43423700) (208)
[ 1214.592650] amdgpu :01:00.0: GPU fault detected: 146 0x0f2aa014
[ 1214.592650] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057D8
[ 1214.592651] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C02000C
[ 1214.592652] VM fault (0x0c, vmid 6) at page 1071064, read from 'CB2'
(0x43423200) (32)
[ 1214.592657] amdgpu :01:00.0: GPU fault detected: 146 0x0f60e00c
[ 1214.592658] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057EC
[ 1214.592659] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D0E0014
[ 1214.592659] VM fault (0x14, vmid 6) at page 1071084, write from 'CB6'
(0x43423600) (224)
[ 1214.592665] amdgpu :01:00.0: GPU fault detected: 146 0x0f28a00c
[ 1214.592666] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057D0
[ 1214.592666] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D0E0014
[ 1214.592667] VM fault (0x14, vmid 6) at page 1071056, write from 'CB6'
(0x43423600) (224)
[ 1214.592673] amdgpu :01:00.0: GPU fault detected: 146 0x0ec25014
[ 1214.592673] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001057D2
[ 1214.592674] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D060014
[ 1214.592675] VM fault (0x14, vmid 6) at page 1071058, write from 'CB0'
(0x43423000) (96)
[ 1214.661835] steam[6544]: segfault at 4184ddd7 ip f72ea771 sp
ff9ce690 error 4 in libc-2.23.so[f727d000+1af000]
[ 1353.103633] 
failed to send pre message 200 ret is 0 
[ 1353.317672] 
failed to send message 200 ret is 0 
[ 1353.536394] 
failed to send pre message 201 ret is 0 
[ 1353.754228] 
failed to send message 201 ret is 0 
[ 1961.904046] 
failed to send pre message 200 ret is 0 
[ 1962.120865] 
failed to send message 200 ret is 0 
[ 1962.342261] 
failed to send pre message 201 ret is 0 
[ 1962.560233] 
failed to send message 201 ret is 0

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

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Am 30.08.2016 um 20:09 schrieb Emil Velikov:
> I second Ilia here. Using bbswitch in conjunction with any driver (be
> that nouveau or the proprietary one) is a bad idea.
>

I removed bbswitch from my system and will use vgaswitcheroo to check
the GPU power state from now.

> (If Ilia's suggestions does not help) Confirm if the freeze is due
> to/as the GPU is powered on or off.
>

Yeah, the freeze is caused by the switched off GPU.
Waited for the nouveau driver to switch it off, before starting
the graphical user interface...

> Out of curiosity: how did you force X to ignore the device ?
>

I tried to tell X11 to ignore the device with the following
configuration:

  Section "Device"
  Identifier  "Nvidia"
  VendorName  "NVIDIA Corporation"
  Option  "Ignore" "true"
  EndSection

> You can check if it's the boot_vga assumption with
> cat /sys/class/drm/card*/device/{boot_vga,vendor}
> If the output changes them my assumption holds true.

Output did not change:

  1
  0x8086

0x8086 is the vendor ID of intel. So that's ok...

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

[Tony Lindgren]

* Jyri Sarha  [160831 11:49]:
> On 08/31/16 21:04, Tony Lindgren wrote:
> > * Jyri Sarha  [160831 06:19]:
> >>   ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC
> >> node
> >>   ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node
> >>   ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
> >>   ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node
> > 
> > If some of these dts changes are OK for me to apply separately already,
> > please let me know.
> > 
> > Otherwise I'll tag this thread as read and assume you'll send the dts
> > changes separately when ready :)
> > 
> 
> According to my plan the drm side changes should go into 4.9.
> 
> The commit messages and the comments may look confusing without the
> implementation, but otherwise there should be no harm in applying these
> already. The new properties in dts simply wont have any effect. On the
> other hand, not having the dts changes won't have any dramatic effect
> either. The supported colour formats will just remain in the same
> incorrect state as they have always been until the dts changes are
> there. So what ever is more convenient for you.

OK well please ping me or resend just the dts changes once the driver
changes are queued. Probably safer to wait a bit in case things still
change.

Thanks,

Tony

[PATCH v8 15/18] ARM: STi: DT: STiH407: Add uniperif reader dt nodes

[Lee Jones]

On Tue, 30 Aug 2016, Peter Griffin wrote:
> Thanks for reviewing and your very valuable feedback.
> On Tue, 30 Aug 2016, Lee Jones wrote:
> > On Fri, 26 Aug 2016, Peter Griffin wrote:
> > 
> > > This patch adds the DT node for the uniperif reader
> > > IP block found on STiH407 family silicon.
> > > 
> > > Signed-off-by: Arnaud Pouliquen 
> > > Signed-off-by: Peter Griffin 
> > > ---
> > >  arch/arm/boot/dts/stih407-family.dtsi | 26 ++
> > >  1 file changed, 26 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > index d263c96..bdddf2c 100644
> > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > @@ -956,5 +956,31 @@
> > >   st,version = <5>;
> > >   st,mode = "SPDIF";
> > >   };
> > > +
> > > + sti_uni_reader0: sti-uni-reader at 0 {
> > > + compatible = "st,sti-uni-reader";
> > > + status = "disabled";
> > 
> > I find it's normally nicer to place the status of the node at the
> > bottom, separated by a '\n'.
> 
> Ok I'll add a superflous '\n' in the next version.

Everyone loves a smart arse!

In this case I believe the '\n' to be a functional separator and not
superfluous at all.

> > > + dai-name = "Uni Reader #0 (PCM IN)";
> > 
> > Oooo, not seen something like this before.
> > 
> > If it does not already have one, it would require a DT Ack.
> 
> No idea, the driver got merged 1 year ago.
> 
> Arnaud did you get a DT ack when you merged this driver & binding?
> > 
> > > + st,version = <3>;
> > 
> > This will likely need a DT Ack too.  We usually encode this sort of
> > information in the compatible string.
> 
> See 05c1b4480e86a871b18030d6f3d532dc0ecdf38c

Well Rob's the boss.  We certainly never used to take 'device ID' or
'version' attributes.  I guess something must have changed.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 2/2] drm/virtio: add real fence context and seqno

[Gustavo Padovan]

From: Gustavo Padovan 

virtio fences were created with no fence context, which would make then
clash with an allocated fence context.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   | 1 +
 drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +-
 drivers/gpu/drm/virtio/virtgpu_kms.c   | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b18ef31..06ad923 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -75,6 +75,7 @@ typedef void (*virtio_gpu_resp_cb)(struct virtio_gpu_device 
*vgdev,
 struct virtio_gpu_fence_driver {
atomic64_t   last_seq;
uint64_t sync_seq;
+   uint64_t context;
struct list_head fences;
spinlock_t   lock;
 };
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index cf44187..f3f70fa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -89,7 +89,7 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
(*fence)->drv = drv;
(*fence)->seq = ++drv->sync_seq;
fence_init(&(*fence)->f, _fence_ops, >lock,
-  0, (*fence)->seq);
+  drv->context, (*fence)->seq);
fence_get(&(*fence)->f);
list_add_tail(&(*fence)->node, >fences);
spin_unlock_irqrestore(>lock, irq_flags);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c 
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4150873..036b0fb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -159,6 +159,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned 
long flags)
virtio_gpu_init_vq(>ctrlq, virtio_gpu_dequeue_ctrl_func);
virtio_gpu_init_vq(>cursorq, virtio_gpu_dequeue_cursor_func);

+   vgdev->fence_drv.context = fence_context_alloc(1);
spin_lock_init(>fence_drv.lock);
INIT_LIST_HEAD(>fence_drv.fences);
INIT_LIST_HEAD(>cap_cache);
-- 
2.5.5

[PATCH 1/2] drm/virtio: drop virtio_gpu_execbuffer_ioctl() wrapping

[Gustavo Padovan]

From: Gustavo Padovan 

Instead of wrapping virtio_gpu_execbuffer() to execute the ioctl
just execute it directly.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index c046903..e0613a9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -89,10 +89,16 @@ static void virtio_gpu_unref_list(struct list_head *head)
}
 }

-static int virtio_gpu_execbuffer(struct drm_device *dev,
-struct drm_virtgpu_execbuffer *exbuf,
+/*
+ * Usage of execbuffer:
+ * Relocations need to take into account the full VIRTIO_GPUDrawable size.
+ * However, the command as passed from user space must *not* contain the 
initial
+ * VIRTIO_GPUReleaseInfo struct (first XXX bytes)
+ */
+static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
 struct drm_file *drm_file)
 {
+   struct drm_virtgpu_execbuffer *exbuf = data;
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
struct drm_gem_object *gobj;
@@ -182,20 +188,6 @@ out_free:
return ret;
 }

-/*
- * Usage of execbuffer:
- * Relocations need to take into account the full VIRTIO_GPUDrawable size.
- * However, the command as passed from user space must *not* contain the 
initial
- * VIRTIO_GPUReleaseInfo struct (first XXX bytes)
- */
-static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data,
-  struct drm_file *file_priv)
-{
-   struct drm_virtgpu_execbuffer *execbuffer = data;
-   return virtio_gpu_execbuffer(dev, execbuffer, file_priv);
-}
-
-
 static int virtio_gpu_getparam_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
-- 
2.5.5

[PATCH v8 01/18] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Lee Jones]

On Tue, 30 Aug 2016, Peter Griffin wrote:
> On Tue, 30 Aug 2016, Lee Jones wrote:
> > On Fri, 26 Aug 2016, Peter Griffin wrote:
> > 
> > > slim core is used as a basis for many IPs in the STi
> > > chipsets such as fdma and demux. To avoid duplicating
> > > the elf loading code in each device driver a slim
> > > rproc driver has been created.
> > > 
> > > This driver is designed to be used by other device drivers
> > > such as fdma, or demux whose IP is based around a slim core.
> > > The device driver can call slim_rproc_alloc() to allocate
> > > a slim rproc and slim_rproc_put() when finished.
> > > 
> > > This driver takes care of ioremapping the slim
> > > registers (dmem, imem, slimcore, peripherals), whose offsets
> > > and sizes can change between IP's. It also obtains and enables
> > > any clocks used by the device. This approach avoids having
> > > a double mapping of the registers as slim_rproc does not register
> > > its own platform device. It also maps well to device tree
> > > abstraction as it allows us to have one dt node for the whole
> > > device.
> > > 
> > > All of the generic rproc elf loading code can be reused, and
> > > we provide start() stop() hooks to start and stop the slim
> > > core once the firmware has been loaded. This has been tested
> > > successfully with fdma driver.
> > 
> > Nit.  It would be good to use a constant line-wrap.
> > 
> > 'M-x post-mode' will help with this.
> 
> Can you provide the magic which makes this happen for GIT commit messages?

I tend to do it manually.  However a 3 second Google search produced
[0], which looks like it could be fun/useful.

[0] https://www.emacswiki.org/emacs/Git

[...]

> > > + * License terms:  GNU General Public License (GPL), version 2
> > 
> > Are you sure ST are okay with the shortened version of the GPL?
> 
> Do you mean the banner should be like this?
> 
>  * 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.

Yes, exactly.

[...]

> > > +/* slimcore registers */
> > 
> > What's it called? slimcore, slim core, ST Slim?
> 
> It is usually referred to as SLIM core, or SLIM CPU in the various functional
> specifications.
> 
> > 
> > Please be consistent.  Use the name from the datasheet.
> 
> OK. The datasheet isn't consistent either, so we will settle on SLIM core and
> SLIM CPU.

Perfect.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v8 01/18] remoteproc: st_slim_rproc: add a slimcore rproc driver

[Peter Griffin]

Hi Bjorn,

On Tue, 30 Aug 2016, Bjorn Andersson wrote:

> On Tue 30 Aug 05:34 PDT 2016, Lee Jones wrote:
> 
> Thanks for your review Lee.
> 
> > On Fri, 26 Aug 2016, Peter Griffin wrote:
> [..]
> > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > index 1a8bf76a..06765e0 100644
> > > --- a/drivers/remoteproc/Kconfig
> > > +++ b/drivers/remoteproc/Kconfig
> > > @@ -100,4 +100,12 @@ config ST_REMOTEPROC
> > > processor framework.
> > > This can be either built-in or a loadable module.
> > >  
> > > +config ST_SLIM_REMOTEPROC
> > > + tristate "ST Slim remoteproc support"
> > > + select REMOTEPROC
> > > + help
> > > +   Say y here to support firmware loading on IP based around
> > > +   the Slim core.
> > > +   If unsure say N.
> 
> Saw one more thing when browsing through...
> 
> As this piece of code doesn't do anything on its own and is going to be
> selected by the "function driver" I don't think this should be
> user-selectable.

Applogies, I believe you pointed this out in a previous review, but it seems to
have slipped through the net. Will fix in the next version.

Regards,

Peter.

drm/atmel-hlcdc: connector type & fbdev mode settings

[Hyung Jin Jung]

According to Atmel's guideline... 
http://www.at91.com/linux4sam/bin/view/Linux4SAM/UsingAtmelDRMDriver

the "fbdev emulation mode" could be set from kernel command line (LVDS-1:...)
however, driver register it as DRM_MODE_CONNECTOR_Unknown connector.

Actually we using sama5d3x with LVDS cable so that below patch would be correct.
But I don't know the other case such as HDMI, composite... 

Do we need to consider using DT or auto-detection??

Signed-off-by: HyungJin Jung 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b50..da97efe
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -208,7 +208,7 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
_hlcdc_panel_connector_helper_funcs);
ret = drm_connector_init(dev, >connector,
 _hlcdc_panel_connector_funcs,
-DRM_MODE_CONNECTOR_Unknown);
+DRM_MODE_CONNECTOR_LVDS);
if (ret)
goto err_encoder_cleanup;

-- 
1.9.1

BR,
Davy

Skylake graphics regression: projector failure with 4.8-rc3

[James Bottomley]

On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> We seem to have an xrandr regression with skylake now.  What's
> happening is that I can get output on to a projector, but the system 
> is losing video when I change the xrandr sessions (like going from a 
> --above b to a --same-as b).  The main screen goes blank, which is
> basically a reboot situation.  Unfortunately, I can't seem to get the
> logs out of systemd to see if there was a dump to dmesg (the system 
> was definitely responding).
> 
> I fell back to 4.6.2 which worked perfectly, so this is definitely 
> some sort of regression.  I'll be able to debug more fully when I get 
> back home from the Linux Security Summit.

I'm home now.  Unfortunately, my monitor isn't as problematic as the
projector, but by flipping between various modes and separating and
overlaying the panels with --above and --same-as (xrandr), I can
eventually get it to the point where the main LCD panel goes black and
can only be restarted by specifying a different mode.

This seems to be associated with these lines in the X

[ 14714.389] (EE) intel(0): failed to set mode: Invalid argument [22]

But the curious thing is that even if this fails with the error message
once, it may succeed a second time, so it looks to be a transient error
translation problem from the kernel driver.

I've attached the full log below.

This is only with a VGA output.  I currently don't have a HDMI dongle,
but I'm in the process of acquiring one.

James
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 31792 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160831/9456e526/attachment-0001.bin>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #119 from PhilipW  ---
I also suspect this - microcode does not fix the issue on a Powercolor r9 390
pcs+.

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

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

[Tony Lindgren]

* Jyri Sarha  [160831 06:19]:
>   ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC
> node
>   ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node
>   ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
>   ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node

If some of these dts changes are OK for me to apply separately already,
please let me know.

Otherwise I'll tag this thread as read and assume you'll send the dts
changes separately when ready :)

Regards,

Tony

[PATCH] drm/gma500: remove the process of stolen page in page fault handler.

[jiang.bi...@zte.com.cn]

Patrik Jakobsson  wrote on 2016/08/30 18:21:08:

> Patrik Jakobsson 
> 2016/08/30 18:21
>
> From
> jiang.biao2 at zte.com.cn,
> cc
> dri-devel 
> Re: [PATCH] drm/gma500: remove the process of stolen page in page fault 
> handler.
>
> On Tue, Aug 30, 2016 at 7:10 AM,   wrote:
> >
> > Direct gtt range is used in the page fault scene in current driver,
> > instead of stolen page. So no need to keep relative process.
>
> Hi
>
> Are you saying that we don't use stolen memory? Afaik stolen memory
> should be accessed through the stolen range so we do need this.
>
> -Patrik
>
As far as I can see, the stolen memory is only used by fbdev driver in gma500,
but the fbdev driver maps the stloen memory directly in psbfb_vm_fault, not
using psb_gem_fault to map the stolen memory.
The only scenario using the psb_gem_fault is the gtt range created by
psb_gem_create, which alloc the gtt range without stolen memory backed.

If I missed something, pls enlighten me.
Thanks a lot.

[PATCH 6/6] ARM: dts: gr8: Add support for the GR8 evaluation board

[Maxime Ripard]

From: Mylène Josserand 

The GR8-EVB is a small board with an NextThing GR8, an Hynix MLC NAND,
an AXP209 PMIC, USB host and OTG, an SPDIF output and a connectors for CSI,
I2S and LCD.

Signed-off-by: Mylène Josserand 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/gr8-evb.dts | 378 ++
 2 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/gr8-evb.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7dd4a07c4784..8226b0a2e178 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -734,7 +734,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-q8-tablet.dtb \
sun5i-a13-utoo-p66.dtb \
-   sun5i-r8-chip.dtb
+   sun5i-r8-chip.dtb \
+   gr8-evb.dtb
 dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
diff --git a/arch/arm/boot/dts/gr8-evb.dts b/arch/arm/boot/dts/gr8-evb.dts
new file mode 100644
index ..e334d18d7bf0
--- /dev/null
+++ b/arch/arm/boot/dts/gr8-evb.dts
@@ -0,0 +1,378 @@
+/*
+ * Copyright 2016 Free Electrons
+ * Copyright 2016 NextThing Co
+ *
+ * Mylène Josserand 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "gr8.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "NextThing GR8-EVB";
+   compatible = "nextthing,gr8-evb", "nextthing,gr8";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 1 0>;
+   enable-gpios = <_gpio 1 GPIO_ACTIVE_HIGH>;
+
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   };
+
+   panel {
+   compatible = "allwinner,sun4i-a10-sub-evb-5-lcd";
+   enable-gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
+   backlight = <>;
+   power-supply = <_vcc3v0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic at 34 {
+   reg = <0x34>;
+
+   /*
+ 

[PATCH 5/6] ARM: dts: Add NextThing GR8 dtsi

[Maxime Ripard]

From: Mylène Josserand 

The GR8 is an SoC made by Nextthing loosely based on the sun5i family.

Since it's not clear yet what we can factor out and merge with the A10s and
A13 support, let's keep it out of the sun5i.dtsi include tree. We will
figure out what can be shared when things settle down.

Signed-off-by: Mylène Josserand 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/gr8.dtsi | 1080 
 1 file changed, 1080 insertions(+)
 create mode 100644 arch/arm/boot/dts/gr8.dtsi

diff --git a/arch/arm/boot/dts/gr8.dtsi b/arch/arm/boot/dts/gr8.dtsi
new file mode 100644
index ..d21cfa3f3c14
--- /dev/null
+++ b/arch/arm/boot/dts/gr8.dtsi
@@ -0,0 +1,1080 @@
+/*
+ * Copyright 2016 Mylène Josserand
+ *
+ * Mylène Josserand 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library 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 library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "skeleton.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu at 0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a8";
+   reg = <0x0>;
+   clocks = <>;
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /*
+* This is a dummy clock, to be used as placeholder on
+* other mux clocks when a specific parent clock is not
+* yet implemented. It should be dropped when the driver
+* is complete.
+*/
+   dummy: dummy {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+   };
+
+   osc24M: clk at 01c20050 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun4i-a10-osc-clk";
+   reg = <0x01c20050 0x4>;
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   osc3M: osc3M_clk {
+   compatible = "fixed-factor-clock";
+   #clock-cells = <0>;
+   clock-div = <8>;
+   clock-mult = <1>;
+   clocks = <>;
+   clock-output-names = "osc3M";
+   };
+
+   osc32k: clk at 0 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   clock-output-names = "osc32k";
+   };
+
+   pll1: clk at 01c2 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun4i-a10-pll1-clk";
+   reg = <0x01c2 0x4>;
+   clocks = <>;
+   

[PATCH 4/6] ARM: sunxi: Support the Nextthing GR8

[Maxime Ripard]

The GR8 is an SoC made by Nextthing Co, loosely based on the sun5i family.

It has a number of new controllers compared to the A10s and A13 (SPDIF, I2S),
but some controllers missing too (Ethernet, less I2C, less UARTs).

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 MAINTAINERS | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc36b0d..3975d0a0e4c2 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  nextthing,gr8
diff --git a/MAINTAINERS b/MAINTAINERS
index 20bb1d00098c..c6a9e6fda1d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -982,6 +982,7 @@ M:  Chen-Yu Tsai 
 L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 N: sun[x456789]i
+F: arch/arm/boot/dts/gr8*

 ARM/Allwinner SoC Clock Support
 M: Emilio López 
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 95dca8c2c9ed..2e2bde271205 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -22,6 +22,7 @@ static const char * const sunxi_board_dt_compat[] = {
"allwinner,sun5i-a10s",
"allwinner,sun5i-a13",
"allwinner,sun5i-r8",
+   "nextthing,gr8",
NULL,
 };

-- 
2.9.2

[PATCH 3/6] drm/panel: simple: Add A10 EVB 5 inch panel support

[Maxime Ripard]

The A10-EVB from Allwinner comes with an unidentified panel, with the only
mark on the PCB being A10-SUB-EVB-5LCD.

Add timings to simple panel to handle it.

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

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 85143d1b9b31..be371b053aab 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -386,6 +386,29 @@ static void panel_simple_shutdown(struct device *dev)
panel_simple_disable(>base);
 }

+static const struct drm_display_mode allwinner_a10_sub_evb_5lcd_mode = {
+   .clock = 33000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 209,
+   .hsync_end = 800 + 209 + 1,
+   .htotal = 800 + 209 + 1 + 45,
+   .vdisplay = 480,
+   .vsync_start = 480 + 22,
+   .vsync_end = 480 + 22 + 1,
+   .vtotal = 480 + 22 + 1 + 22,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc allwinner_a10_sub_evb_5lcd = {
+   .modes = _a10_sub_evb_5lcd_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 110,
+   .height = 67,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 3,
.hdisplay = 800,
@@ -1515,6 +1538,9 @@ static const struct panel_desc urt_umsh_8596md_parallel = 
{

 static const struct of_device_id platform_of_match[] = {
{
+   .compatible = "allwinner,sun4i-a10-sub-evb-5-lcd",
+   .data = _a10_sub_evb_5lcd,
+   }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = _am800480r3tmqwa1h,
}, {
-- 
2.9.2

[PATCH 2/6] pinctrl: sunxi: Add GR8 controller support

[Maxime Ripard]

From: Mylène Josserand 

Just like the other member of the sunxi family, let's add a pinctrl table
for the muxing options.

Signed-off-by: Mylène Josserand 
Signed-off-by: Maxime Ripard 
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-gr8.c| 541 +
 4 files changed, 547 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-gr8.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 69617220c5d6..1685821eea41 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -23,6 +23,7 @@ Required properties:
   "allwinner,sun8i-h3-pinctrl"
   "allwinner,sun8i-h3-r-pinctrl"
   "allwinner,sun50i-a64-pinctrl"
+  "nextthing,gr8-pinctrl"

 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index aaf075b972f5..bff1ffc6f01e 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -17,6 +17,10 @@ config PINCTRL_SUN5I_A13
def_bool MACH_SUN5I
select PINCTRL_SUNXI

+config PINCTRL_GR8
+   def_bool MACH_SUN5I
+   select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN6I_A31
def_bool MACH_SUN6I
select PINCTRL_SUNXI
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 2d8b64e222e0..95f93d0561fc 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -5,6 +5,7 @@ obj-y   += pinctrl-sunxi.o
 obj-$(CONFIG_PINCTRL_SUN4I_A10)+= pinctrl-sun4i-a10.o
 obj-$(CONFIG_PINCTRL_SUN5I_A10S)   += pinctrl-sun5i-a10s.o
 obj-$(CONFIG_PINCTRL_SUN5I_A13)+= pinctrl-sun5i-a13.o
+obj-$(CONFIG_PINCTRL_GR8)  += pinctrl-gr8.o
 obj-$(CONFIG_PINCTRL_SUN6I_A31)+= pinctrl-sun6i-a31.o
 obj-$(CONFIG_PINCTRL_SUN6I_A31S)   += pinctrl-sun6i-a31s.o
 obj-$(CONFIG_PINCTRL_SUN6I_A31_R)  += pinctrl-sun6i-a31-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-gr8.c 
b/drivers/pinctrl/sunxi/pinctrl-gr8.c
new file mode 100644
index ..2904d2b7378b
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-gr8.c
@@ -0,0 +1,541 @@
+/*
+ * NextThing GR8 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 Mylene Josserand
+ *
+ * Based on pinctrl-sun5i-a13.c
+ *
+ * Mylene Josserand 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun5i_gr8_pins[] = {
+   /* Hole */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2c0")), /* SCK */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2c0")), /* SDA */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "pwm0"),
+ SUNXI_FUNCTION(0x3, "spdif"), /* DO */
+ SUNXI_FUNCTION_IRQ(0x6, 16)), /* EINT16 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "ir0"),   /* TX */
+ SUNXI_FUNCTION_IRQ(0x6, 17)), /* EINT17 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "ir0"),   /* RX */
+ SUNXI_FUNCTION_IRQ(0x6, 18)), /* EINT18 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s0"),  /* MCLK */
+ SUNXI_FUNCTION_IRQ(0x6, 19)), /* EINT19 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s0"),  /* BCLK */
+ SUNXI_FUNCTION_IRQ(0x6, 20)), /* EINT20 */
+   

[PATCH 1/6] backlight: pwm_bl: Handle gpio that can sleep

[Maxime Ripard]

Some backlight GPIOs might be connected to some i2c based expanders whose
access might sleep.

Since it's not in any critical path, use the cansleep variant of the GPIO
API.

Signed-off-by: Maxime Ripard 
---
 drivers/video/backlight/pwm_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b2b366bb0f97..12614006211e 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -55,7 +55,7 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, 
int brightness)
dev_err(pb->dev, "failed to enable power supply\n");

if (pb->enable_gpio)
-   gpiod_set_value(pb->enable_gpio, 1);
+   gpiod_set_value_cansleep(pb->enable_gpio, 1);

pwm_enable(pb->pwm);
pb->enabled = true;
@@ -70,7 +70,7 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
pwm_disable(pb->pwm);

if (pb->enable_gpio)
-   gpiod_set_value(pb->enable_gpio, 0);
+   gpiod_set_value_cansleep(pb->enable_gpio, 0);

regulator_disable(pb->power_supply);
pb->enabled = false;
-- 
2.9.2