[PATCH v2] i2c: move locking operations to their own struct

[Wolfram Sang]

On Thu, Aug 25, 2016 at 11:07:01PM +0200, Peter Rosin wrote:
> This makes it trivial to constify them, so do that.
> 
> Signed-off-by: Peter Rosin 

Applied to for-next, thanks! Thanks for the quick ack, Daniel!

-- 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/20160830/26c079d2/attachment.sig>

[PATCH] drm/nouveau: silence warnings reported during builds with W=1

[Arnd Bergmann]

On Tuesday 30 August 2016, Baoyou Xie wrote:
> We get some warnings when building kernel with W=1:
> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous 
> prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]
> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous 
> prototype for 'nv50_grctx_fill' [-Wmissing-prototypes]
> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1: warning: no previous 
> prototype for 'nv50_grctx_init' [-Wmissing-prototypes]
> 
> 
> In fact, some functions are only used in the file in which they
> are declared and don't need a declaration, but can be made static.
> and others are declared in the header files, but need to add
> missing header dependencies.
> 
> Signed-off-by: Baoyou Xie 

The patch looks very good, and this is better than one patch per file. I would 
personally
do this as two patches, as you are touching a number of files and are doing two 
separate
things here. As a rule of thumb, when the changelog text mentions two or more 
things
that the patch does, the patch should be split up so that each part does one 
thing.
After you do that, it also becomes easier to write a good subject line like 
"mark
function as static" and "add missing includes", which tells you more about the 
patch
than "silence warnings".

It's quite likely that the nouveau maintainers are less picky than I am though, 
so
if they want to apply the patch as-is

Acked-by: Arnd Bergmann 

Otherwise please split and resend in a few days, in case there are other 
comments
that need to be addressed.

Arnd

[PATCH v8 05/18] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Vinod Koul]

On Fri, Aug 26, 2016 at 03:56:40PM +0100, Peter Griffin wrote:

>  config STM32_DMA
>   bool "STMicroelectronics STM32 DMA support"
>   depends on ARCH_STM32
> @@ -567,7 +580,6 @@ config ZX_DMA
>   help
> Support the DMA engine for ZTE ZX296702 platform devices.
>  
> -

unrelated change?

> + fdev->chans = devm_kzalloc(>dev,
> +fdev->nr_channels
> +* sizeof(struct st_fdma_chan), GFP_KERNEL);

devm_kcalloc()

> + if (!fdev->chans)
> + return -ENOMEM;
> +
> + fdev->dev = >dev;
> + fdev->drvdata = drvdata;
> + platform_set_drvdata(pdev, fdev);
> +
> + fdev->irq = platform_get_irq(pdev, 0);
> + if (fdev->irq < 0) {
> + dev_err(>dev, "Failed to get irq resource\n");
> + return -EINVAL;
> + }
> +
> + ret = devm_request_irq(>dev, fdev->irq, st_fdma_irq_handler, 0,
> +dev_name(>dev), fdev);
> + if (ret) {
> + dev_err(>dev, "Failed to request irq (%d)\n", ret);
> + goto err;
> + }
> +
> + fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
> + if (!fdev->slim_rproc) {
> + ret = PTR_ERR(fdev->slim_rproc);
> + dev_err(>dev, "slim_rproc_alloc failed (%d)\n", ret);
> + goto err;
> + }
> +
> + /* Initialise list of FDMA channels */
> + INIT_LIST_HEAD(>dma_device.channels);
> + for (i = 0; i < fdev->nr_channels; i++) {
> + struct st_fdma_chan *fchan = >chans[i];
> +
> + fchan->fdev = fdev;
> + fchan->vchan.desc_free = st_fdma_free_desc;
> + vchan_init(>vchan, >dma_device);

this initialized a tasklet

> +static int st_fdma_remove(struct platform_device *pdev)
> +{
> + struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
> +
> + devm_free_irq(>dev, fdev->irq, fdev);
> + st_slim_rproc_put(fdev->slim_rproc);
> + of_dma_controller_free(pdev->dev.of_node);
> + dma_async_device_unregister(>dma_device);

and that vchan tasklet is not quisced here :(

> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
> +MODULE_AUTHOR("Ludovic.barre ");
> +MODULE_AUTHOR("Peter Griffin ");

No MODULE_ALIAS?

-- 
~Vinod

Kernel Freeze with American Megatrends BIOS

[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.

If you use the external bbswitch module, the effect is the same. I have
been trying to debug this for some time on nouveau with no luck. The
PCI/PM D3cold patches from Mika makes no difference.

Runtime resume via nouveau triggers some ACPI methods (I'll assume the
Windows 8-style PR method and take the Clevo P651 as example):

\_SB.PCI0.PEG0.PG00._ON () ->
\_SB.PCI0.PGON (0)

Then:

Method (PGON, 1, Serialized) {
PION = Arg0 // note: 0 for PG00
// ...
If ((OSYS != 0x07DF)) { /* Not Windows 2015 (Windows 10), see below */ }
Else {
LKEN (PION)
}
// this is the infinite loop: it tries to bring the PCIe link to
// full speed, but fails to do so.
While ((\_SB.PCI0.PEG0.LNKS < 0x07)) {
Local0 = 0x20
While (Local0) {
If ((\_SB.PCI0.PEG0.LNKS < 0x07)) {
Stall (0x64)
Local0--
} Else { Break }
}
If ((Local0 == Zero)) {
\_SB.PCI0.PEG0.RTLK = One
Stall (0x64)
}
}
// ...
}

Without any workaround, this piece of code is invoked:

Method (LKEN, 1, NotSerialized) {
Local3 = (CPEX & 0x0F)  // CPEX at 0x5ff9be7f and has value 000506e3
If ((Local3 == Zero)) {
/* Similar to below, but with Q0L0 -> P0L0 (register 0xBC bit 6) */
} ElseIf ((Local3 != Zero)) {
If ((Arg0 == Zero)) {
/* Enter L0 Activate state.
 * (LKDS tries to enter L2, deep-energy-saving state.) */
Q0L0 = One  // register 0x249 bit 0; \_SB.PCI0.OPG0.Q0L0 
00:01.0
Sleep (0x10)
Local0 = Zero
While (Q0L0) {
If ((Local0 > 0x04)) { Break }
Sleep (0x10)
Local0++
}
} else { /* other cases, but we are only interested in PGON(0) */ }
}
}

The acpi_osi="!Windows 2015" workaround will invoke this instead:

If ((OSYS != 0x07DF)) {
If ((PION == Zero)) {
P0AP = Zero  /* PGOF writes 3 */
P0RM = Zero  /* PGOF writes 1 */
}
If ((PBGE != Zero)) { /* Observed to be false (PBGE == 0) */
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 /* Link Disable = 0, PGOF sets 1 instead. */
P0TR = One  /* Train? (PGOF does not set this). */
TCNT = Zero
While ((TCNT < LDLY)) { /* LDLY = 300 */
If ((P0VC == Zero)) {
/* VC Negotiation Pending 0 means VC negotation is 
complete. */
Break
}
Sleep (0x10)
TCNT += 0x10 /* At most 19 iterations, sleeping for 304ms. */
}
}
}

The comments above are my own interpretation based on the acpidumps I
extracted from the machine. These notes and ACPI tables can be found at
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
https://github.com/Lekensteyn/acpi-stuff/tree/master/dsl/Clevo_P651RA

Other affected devices have similar code, differences are small:
 - No check for LNKS (avoids the infinite loop, but device is still off)
 - Instead of a check for != "Windows 2015", they check for == "Windows
   2009" or even for == "Windows 2009" || "Windows 2013" (Dell Inspiron
   7559).

The tested kernels (with bbswitch or nouveau) were Linux 4.4.0, 4.6,
4.7 (nouveau + PCI/PM + nouveau PR patches). The PCIe device is
something from the GTX 9xxM family in all cases.

I have a bunch of PCI config dumps from Windows and Linux, but there is
nothing extraordinary. Also did an ACPI trace via a Checked/Debug build
of Windows, but it just confirms that the ACPI method we use for the
Nvidia device is the correct one.

Let me know if you need more information, I would be glad to provide.

Kind regards,
Peter

> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> > Hi,
> > 
> > hope somebody can help me fix this kernel problem which affects the 
> 

[RFC] drm: implement generic firmware eviction

[David Herrmann]

Hi Rob

On Fri, Aug 26, 2016 at 2:36 PM, Rob Herring  wrote:
> On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann  
> wrote:
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evict_firmware(), and takes a flagset controlling which firmware to
>> kick out.
>>
>> This is meant to be used by drivers in their ->probe() callbacks of their
>> parent bus, before calling into drm_dev_register().
>>
>> Signed-off-by: David Herrmann 
>> ---
>> Hey
>>
>> This is just compile-tested for now. I just want to get some comments on the
>> design. I decided to drop the sysfb infrastructure and rather just use this
>> generic helper. It keeps things simple and should work just fine for all
>> reasonable use-cases.
>>
>> This will work with SimpleDRM out-of-the-box on x86.
>>
>> Architectures with dynamic simple-framebuffer devices are not supported yet. 
>> I
>> actually have no idea what the strategy there is? Can the DeviceTree people 
>> come
>> up with something? Am I supposed to call of_platform_depopulate()?
>
> If of_platform_populate was used to create the device, then yes call
> of_platform_depopulate. In this case, I think it wasn't. If
> of_platform_device_create was used, then platform_device_del.
>
>> Or
>> of_detach_node()? Or what?
>
> No. Only the struct device and its resources should need to be
> destroyed. The node should remain.
>
>> Looking at drivers/of/{platform,dynamic}.c, I cannot see how this is 
>> supposed to
>> work at all. Who protects platform_device_del() from being called in 
>> parallel?
>
> Not sure. In parallel to what? On most systems, nodes never go away
> and on those that do it is only a few things that get hotplugged.
> That's changing with DT overlays now, so there certainly could be some
> issues.

Two tasks calling platform_device_del() in parallel on the same device
will not work. Meaning, calling of_platform_device_destroy() in
parallel does not work either. Same for of_platform_depopulate(). Same
for of_node_detach().

Sure, all those functions are not meant to be called in parallel by
multiple tasks. They are rather meant to have a single holder which
preferably is the one instantiating and destroying the
node/device/foobar. But the framebuffer eviction code somehow needs to
trigger the removal, and thus needs some hook, that can be called in
parallel by any driver that is loaded.

I can make sure the simple-framebuffer eviction code is locked
properly. That'll work, for now. But if someone ends up providing
simple-framebuffer devices via overlays or any other dynamic
mechanism, they will race the removal. And it will be completely
non-obvious to them. I really don't want to be responsible to have
submitted that code. If anyone cares for proper device hand-over on
ARM, please come up with an idea to fix it. Otherwise, I will just
limit the simpledrm code to x86.

IOW the device handover code somehow needs to know who was responsible
for the instantiation of the simple-framebuffer device, so it can tell
them to remove it again. On x86 there is only one place where those
can be instantiated. But on OF-based systems, it can be dynamically
instantiated in many places right now.

Thanks
David

Kernel Freeze with American Megatrends BIOS

[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).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

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

[Chen-Yu Tsai]

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

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;
+
drm_encoder_helper_add(>encoder,
   _rgb_enc_helper_funcs);
ret = drm_encoder_init(drm,
@@ -266,7 +267,7 @@ int sun4i_rgb_init(struct drm_device *drm)
}
}

-   if (!IS_ERR(encoder->bridge)) {
+   if (encoder->bridge) {
encoder->bridge->encoder = >encoder;

ret = drm_bridge_attach(drm, encoder->bridge);
-- 
2.9.3

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

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.


Am 30.08.2016 um 19:43 schrieb Ilia Mirkin:
> On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer
>  wrote:
>> My conclusion:
>>
>> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>>I would love to help here.
> 
> nouveau + bbswitch will always end in tears. You're going behind the
> driver's back and messing around with state it believes it is
> managing. What if you just use nouveau and let it auto-power-off the
> GPU like it's designed to, with v4.8-rc?
> 
>   -ilia
> 

[Bug 97166] lockup during gameplay of Batman series of games

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

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

--- Comment #11 from farmboy0+freedesktop at googlemail.com ---
Created attachment 126123
  --> https://bugs.freedesktop.org/attachment.cgi?id=126123=edit
ddebug info

-- 
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/20160830/6ae579b2/attachment.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 #2 from Luke A. Guest  ---
(In reply to Vedran Miletić from comment #1)
> It's a long shot, but does
> https://lists.freedesktop.org/archives/mesa-dev/2016-August/127318.html fix
> it?

I can confirm on R9 390, this patch stops the GPU page faults in dmesg log, but
I'm still getting major corruption when recording the screen in obs or ffmeg
https://youtu.be/pFqhIGYLbDM

-- 
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/20160830/2ca0ed53/attachment.html>

[PATCH v2] drm/nouveau/gr: mark gm107_grctx_generate_tpcid() static

[Baoyou Xie]

On 30 August 2016 at 00:01, Sean Paul  wrote:

> On Mon, Aug 29, 2016 at 9:02 AM, Baoyou Xie  wrote:
> > We get 1 warning when build kernel with W=1:
> > drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no
> previous prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
> >
> > In fact, this function is only used in the file in which it is
> > declared and don't need a declaration, but can be made static.
> > so this patch marks this function with 'static'.
> >
>
> It would make things a lot easier if you either consolidated all of
> these static changes into one patch, or released them as a series.
>
>
Do you mean that I need to consolidate all of them into one patch this
time? or next time?


> Sean
>
>
> > Signed-off-by: Baoyou Xie 
> > ---
> >  drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> > index 6d3c501..4c4b5ab 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
> > @@ -933,7 +933,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx
> *info)
> > }
> >  }
> >
> > -void
> > +static void
> >  gm107_grctx_generate_tpcid(struct gf100_gr *gr)
> >  {
> > struct nvkm_device *device = gr->base.engine.subdev.device;
> > --
> > 2.7.4
> >
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160830/624f87e7/attachment.html>

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel.
The result is the same. There is no difference if bbswitch of acpi_call
is used. However I noticed following:

1. The nouveau driver is broken in both kernel version and is responsible
   for the freezes while gathering power state information with bbswitch.
   Sometimes while shutting the system down, everything except the LCD
   screen is switched off. This only happens with nouveau.
   I noticed following error log messages:

   kernel: nouveau :01:00.0: fb: 6144 MiB GDDR5
   kernel: nouveau :01:00.0: priv: HUB0: 10ecc0  (1e40822c)
   kernel: nouveau :01:00.0: DRM: VRAM: 6144 MiB
   kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB
   kernel: nouveau :01:00.0: DRM: Pointer to TMDS table invalid
   kernel: nouveau :01:00.0: DRM: DCB version 4.1
   kernel: nouveau :01:00.0: DRM: Pointer to flat panel table invalid

2. -> Boot with nouveau module loaded
   -> switch off the discrete GPU with bbswitch or acpi_call
   -> start X11
   -> obtaining power state with bbswitch freezes the system
   -> or working with the system for some minutes freezes the system

3. -> Boot with nouveau module blacklisted
   -> switch off the discrete GPU
   -> start X11
   -> system immediately freezes

4. -> Boot with nouveau module blacklisted
   -> switch off the discrete GPU
   -> start Wayland
   -> system runs - Note: I tried this for couple of days with 4.6 and 4.7 
mainline
  and the system freezed randomly after some time.
  However I have to test if this is still present with 
4.7.2
  and 4.8 mainline. Right now it seams to be fine.
   -> running Xwayland (does not depend on the GPU power state) kills 
performance!
  the system freezes for several seconds...
  So working with Wayland is also no solution.

My conclusion:

1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
   I would love to help here.

2. X11 is just broken and is not capable to start the graphical session
   if the nvidia GPU is not handled by any video driver (kernel module).
   Even forcing X11 to ignore the discrete GPU doesn't help.

   Setting the command line arguments to:

 acpi_osi=! acpi_osi="Windows 2009"

   fixes the issues with X11 but other things break...
   What the hell is going on?! :/

Am 30.08.2016 um 17:48 schrieb Emil Velikov:
> On 30 August 2016 at 16:25, Roland Singer  
> wrote:
>> I tried these scenarios:
>>
>> 1. Booted the system without the bbswitch module. The nouveau module
>>was loaded and is responsible for the power management of the GPU.
>>The graphical session freezes after some minutes...
>>
>> 2. Booted the system without bbswitch and with nouveau blacklisted.
>>Manually loaded bbswitch to switch off the discrete GPU.
>>Same freeze after a while or by explicitly obtaining the GPU state.
>>
>> Is there a possibility to switch off the discrete card without bbswitch?
>> If this is possible, then I could test this without nouveau and bbswitch
>> at all. If the system hangs, then it is not the video driver nor bbswitch.
>>
> As Ilia mentioned acpi_call should do it. You can also check with the
> nouveau/bbwswitch code to see which ones they use in your case and
> bash it manually. It might be that the 'wrong one' gets used thus
> things going horribly wrong.
> 
> Regards,
> Emil
> 

Kernel Freeze with American Megatrends BIOS

[Emil Velikov]

On 30 August 2016 at 19:09, Emil Velikov  wrote:
> On 30 August 2016 at 18:37, Roland Singer  
> wrote:
>> I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel.
>> The result is the same. There is no difference if bbswitch of acpi_call
>> is used. However I noticed following:
>>
>> 1. The nouveau driver is broken in both kernel version and is responsible
>>for the freezes while gathering power state information with bbswitch.
>>Sometimes while shutting the system down, everything except the LCD
>>screen is switched off. This only happens with nouveau.
>>I noticed following error log messages:
>>
> I second Ilia here. Using bbswitch in conjunction with any driver (be
> that nouveau or the proprietary one) is a bad idea.
>
>>kernel: nouveau :01:00.0: fb: 6144 MiB GDDR5
>>kernel: nouveau :01:00.0: priv: HUB0: 10ecc0  (1e40822c)
>>kernel: nouveau :01:00.0: DRM: VRAM: 6144 MiB
>>kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB
>>kernel: nouveau :01:00.0: DRM: Pointer to TMDS table invalid
>>kernel: nouveau :01:00.0: DRM: DCB version 4.1
>>kernel: nouveau :01:00.0: DRM: Pointer to flat panel table invalid
>>
>> 2. -> Boot with nouveau module loaded
>>-> switch off the discrete GPU with bbswitch or acpi_call
>>-> start X11
>>-> obtaining power state with bbswitch freezes the system
>>-> or working with the system for some minutes freezes the system
>>
> (If Ilia's suggestions does not help) Confirm if the freeze is due
> to/as the GPU is powered on or off.
>
>> 3. -> Boot with nouveau module blacklisted
>>-> switch off the discrete GPU
>>-> start X11
>>-> system immediately freezes
>>
> It's perfectly possible that the discrete GPU is set as boot one and X
> goes angry since there's no driver/way to bring it up.
>
>> 4. -> Boot with nouveau module blacklisted
>>-> switch off the discrete GPU
>>-> start Wayland
>>-> system runs - Note: I tried this for couple of days with 4.6 and 4.7 
>> mainline
>>   and the system freezed randomly after some time.
>>   However I have to test if this is still present 
>> with 4.7.2
>>   and 4.8 mainline. Right now it seams to be fine.
>>-> running Xwayland (does not depend on the GPU power state) kills 
>> performance!
>>   the system freezes for several seconds...
>>   So working with Wayland is also no solution.
>>
>> My conclusion:
>>
>> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>>I would love to help here.
>>
>> 2. X11 is just broken and is not capable to start the graphical session
>>if the nvidia GPU is not handled by any video driver (kernel module).
>>Even forcing X11 to ignore the discrete GPU doesn't help.
>>
> Out of curiosity: how did you force X to ignore the device ?
>
>>Setting the command line arguments to:
>>
>>  acpi_osi=! acpi_osi="Windows 2009"
>>
>>fixes the issues with X11 but other things break...
>>What the hell is going on?! :/
>>
> You can check if it's the boot_vga assumption with
>
[Sorry about that] ...
cat /sys/class/drm/card*/device/{boot_vga,vendor}

If the output changes them my assumption holds true.
-Emil

Kernel Freeze with American Megatrends BIOS

[Emil Velikov]

On 30 August 2016 at 18:37, Roland Singer  
wrote:
> I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel.
> The result is the same. There is no difference if bbswitch of acpi_call
> is used. However I noticed following:
>
> 1. The nouveau driver is broken in both kernel version and is responsible
>for the freezes while gathering power state information with bbswitch.
>Sometimes while shutting the system down, everything except the LCD
>screen is switched off. This only happens with nouveau.
>I noticed following error log messages:
>
I second Ilia here. Using bbswitch in conjunction with any driver (be
that nouveau or the proprietary one) is a bad idea.

>kernel: nouveau :01:00.0: fb: 6144 MiB GDDR5
>kernel: nouveau :01:00.0: priv: HUB0: 10ecc0  (1e40822c)
>kernel: nouveau :01:00.0: DRM: VRAM: 6144 MiB
>kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB
>kernel: nouveau :01:00.0: DRM: Pointer to TMDS table invalid
>kernel: nouveau :01:00.0: DRM: DCB version 4.1
>kernel: nouveau :01:00.0: DRM: Pointer to flat panel table invalid
>
> 2. -> Boot with nouveau module loaded
>-> switch off the discrete GPU with bbswitch or acpi_call
>-> start X11
>-> obtaining power state with bbswitch freezes the system
>-> or working with the system for some minutes freezes the system
>
(If Ilia's suggestions does not help) Confirm if the freeze is due
to/as the GPU is powered on or off.

> 3. -> Boot with nouveau module blacklisted
>-> switch off the discrete GPU
>-> start X11
>-> system immediately freezes
>
It's perfectly possible that the discrete GPU is set as boot one and X
goes angry since there's no driver/way to bring it up.

> 4. -> Boot with nouveau module blacklisted
>-> switch off the discrete GPU
>-> start Wayland
>-> system runs - Note: I tried this for couple of days with 4.6 and 4.7 
> mainline
>   and the system freezed randomly after some time.
>   However I have to test if this is still present 
> with 4.7.2
>   and 4.8 mainline. Right now it seams to be fine.
>-> running Xwayland (does not depend on the GPU power state) kills 
> performance!
>   the system freezes for several seconds...
>   So working with Wayland is also no solution.
>
> My conclusion:
>
> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>I would love to help here.
>
> 2. X11 is just broken and is not capable to start the graphical session
>if the nvidia GPU is not handled by any video driver (kernel module).
>Even forcing X11 to ignore the discrete GPU doesn't help.
>
Out of curiosity: how did you force X to ignore the device ?

>Setting the command line arguments to:
>
>  acpi_osi=! acpi_osi="Windows 2009"
>
>fixes the issues with X11 but other things break...
>What the hell is going on?! :/
>
You can check if it's the boot_vga assumption with

Check wh

You're a victum of the Windows specific fun (quirks?) in

> Am 30.08.2016 um 17:48 schrieb Emil Velikov:
>> On 30 August 2016 at 16:25, Roland Singer  
>> wrote:
>>> I tried these scenarios:
>>>
>>> 1. Booted the system without the bbswitch module. The nouveau module
>>>was loaded and is responsible for the power management of the GPU.
>>>The graphical session freezes after some minutes...
>>>
>>> 2. Booted the system without bbswitch and with nouveau blacklisted.
>>>Manually loaded bbswitch to switch off the discrete GPU.
>>>Same freeze after a while or by explicitly obtaining the GPU state.
>>>
>>> Is there a possibility to switch off the discrete card without bbswitch?
>>> If this is possible, then I could test this without nouveau and bbswitch
>>> at all. If the system hangs, then it is not the video driver nor bbswitch.
>>>
>> As Ilia mentioned acpi_call should do it. You can also check with the
>> nouveau/bbwswitch code to see which ones they use in your case and
>> bash it manually. It might be that the 'wrong one' gets used thus
>> things going horribly wrong.
>>
>> Regards,
>> Emil
>>
>

[Bug 93167] radeon/drm fails to restore graphics mode after s2disk

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

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

Elmar Stellnberger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Elmar Stellnberger  ---
likely an issue of the mainboard manufacturer as this works with the same card
and another motherboard; closing.

-- 
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/20160830/1e2250c1/attachment-0001.html>

[RFC] drm: implement generic firmware eviction

[Rob Herring]

On Tue, Aug 30, 2016 at 4:12 PM, David Herrmann  
wrote:
> Hi
>
> On Tue, Aug 30, 2016 at 10:58 PM, Rob Herring  wrote:
>> On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann  
>> wrote:
>>> Sure, all those functions are not meant to be called in parallel by
>>> multiple tasks. They are rather meant to have a single holder which
>>> preferably is the one instantiating and destroying the
>>> node/device/foobar. But the framebuffer eviction code somehow needs to
>>> trigger the removal, and thus needs some hook, that can be called in
>>> parallel by any driver that is loaded.
>>>
>>> I can make sure the simple-framebuffer eviction code is locked
>>> properly. That'll work, for now. But if someone ends up providing
>>> simple-framebuffer devices via overlays or any other dynamic
>>> mechanism, they will race the removal.
>>
>> No doubt someone will come up with some usecase wanting to do that,
>> but IMO that is not a supported usecase and should not be.
>> simple-framebuffer is for providing a firmware setup framebuffer.
>
> Sure. Any sensible simple-framebuffer use would follow what we have
> now. But it feels wrong to me that if some node is added that just
> happens to have "simple-framebuffer" as name, suddenly things will go
> wrong. I mean, yeah, DT is not a userspace API, but I still would like
> the code to catch misuses rather than fail. It is an API after all. Or
> is that being overly pedantic?

The kernel could blow up in all sorts of interesting ways if random
nodes were created. IMO, it is not the kernel's job to be a DT
validator. If it is, it is doing a horrible job. And don't get me
wrong, we do need something to do that. That is all orthogonal to
dynamic devices and the issues there.

>>> And it will be completely
>>> non-obvious to them. I really don't want to be responsible to have
>>> submitted that code. If anyone cares for proper device hand-over on
>>> ARM, please come up with an idea to fix it. Otherwise, I will just
>>> limit the simpledrm code to x86.
>>>
>>> IOW the device handover code somehow needs to know who was responsible
>>> for the instantiation of the simple-framebuffer device, so it can tell
>>> them to remove it again. On x86 there is only one place where those
>>> can be instantiated. But on OF-based systems, it can be dynamically
>>> instantiated in many places right now.
>>
>> What do you mean by all over the place? It is only in simplefb_init
>> ATM. I haven't looked at what simpledrm is doing, but we can move the
>> device creation to of_platform_default_populate_init if we need a
>> single spot.
>
> Currently I see at least 3 paths that might add such nodes:
>
>  - of_platform_populate()

If we assume the node is only under chosen, then that would require a
call to of_platform_populate with /chosen as the root which shouldn't
happen. More generally the assumption is of_platform_populate is only
called once from for the root node and only on sub-trees by the driver
of sub-tree's root device.

>  - of_node_attach() (via the notifier)

A node getting attached would be harmless. Nothing really would happen
until a handler calls of_platform_populate. So this is the same as the
1st case.

>  - simplefb_init()

Actually, I'd prefer to move it out of there and into the core. I
don't think drivers should look at /chosen and only the core and arch
code should. Of course, the only enforcing of that is policy. For
overlays though, there's been some discussion on limiting where
overlays can be applied.

> Should I just ignore anything but simplefb_init()? I understand that
> it's the only one used by normal code-paths, but isn't it kinda ugly
> to silently introduce race conditions if a node just happens to be
> introduced via one of the other methods? Or are errors in the DT not
> meant to be caught?

In general there's no limit to how wrong a DT could be. I could write
a DT that causes every DT enabled driver in the kernel to probe (that
would be an interesting test case). The kernel is limited in knowing
what is correct, and the whole point of DT is to move that information
out of the kernel.  This is case is just one compatible string out of
thousands and location in the tree is just one thing to check.

This is a major reason why there is not yet a userspace interface for
applying DT overlays as who knows what random crap could be in the DT.
We're nervous about what could happen from frying h/w to creating
security holes. Evidently the ACPI folks were not so nervous and added
an interface.

Rob

[PATCH 2/2] libdrm: add etnaviv tests

[Daniel Vetter]

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

The generic kms tests in igt should run perfectly fine on radeon. Not
that I've tried yet (I dont have a radeon throw-away box for testing).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

I tried these scenarios:

1. Booted the system without the bbswitch module. The nouveau module
   was loaded and is responsible for the power management of the GPU.
   The graphical session freezes after some minutes...

2. Booted the system without bbswitch and with nouveau blacklisted.
   Manually loaded bbswitch to switch off the discrete GPU.
   Same freeze after a while or by explicitly obtaining the GPU state.

Is there a possibility to switch off the discrete card without bbswitch?
If this is possible, then I could test this without nouveau and bbswitch
at all. If the system hangs, then it is not the video driver nor bbswitch.

Am 30.08.2016 um 16:08 schrieb Emil Velikov:
> On 30 August 2016 at 14:06, Bjorn Helgaas  wrote:
>> On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
>>> Thanks for pointing it out.
>>>
>>> Yeah that's right. The system will hang randomly a few minutes later,
>>> because some certain actions in the graphical user session will trigger
>>> the freeze.
>>>
>>> I had a look at the function body of pci_read_config_dword:
>>>
>>>   #define PCI_OP_READ(size, type, len) \
>>>   int pci_bus_read_config_##size \
>>>   (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
>>>   {   \
>>>   int res;\
>>>   unsigned long flags;\
>>>   u32 data = 0;   \
>>>   if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
>>>   raw_spin_lock_irqsave(_lock, flags);\
>>>   res = bus->ops->read(bus, devfn, pos, len, );  \
>>>   *value = (type)data;\
>>>   raw_spin_unlock_irqrestore(_lock, flags);   \
>>>   return res; \
>>>   }
>>>
>>> I guess, that bus->ops->read(...) might be the trigger.
>>> Any hints how to continue debugging?
>>
>> It's not likely that the problem is in the bus->ops->read() path.  That
>> is used by every device driver, so a problem there would cause more
>> serious problems than what you're seeing.
>>
>> My guess would be some problem in the video driver or the bbswitch
>> thing.
>>
> FWIW I'm inclined to call it a bbswitch bug. It can (and does when
> needed) power off the dedicated GPU.
> 
> Depending on the platform different methods are used:
> 
> Sometimes the GPU driver will get 0x (or similar) when trying
> to read from the device mmio space. While one can say that the driver
> should attribute for this, IMHO it's a bad idea to have two drivers
> controlling the same hardware, let alone without any coordination
> between them.
> 
> IIRC in some cases the device can disappear from the PCI bus (not 100%
> sure this one). In which case a simple read can lead to a wide range
> of fireworks.
> 
> Disclaimer: it's been a while since I've looked into bbswitch so
> things might have changed/improved.
> 
> Regards,
> Emil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH] drm/sun4i: rgb: add missing calls to drm_panel_{prepare, unprepare}

[Jonathan Liu]

If the enable-gpios property of a simple panel in device tree is set,
the GPIO is not toggled on/off because of missing calls to
drm_panel_prepare and drm_panel_unprepare.

Signed-off-by: Jonathan Liu 
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f5bbac6..d6943e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -151,6 +151,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder 
*encoder)

DRM_DEBUG_DRIVER("Enabling RGB output\n");

+   drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
sun4i_tcon_channel_enable(tcon, 0);
 }
@@ -165,6 +166,7 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder 
*encoder)

sun4i_tcon_channel_disable(tcon, 0);
drm_panel_disable(tcon->panel);
+   drm_panel_unprepare(tcon->panel);
 }

 static void sun4i_rgb_encoder_mode_set(struct drm_encoder *encoder,
-- 
2.9.3

Kernel Freeze with American Megatrends BIOS

[Emil Velikov]

On 30 August 2016 at 16:25, Roland Singer  
wrote:
> I tried these scenarios:
>
> 1. Booted the system without the bbswitch module. The nouveau module
>was loaded and is responsible for the power management of the GPU.
>The graphical session freezes after some minutes...
>
> 2. Booted the system without bbswitch and with nouveau blacklisted.
>Manually loaded bbswitch to switch off the discrete GPU.
>Same freeze after a while or by explicitly obtaining the GPU state.
>
> Is there a possibility to switch off the discrete card without bbswitch?
> If this is possible, then I could test this without nouveau and bbswitch
> at all. If the system hangs, then it is not the video driver nor bbswitch.
>
As Ilia mentioned acpi_call should do it. You can also check with the
nouveau/bbwswitch code to see which ones they use in your case and
bash it manually. It might be that the 'wrong one' gets used thus
things going horribly wrong.

Regards,
Emil

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

[Peter Griffin]

Hi Lee,

Thanks for reviewing.

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?

> 
> > Signed-off-by: Peter Griffin 
> > ---
> >  drivers/remoteproc/Kconfig   |   8 +
> >  drivers/remoteproc/Makefile  |   1 +
> >  drivers/remoteproc/st_slim_rproc.c   | 364 
> > +++
> >  include/linux/remoteproc/st_slim_rproc.h |  53 +
> >  4 files changed, 426 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > 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.
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+= 
> > da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c 
> > b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 000..f4bf2d7
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * st_slim_rproc.c
> 
> These serve no purpose and have a habit of becoming out-of-date.
> Please remove it and replace with a nice succinct description
> instead.

OK will fix.
> 
> > + * Copyright (C) 2016 STMicroelectronics
> 
> Nit: '\n' here.

Will fix. 
> 
> > + * Author: Peter Griffin 
> 
> Nit: '\n' here.

Will fix.

> 
> > + * 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.

As I'm not aware of a shortened version of the GPV v2 license.

> 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "remoteproc_internal.h"
> > +
> > +/* 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.

> 
> > +#define SLIM_ID_OFST   0x0
> > +#define SLIM_VER_OFST  0x4
> > +
> > +#define SLIM_EN_OFST   0x8
> > +#define SLIM_EN_RUNBIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST 0xC
> > +#define SLIM_CLK_GATE_DIS  BIT(0)
> > +#define SLIM_CLK_GATE_RESETBIT(2)
> > +
> > +#define 

[PATCH] drm/sun4i: rgb: add missing calls to drm_panel_{prepare, unprepare}

[Emil Velikov]

On 30 August 2016 at 07:55, Jonathan Liu  wrote:
> If the enable-gpios property of a simple panel in device tree is set,
> the GPIO is not toggled on/off because of missing calls to
> drm_panel_prepare and drm_panel_unprepare.
>
> Signed-off-by: Jonathan Liu 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index f5bbac6..d6943e9 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -151,6 +151,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder 
> *encoder)
>
> DRM_DEBUG_DRIVER("Enabling RGB output\n");
>
> +   drm_panel_prepare(tcon->panel);
> drm_panel_enable(tcon->panel);
IMHO it's worth having a _prepare_enable, and alike on the dtor side,
similar to clk. The clk helper attributes when .enable() fails, which
is a good idea. Looking on the drm side - all the users of such
helper(s) don't bother checking neither .prepare or .enable. So
updating that alongside the introduction would be a great move ;-)

Just an idea about another small task.
Emil

P.S. Skimming through v4.7 mediatek (mtk) driver looks a bit
assymetrical wrt using the drm_panel API. Worth checking if things
have improved with later versions ?

[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo

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

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

--- Comment #9 from Thomas J. Moore  ---
Just thought I'd mention that 4.8-rc2 and 4.8-rc3 are still worse off than
before, even though both have changes for amdgpu power management (i.e., no fix
for this, and X still won't start any more, although I suppose maybe the later
is because I'd need a matching update to xf86-video-amdgpu I'm not aware of). 
I won't report any further lack of progress.

-- 
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/20160830/65c9d2f4/attachment.html>

[RFC] drm: implement generic firmware eviction

[Rob Herring]

On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann  
wrote:
> Hi Rob
>
> On Fri, Aug 26, 2016 at 2:36 PM, Rob Herring  wrote:
>> On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann  
>> wrote:
>>> Provide a generic DRM helper that evicts all conflicting firmware
>>> framebuffers, devices, and drivers. The new helper is called
>>> drm_evict_firmware(), and takes a flagset controlling which firmware to
>>> kick out.
>>>
>>> This is meant to be used by drivers in their ->probe() callbacks of their
>>> parent bus, before calling into drm_dev_register().
>>>
>>> Signed-off-by: David Herrmann 
>>> ---
>>> Hey
>>>
>>> This is just compile-tested for now. I just want to get some comments on the
>>> design. I decided to drop the sysfb infrastructure and rather just use this
>>> generic helper. It keeps things simple and should work just fine for all
>>> reasonable use-cases.
>>>
>>> This will work with SimpleDRM out-of-the-box on x86.
>>>
>>> Architectures with dynamic simple-framebuffer devices are not supported 
>>> yet. I
>>> actually have no idea what the strategy there is? Can the DeviceTree people 
>>> come
>>> up with something? Am I supposed to call of_platform_depopulate()?
>>
>> If of_platform_populate was used to create the device, then yes call
>> of_platform_depopulate. In this case, I think it wasn't. If
>> of_platform_device_create was used, then platform_device_del.
>>
>>> Or
>>> of_detach_node()? Or what?
>>
>> No. Only the struct device and its resources should need to be
>> destroyed. The node should remain.
>>
>>> Looking at drivers/of/{platform,dynamic}.c, I cannot see how this is 
>>> supposed to
>>> work at all. Who protects platform_device_del() from being called in 
>>> parallel?
>>
>> Not sure. In parallel to what? On most systems, nodes never go away
>> and on those that do it is only a few things that get hotplugged.
>> That's changing with DT overlays now, so there certainly could be some
>> issues.
>
> Two tasks calling platform_device_del() in parallel on the same device
> will not work. Meaning, calling of_platform_device_destroy() in
> parallel does not work either. Same for of_platform_depopulate(). Same
> for of_node_detach().

Changes to DT nodes and struct device's are completely separate from a
DT core perspective ATM. A caller is responsible adding devices when
nodes are added, removing the devices, then removing the nodes. The
only overlays currently supported require a driver to load them and
handle any transitions.

DT is still far from dynamic in the sense that any random node can come and go.

> Sure, all those functions are not meant to be called in parallel by
> multiple tasks. They are rather meant to have a single holder which
> preferably is the one instantiating and destroying the
> node/device/foobar. But the framebuffer eviction code somehow needs to
> trigger the removal, and thus needs some hook, that can be called in
> parallel by any driver that is loaded.
>
> I can make sure the simple-framebuffer eviction code is locked
> properly. That'll work, for now. But if someone ends up providing
> simple-framebuffer devices via overlays or any other dynamic
> mechanism, they will race the removal.

No doubt someone will come up with some usecase wanting to do that,
but IMO that is not a supported usecase and should not be.
simple-framebuffer is for providing a firmware setup framebuffer.

> And it will be completely
> non-obvious to them. I really don't want to be responsible to have
> submitted that code. If anyone cares for proper device hand-over on
> ARM, please come up with an idea to fix it. Otherwise, I will just
> limit the simpledrm code to x86.
>
> IOW the device handover code somehow needs to know who was responsible
> for the instantiation of the simple-framebuffer device, so it can tell
> them to remove it again. On x86 there is only one place where those
> can be instantiated. But on OF-based systems, it can be dynamically
> instantiated in many places right now.

What do you mean by all over the place? It is only in simplefb_init
ATM. I haven't looked at what simpledrm is doing, but we can move the
device creation to of_platform_default_populate_init if we need a
single spot.

Rob

[PATCH v2 2/7] drm/tilcdc: Add blue-and-red-crossed devicetree property

[Jyri Sarha]

On 08/30/16 15:46, Tomi Valkeinen wrote:
> 
> 
> On 26/08/16 20:44, Jyri Sarha wrote:
>> On 08/26/16 15:51, Rob Herring wrote:
 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> @@ -17,6 +17,8 @@ Optional properties:
> the lcd controller.
>   - max-pixelclock: The maximum pixel clock that can be supported
> by the lcd controller in KHz.
> + - blue-and-red-crossed: Boolean property, set this of blue and red wires
> +   for LCD_DATA are crossed for 24-bit RGB support (and 16-bit BGR 
> mode). [1]
>>> Doesn't this need to be blue-and-red-straight for compatibility?
>>>
>>
>> There is no way to be backward compatible with all am3 based devices.
> 
> Hmm, I guess it would be possible to have three options:
> 
> - 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
> 

Yes, that would be backward compatible and probably the best approach.
As this way all applications would still run, even if the colours are
wrong (as they have always been).

I'll do that if no one suggests otherwise.

BR,
Jyri

[PATCH v2 2/7] drm/tilcdc: Add blue-and-red-crossed devicetree property

[Tomi Valkeinen]

On 26/08/16 20:44, Jyri Sarha wrote:
> On 08/26/16 15:51, Rob Herring wrote:
>>> --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
>>>> +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
>>>> @@ -17,6 +17,8 @@ Optional properties:
>>>> the lcd controller.
>>>>   - max-pixelclock: The maximum pixel clock that can be supported
>>>> by the lcd controller in KHz.
>>>> + - blue-and-red-crossed: Boolean property, set this of blue and red wires
>>>> +   for LCD_DATA are crossed for 24-bit RGB support (and 16-bit BGR mode). 
>>>> [1]
>> Doesn't this need to be blue-and-red-straight for compatibility?
>>
> 
> There is no way to be backward compatible with all am3 based devices.

Hmm, I guess it would be possible to have three options:

- 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

 Tomi

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

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

[Peter Griffin]

Hi Lee,

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.

>  There isn't a functional difference
> admittedly, but it would be my preference, since it's not describing
> the device per se.

Will change to your preference in the next version.

> 
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   reg = <0x8D83000 0x158>;
> 
> We usually use lower-case for the address.

Will fix.

> 
> Since this has a 'reg' property, the '0' in the node name does not
> look appropriate.

Will fix.
> 
> > +   interrupts = ;
> > +   dmas = < 5 0 1>;
> > +   dma-names = "rx";
> > +   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
> 
> > +   };
> > +
> > +   sti_uni_reader1: sti-uni-reader at 1 {
> > +   compatible = "st,sti-uni-reader";
> > +   status = "disabled";
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   reg = <0x8D84000 0x158>;
> > +   interrupts = ;
> > +   dmas = < 6 0 1>;
> > +   dma-names = "rx";
> > +   dai-name = "Uni Reader #1 (HDMI RX)";
> > +   st,version = <3>;
> > +   };
> 
> All as above.
> 
> > };
> >  };
> 

Regards,

Peter.

Kernel Freeze with American Megatrends BIOS

[Emil Velikov]

On 30 August 2016 at 14:06, Bjorn Helgaas  wrote:
> On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
>> Thanks for pointing it out.
>>
>> Yeah that's right. The system will hang randomly a few minutes later,
>> because some certain actions in the graphical user session will trigger
>> the freeze.
>>
>> I had a look at the function body of pci_read_config_dword:
>>
>>   #define PCI_OP_READ(size, type, len) \
>>   int pci_bus_read_config_##size \
>>   (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
>>   {   \
>>   int res;\
>>   unsigned long flags;\
>>   u32 data = 0;   \
>>   if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
>>   raw_spin_lock_irqsave(_lock, flags);\
>>   res = bus->ops->read(bus, devfn, pos, len, );  \
>>   *value = (type)data;\
>>   raw_spin_unlock_irqrestore(_lock, flags);   \
>>   return res; \
>>   }
>>
>> I guess, that bus->ops->read(...) might be the trigger.
>> Any hints how to continue debugging?
>
> It's not likely that the problem is in the bus->ops->read() path.  That
> is used by every device driver, so a problem there would cause more
> serious problems than what you're seeing.
>
> My guess would be some problem in the video driver or the bbswitch
> thing.
>
FWIW I'm inclined to call it a bbswitch bug. It can (and does when
needed) power off the dedicated GPU.

Depending on the platform different methods are used:

Sometimes the GPU driver will get 0x (or similar) when trying
to read from the device mmio space. While one can say that the driver
should attribute for this, IMHO it's a bad idea to have two drivers
controlling the same hardware, let alone without any coordination
between them.

IIRC in some cases the device can disappear from the PCI bus (not 100%
sure this one). In which case a simple read can lead to a wide range
of fireworks.

Disclaimer: it's been a while since I've looked into bbswitch so
things might have changed/improved.

Regards,
Emil

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

[Maxime Ripard]

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.

>   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.

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/20160830/9deb77a5/attachment.sig>

[PATCH] drm/sun4i: rgb: add missing calls to drm_panel_{prepare,unprepare}

[Maxime Ripard]

Hi,

On Tue, Aug 30, 2016 at 04:55:00PM +1000, Jonathan Liu wrote:
> If the enable-gpios property of a simple panel in device tree is set,
> the GPIO is not toggled on/off because of missing calls to
> drm_panel_prepare and drm_panel_unprepare.
> 
> Signed-off-by: Jonathan Liu 

This was not applying properly, but I merged it.

Please make sure that it applies on top of the current next branch.

Good catch, 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/20160830/f006f93f/attachment.sig>

[RFC 0/2] New feature: Framebuffer processors

[Inki Dae]

2016년 08월 25일 21:14에 Daniel Vetter 이(가) 쓴 글:
> On Thu, Aug 25, 2016 at 08:45:25PM +0900, Inki Dae wrote:
>>
>>
>> 2016년 08월 25일 17:42에 Daniel Vetter 이(가) 쓴 글:
>>> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:


 2016년 08월 24일 20:57에 Daniel Vetter 이(가) 쓴 글:
> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>> Hi,
>>
>> 2016년 08월 23일 18:41에 Daniel Stone 이(가) 쓴 글:
>>> Hi,
>>>
>>> On 22 August 2016 at 16:23, Rob Clark  wrote:
 I guess a lot comes down to 'how long before hw designers bolt a CP to
 the thing'..  at that point, I think you especially don't want a
 per-blit kernel interface.
>>>
>>> Regardless of whether or not we want it, we already _have_ it, in the
>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>> anyway ...
>>
>> So we are trying this. We had expereneced using V4L2 and DRM together on
>> Linux Platform makes it too complicated, and also integrated DRM with
>> M2M such as 2D and Post processor makes it simplified.  So We have been
>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>> Codec - called it MFC - and Camera sensor and relevant things.
>> I think now V4L2 and DRM frameworks may make many engineers confusing
>> because there are the same devices which can be controlled by V4L2 and
>> DRM frameworks - maybe we would need more efforts like Laurent did with
>> Live source[1] in the future.
>
> Can you pls explain in more detail where working with both v4l and drm
> drivers and making them cooperate using dma-bufs poses problems? We should
> definitely fix that.

 I think it would be most Linux Platforms - Android, Chrome and Tizen -
 which would use OpenMAX/GStreammer for Multimedia and X or
 Wayland/SurfaceFlinger for Display.
>>>
>>> Yes, that's the use case. Where is the problem in making this happen? v4l
>>> can import dma-bufs, drm can export them, and there's plenty devices
>>> shipping (afaik) that make use of exact this pipeline. Can you pls explain
>>> what problem you've hit trying to make this work on exynos?
>>
>> No problem but just make it complicated as I mentioned above - the
>> stream operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF
>> of V4L2 would never be simple as DRM.  Do you think M2M device should be
>> controlled by V4L2 interfaces? and even 2D accelerator? As long as I
>> know, The Graphics card on Desktop has all devices such as 2D/3D GPU, HW
>> Video codec and Display controller, and these devices are controlled by
>> DRM interfaces. So we - ARM Exynos - are trying to move these things to
>> DRM world and also trying to implement more convenient interfaces like
>> Marek did.
> 
> This is a misconception, there's nothing in the drm world requiring that
> everything is under the same drm device. All the work we've done over the
> past years (dma-buf, reservations, fence, prime, changes in X.org and
> wayland) are _all_ to make it possible to have a gfx device consisting of
> multiple drm/v4l/whatever else nodes. Especially for a SoC moving back to
> fake-integrating stuff really isn't a good idea I think.

Yes, not all devices. As I mentioned already - excepting HW Video codec and 
Camera device, we have changed a post processor driver to DRM instead of V4L2 
and now we are trying to standard the post processsor interfaces.
I know that the Display controllers of several SoC include Post processing 
function which makes image to be scaled up, down or rotated and pixel format of 
the image to be converted to other pixel format, and these device are 
controlled by DRM.

Do you think these post processor devices should be controlled by V4L2?

Thanks,
Inki Dae

> 
> And wrt drm being simpler than v4l - I don't think drm is any simpler, at
> elast if you look at some of the more feature-full render drivers.
> -Daniel
> 

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

[Haixia Shi]

The usb_driver suspend and resume function pointers must be populated
to prevent forced unbinding of USB interface driver. See usb/core/driver.c:
unbind_no_pm_drivers_interfaces().

Restore mode and damage the entire frame buffer upon resume.

TEST=suspend and resume with the same UDL device connected
TEST=suspend with UDL, unplug UDL and resume
TEST=suspend with UDL, unplug and connect another UDL device then resume

Signed-off-by: Haixia Shi 
Reviewed-by: Stphane Marchesin 
---
 drivers/gpu/drm/udl/udl_drv.c | 17 +
 drivers/gpu/drm/udl/udl_drv.h |  2 ++
 drivers/gpu/drm/udl/udl_modeset.c | 13 +
 3 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 17d34e0..e5dc73b 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -16,6 +16,21 @@ static int udl_driver_set_busid(struct drm_device *d, struct 
drm_master *m)
return 0;
 }

+static int udl_usb_suspend(struct usb_interface *interface,
+  pm_message_t message)
+{
+   return 0;
+}
+
+static int udl_usb_resume(struct usb_interface *interface)
+{
+   struct drm_device *dev = usb_get_intfdata(interface);
+
+   udl_modeset_restore(dev);
+   return 0;
+}
+
+
 static const struct vm_operations_struct udl_gem_vm_ops = {
.fault = udl_gem_fault,
.open = drm_gem_vm_open,
@@ -122,6 +137,8 @@ static struct usb_driver udl_driver = {
.name = "udl",
.probe = udl_usb_probe,
.disconnect = udl_usb_disconnect,
+   .suspend = udl_usb_suspend,
+   .resume = udl_usb_resume,
.id_table = id_table,
 };
 module_usb_driver(udl_driver);
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 0b03d34..f338a57 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -52,6 +52,7 @@ struct udl_device {
struct device *dev;
struct drm_device *ddev;
struct usb_device *udev;
+   struct drm_crtc *crtc;

int sku_pixel_limit;

@@ -87,6 +88,7 @@ struct udl_framebuffer {

 /* modeset */
 int udl_modeset_init(struct drm_device *dev);
+void udl_modeset_restore(struct drm_device *dev);
 void udl_modeset_cleanup(struct drm_device *dev);
 int udl_connector_init(struct drm_device *dev, struct drm_encoder *encoder);

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 7369512..69d6a4f 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -309,6 +309,8 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
char *wrptr;
int color_depth = 0;

+   udl->crtc = crtc;
+
buf = (char *)udl->mode_buf;

/* for now we just clip 24 -> 16 - if we fix that fix this */
@@ -450,6 +452,17 @@ int udl_modeset_init(struct drm_device *dev)
return 0;
 }

+void udl_modeset_restore(struct drm_device *dev)
+{
+   struct udl_device *udl = dev->dev_private;
+   struct udl_framebuffer *ufb;
+   if (!udl->crtc || !udl->crtc->primary->fb)
+   return;
+   udl_crtc_commit(udl->crtc);
+   ufb = to_udl_fb(udl->crtc->primary->fb);
+   udl_handle_damage(ufb, 0, 0, ufb->base.width, ufb->base.height);
+}
+
 void udl_modeset_cleanup(struct drm_device *dev)
 {
drm_mode_config_cleanup(dev);
-- 
2.8.0.rc3.226.g39d4020

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

[Haixia Shi]

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.

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

[PATCH v2] drm/nouveau/gr: mark gm107_grctx_generate_tpcid() static

[Arnd Bergmann]

On Tuesday 30 August 2016, Baoyou Xie wrote:
> On 30 August 2016 at 00:01, Sean Paul  wrote:
> 
> > On Mon, Aug 29, 2016 at 9:02 AM, Baoyou Xie  
> > wrote:
> > > We get 1 warning when build kernel with W=1:
> > > drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no
> > previous prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]
> > >
> > > In fact, this function is only used in the file in which it is
> > > declared and don't need a declaration, but can be made static.
> > > so this patch marks this function with 'static'.
> > >
> >
> > It would make things a lot easier if you either consolidated all of
> > these static changes into one patch, or released them as a series.
> >
> >
> Do you mean that I need to consolidate all of them into one patch this
> time? or next time?

I'd suggest consolidating the 'nouveau' changes into a single patch,
as this is one (very big) driver and resend that one.

Arnd

[PATCH 2/2] libdrm: add etnaviv tests

[Emil Velikov]

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

Other than that - a couple of trivial questions/suggestions. Similar
to the patch 1/2 ones - can be done as follow-up if needed.

>> --- /dev/null
>> +++ b/tests/etnaviv/cmdstream.xml.h

>> +The rules-ng-ng source files this header was generated from are:
>> +- /home/orion/projects/etna_viv/rnndb/cmdstream.xml (  12589 bytes, from 
>> 2013-09-01 10:53:22)
>> +- /home/orion/projects/etna_viv/rnndb/common.xml(  18379 bytes, from 
>> 2014-01-27 15:58:05)
Always wondered about this - can we fix rnn to not print the full path
but just files or rnndb/filename.xml ?

>> +Copyright (C) 2013
There is something funny here - currently we're not 2013 and the
copyright holders are missing. Guess something went bonkers in rnn ?

>> +int main(int argc, char *argv[])
>> +{

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

Thanks
Emil

Kernel Freeze with American Megatrends BIOS

[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

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

[Emil Velikov]

On 30 August 2016 at 08:14, Christian Gmeiner
 wrote:
> From: The etnaviv authors 
>
> Add the libdrm_etnaviv helper library to encapsulate etnaviv-specific 
> interfaces to the DRM.
>
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Lucas Stach 
Just double-checking:
 - you've looked that all the relevant freedreno patches have been
ported over, correct ?
 - the feature checking bug (mentioned on IRC) has been fixed ?

> diff --git a/configure.ac b/configure.ac
> index e3048c7..64f3e6c 100644
> --- a/configure.ac
> +++ b/configure.ac

> @@ -274,6 +279,9 @@ if test "x$drm_cv_atomic_primitives" = "xnone"; then
>
> LIBDRM_ATOMICS_NOT_FOUND_MSG($TEGRA, tegra, NVIDIA Tegra, 
> tegra-experimental-api)
> TEGRA=no
> +
> +   LIBDRM_ATOMICS_NOT_FOUND_MSG($ETNAVIV, etnaviv, Vivante, 
> etnaviv-experimental-api)
Reading this hunk reminds me what a bad name I've used. Then again
nothing better comes up atm. If you can think of any please shout.

> +++ b/etnaviv/Android.mk
Have you tried building/using etna on Android ?


> +++ b/etnaviv/Makefile.am
> @@ -0,0 +1,27 @@
> +AUTOMAKE_OPTIONS=subdir-objects
There are no subdirectories so you don't need this. Then again, can we
move the freedreno one to configure.ac - just append to
AM_INIT_AUTOMAKE.

> +include Makefile.sources
> +
> +AM_CFLAGS = \
> +   $(WARN_CFLAGS) \
> +   -I$(top_srcdir) \
> +   $(PTHREADSTUBS_CFLAGS) \
> +   -I$(top_srcdir)/include/drm
> +
> +libdrm_etnaviv_ladir = $(libdir)
> +libdrm_etnaviv_la_LTLIBRARIES = libdrm_etnaviv.la
> +libdrm_etnaviv_la_LDFLAGS = -version-number 0:0:0 -no-undefined
Maybe make this 1:0:0 ?

> --- /dev/null
> +++ b/etnaviv/etnaviv-symbol-check
> @@ -0,0 +1,45 @@
> +#!/bin/bash
> +
> +# The following symbols (past the first five) are taken from the public 
> headers.
> +# A list of the latter should be available 
> Makefile.sources/LIBDRM_FREEDRENO_H_FILES
> +
LIBDRM_ETNAVIV_H_FILES?


> new file mode 100644
> index 000..462241c
> --- /dev/null
> +++ b/etnaviv/etnaviv_drm.h
Double-checking: this file is identical to the one produced by make
headers_install, correct ?

-Emil

[PATCH] drm/nouveau/acpi: use DSM if bridge does not support D3cold

[Mika Westerberg]

On Fri, Aug 26, 2016 at 01:00:54AM +0200, Peter Wu wrote:
> Even if PR3 support is available on the bridge, it will not be used if
> the PCI layer considers it unavailable (i.e. on all laptops from 2013
> and 2014). Ensure that this condition is checked to allow a fallback to
> the Optimus DSM for device poweroff.
> 
> Initially I wanted to call pci_d3cold_enable before checking bridge_d3
> (in case the user changed d3cold_allowed), but that is such an unlikely
> case and likely fragile anyway. The current patch is suggested by Mika
> in http://www.spinics.net/lists/linux-pci/msg52599.html
> 
> Cc: Mika Westerberg 

Reviewed-by: Mika Westerberg 

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer
 wrote:
> My conclusion:
>
> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>I would love to help here.

nouveau + bbswitch will always end in tears. You're going behind the
driver's back and messing around with state it believes it is
managing. What if you just use nouveau and let it auto-power-off the
GPU like it's designed to, with v4.8-rc?

  -ilia

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

[Lee Jones]

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.

> Signed-off-by: Peter Griffin 
> ---
>  drivers/remoteproc/Kconfig   |   8 +
>  drivers/remoteproc/Makefile  |   1 +
>  drivers/remoteproc/st_slim_rproc.c   | 364 
> +++
>  include/linux/remoteproc/st_slim_rproc.h |  53 +
>  4 files changed, 426 insertions(+)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> 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.
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 92d3758..db1dae7 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)  += 
> da8xx_remoteproc.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)+= qcom_mdt_loader.o
>  obj-$(CONFIG_QCOM_Q6V5_PIL)  += qcom_q6v5_pil.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
> +obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> diff --git a/drivers/remoteproc/st_slim_rproc.c 
> b/drivers/remoteproc/st_slim_rproc.c
> new file mode 100644
> index 000..f4bf2d7
> --- /dev/null
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -0,0 +1,364 @@
> +/*
> + * st_slim_rproc.c

These serve no purpose and have a habit of becoming out-of-date.
Please remove it and replace with a nice succinct description
instead.

> + * Copyright (C) 2016 STMicroelectronics

Nit: '\n' here.

> + * Author: Peter Griffin 

Nit: '\n' here.

> + * License terms:  GNU General Public License (GPL), version 2

Are you sure ST are okay with the shortened version of the GPL?

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "remoteproc_internal.h"
> +
> +/* slimcore registers */

What's it called? slimcore, slim core, ST Slim?

Please be consistent.  Use the name from the datasheet.

> +#define SLIM_ID_OFST 0x0
> +#define SLIM_VER_OFST0x4
> +
> +#define SLIM_EN_OFST 0x8
> +#define SLIM_EN_RUN  BIT(0)
> +
> +#define SLIM_CLK_GATE_OFST   0xC
> +#define SLIM_CLK_GATE_DISBIT(0)
> +#define SLIM_CLK_GATE_RESET  BIT(2)
> +
> +#define SLIM_SLIM_PC_OFST0x20
> +
> +/* dmem registers */
> +#define SLIM_REV_ID_OFST 0x0
> +#define SLIM_REV_ID_MIN_MASK GENMASK(15, 8)
> +#define SLIM_REV_ID_MIN(id)  ((id & SLIM_REV_ID_MIN_MASK) >> 8)
> +#define SLIM_REV_ID_MAJ_MASK GENMASK(23, 16)
> +#define SLIM_REV_ID_MAJ(id)  ((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> +
> +
> +/* peripherals registers */
> +#define SLIM_STBUS_SYNC_OFST 0xF88
> +#define SLIM_STBUS_SYNC_DIS  BIT(0)
> +
> +#define SLIM_INT_SET_OFST0xFD4
> +#define SLIM_INT_CLR_OFST0xFD8
> +#define SLIM_INT_MASK_OFST   0xFDC
> +
> +#define SLIM_CMD_CLR_OFST0xFC8
> +#define SLIM_CMD_MASK_OFST   0xFCC
> +
> +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> + [ST_SLIM_DMEM]  = "dmem",
> + [ST_SLIM_IMEM]  = "imem",
> +};
> +
> +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> +{
> + int clk, err;
> +
> + for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> + 

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

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

Direct gtt range is used in the page fault scene in current driver,
instead of stolen page. So no need to keep relative process.

---
 drivers/gpu/drm/gma500/gem.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 6d1cb6b..53cb6704 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -201,10 +201,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
>> PAGE_SHIFT;

/* CPU view of the page, don't go via the GART for CPU writes */
-   if (r->stolen)
-   pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
-   else
-   pfn = page_to_pfn(r->pages[page_offset]);
+   pfn = page_to_pfn(r->pages[page_offset]);
ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);

 fail:
--
2.1.0

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Rob Clark]

Tom,

hmm, I wonder if it was a bug/oversight for the YUV capabilities of
this extension to not depend on OES_EGL_image_external (which
unfortunately, doesn't seem to have a GL counterpart)?

I think this currently implies that you could sample from an imported
YUV eglimg using (for example) sampler2D in GL or GLES, which I think
was not the intention.

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  wrote:
> Hi All,
>
> The final spec has had enum values assigned and been published on Khronos:
>
> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>
> Thanks to all who've provided input.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm.com at lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom 
>> Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; 
>> dri-
>> devel at lists.freedesktop.org; linux-media at vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> 

[Bug 97362] Low performance after suspend on RX 480

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

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

--- Comment #3 from Grigori Goronzy  ---
FWIW, the Metro 2033 games experience a particularly bad reduction in
performance after suspend. Basically half FPS. Other demanding games, e.g. Tomb
Raider, are not affected quite as much.

Still no idea what could be causing this.

-- 
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/20160830/ae06efcc/attachment-0001.html>

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Emil Velikov]

On 30 August 2016 at 09:12, Russell King - ARM Linux
 wrote:
> On Mon, Aug 29, 2016 at 05:41:10PM +0100, Emil Velikov wrote:
>> Hi all,
>>
>> On 24 August 2016 at 06:46, Vladimir Zapolskiy
>>  wrote:
>>
>> >  MODULE_AUTHOR("Sascha Hauer ");
>> >  MODULE_AUTHOR("Andy Yan ");
>> >  MODULE_AUTHOR("Yakir Yang ");
>> > +MODULE_AUTHOR("Vladimir Zapolskiy ");
>> Don't meant to start a flame-war or alike but to educate myself:
>> Where does one draw the line about adding new author(s) of said
>> module/subsystem ?
>>
>> Afaict this is the most common (?) driver in DRM where the list has
>> grown over time. Should we do the same with others ?
>
> ... and I'm responsible for just over half the commits in the mainline
> kernel and I haven't added myself.  I generally only add myself if I'm
> creating new code or been involved in adding new code, I don't add if
> I'm merely modifying existing code unless I've replaced a large
> quantity of the code.  I think the question people need to ask is:
>
>   "Have I contributed a significant set of changes to be able to claim
>shared authorship of that code?"
>
> You wouldn't claim authorship of a 500 page book if you suggested a
> few edits here and there.
>
> Looking at co-authorship in google, I came across:
>
> http://www.southernfriedscience.com/to-co-author-or-not-to-co-author/
>
> which has an interesting list of points on this subject, although more
> biased to research papers, which is where this problem normally arises.
> That seems to back up my idea of "significant contribution" not just
> a few minor changes.
>
> The question then becomes... what is a significant contribution. :)
>
Roughly my line of thinking as well.

Considering that the driver has been developed independently in one
shape or another for a few years I think it's perfectly reasonable in
this case.

Thanks for the input all !
Emil

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

[Laurent Pinchart]

Hi John,

Thank you for the patches.

On Monday 29 Aug 2016 16:41:32 John Stultz wrote:
> This is another swing at getting the adv7511 hdmi bridge
> audio support reviewed.
> 
> I've taken the core audio work done by Lars-Peter Clausen, and
> adapted by Srinivas Kandagatla and Archit Taneja, and tried to
> rework it to use the hdmi-codec sound driver.
> 
> This patchset, along with the i2s driver and dts changes allows
> HDMI audio to work on the HiKey board.

Where are the dts changes ?

> I'd really appreciate any thoughts or feedback.
> 
> New in v2:
> * Integrated Srinivas' review feedback
> 
> thanks
> -john
> 
> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Laurent Pinchart 
> Cc: Wolfram Sang 
> Cc: Srinivas Kandagatla 
> Cc: "Ville Syrjälä" 
> Cc: Boris Brezillon 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
> Cc: Mark Brown 
> Cc: Lars-Peter Clausen 
> Cc: Jose Abreu 
> Cc: dri-devel at lists.freedesktop.org
> 
> Andy Green (1):
>   drm/bridge: adv7511: Initialize audio packet on adv7533
> 
> Archit Taneja (1):
>   drm/bridge: adv7511: Move the common data structures to header file
> 
> John Stultz (1):
>   drm/bridge: adv7511: Add Audio support.
> 
> Srinivas Kandagatla (1):
>   drm/bridge: adv7511: Enable the audio data and clock pads on adv7533
> 
>  drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
>  drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  13 ++
>  drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 199 ++
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   9 +-
>  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  23 +++
>  6 files changed, 244 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

-- 
Regards,

Laurent Pinchart

[PATCH 2/4 v2] drm/bridge: adv7511: Add Audio support.

[Laurent Pinchart]

Hi John,

Thank you for the patch.

On Monday 29 Aug 2016 16:41:34 John Stultz wrote:
> This patch adds support to Audio for both adv7511 and adv7533
> bridge chips.
> 
> This patch was originally from [1] by Lars-Peter Clausen 
> and was adapted by Archit Taneja  and
> Srinivas Kandagatla .
> 
> Then I heavily reworked it to use the hdmi-codec driver. So credit
> to them, but blame to me.
> 
> [1]
> https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i
> 2c/adv7511_audio.c
> 
> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Laurent Pinchart 
> Cc: Wolfram Sang 
> Cc: Srinivas Kandagatla 
> Cc: "Ville Syrjälä" 
> Cc: Boris Brezillon 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
> Cc: Mark Brown 
> Cc: Lars-Peter Clausen 
> Cc: Jose Abreu 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz 
> ---
> v2: Integrated feedback from Srinivas
> 
>  drivers/gpu/drm/bridge/adv7511/Kconfig |   1 +
>  drivers/gpu/drm/bridge/adv7511/Makefile|   2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |   5 +
>  drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 199 ++
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   5 +
>  5 files changed, 211 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
> b/drivers/gpu/drm/bridge/adv7511/Kconfig index d2b0499..e3975e9 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I2C_ADV7511
>   depends on OF
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
> + select SND_SOC_HDMI_CODEC if SND_SOC

Shouldn't sound support be optional ? I can imagine a board that doesn't wire 
up sound to the ADV7511 but still uses SND_SOC for other purposes.

>   help
> Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
> b/drivers/gpu/drm/bridge/adv7511/Makefile index 9019327..ad7245d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> @@ -1,3 +1,3 @@
> -adv7511-y := adv7511_drv.o
> +adv7511-y := adv7511_drv.o adv7511_audio.o

Could we avoid compiling adv7511_audio.o if sound support isn't desired to 
avoid bloating the kernel ?

>  adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index c7002a0..2e4d340 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -23,6 +23,8 @@ struct adv7511;
> 
>  int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
>  int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
> +int adv7511_audio_init(struct device *dev);
> +void adv7511_audio_exit(struct device *dev);
> 
>  #define ADV7511_REG_CHIP_REVISION0x00
>  #define ADV7511_REG_N0   0x01
> @@ -317,6 +319,8 @@ struct adv7511 {
>   struct drm_display_mode curr_mode;
> 
>   unsigned int f_tmds;
> + unsigned int f_audio;
> + unsigned int audio_source;
> 
>   unsigned int current_edid_segment;
>   uint8_t edid_buf[256];
> @@ -342,6 +346,7 @@ struct adv7511 {
>   bool use_timing_gen;
> 
>   enum adv7511_type type;
> + struct platform_device *audio_pdev;
>  };
> 
>  #ifdef CONFIG_DRM_I2C_ADV7533
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c new file mode 100644
> index 000..0e0ea6b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -0,0 +1,199 @@
> +/*
> + * Analog Devices ADV7511 HDMI transmitter driver
> + *
> + * Copyright 2012 Analog Devices Inc.
> + * Copyright (c) 2016, Linaro Limited
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "adv7511.h"
> +
> +static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
> +unsigned int *cts, unsigned int *n)
> +{
> + switch (fs) {
> + case 32000:
> + *n = 4096;
> + break;
> + case 44100:
> + *n = 6272;
> + break;
> + case 48000:
> + *n = 6144;
> + break;
> + }
> +
> + *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
> +}
> +
> +static int adv7511_update_cts_n(struct adv7511 *adv7511)
> +{
> + unsigned int cts = 0;
> + unsigned int n = 0;
> +
> + adv7511_calc_cts_n(adv7511->f_tmds, adv7511->f_audio, , );
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_N0, (n >> 16) & 0xf);
> + regmap_write(adv7511->regmap, ADV7511_REG_N1, (n >> 8) & 0xff);
> + regmap_write(adv7511->regmap, ADV7511_REG_N2, n 

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

[Patrik Jakobsson]

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

>
> ---
>  drivers/gpu/drm/gma500/gem.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index 6d1cb6b..53cb6704 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -201,10 +201,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
> vm_fault *vmf)
> >> PAGE_SHIFT;
>
> /* CPU view of the page, don't go via the GART for CPU writes */
> -   if (r->stolen)
> -   pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
> -   else
> -   pfn = page_to_pfn(r->pages[page_offset]);
> +   pfn = page_to_pfn(r->pages[page_offset]);
> ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
>
>  fail:
> --
> 2.1.0
>

Kernel Freeze with American Megatrends BIOS

[Roland Singer]

Thanks for pointing it out.

Yeah that's right. The system will hang randomly a few minutes later,
because some certain actions in the graphical user session will trigger
the freeze.

I had a look at the function body of pci_read_config_dword:

  #define PCI_OP_READ(size, type, len) \
  int pci_bus_read_config_##size \
(struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
  { \
int res;\
unsigned long flags;\
u32 data = 0;   \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
raw_spin_lock_irqsave(_lock, flags);\
res = bus->ops->read(bus, devfn, pos, len, );  \
*value = (type)data;\
raw_spin_unlock_irqrestore(_lock, flags);   \
return res; \
  }

I guess, that bus->ops->read(...) might be the trigger.
Any hints how to continue debugging?

Cheers,
Roland

Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas:
> On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
>> Just tried it and the system didn't freeze. However it will freeze
>> after some time (few minutes while working).
>>
>> Seams to be pci_read_config_dword. Where is this exactly defined?
> 
> pci_read_config_dword() is defined in include/linux/pci.h.  It calls
> pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro
> in drivers/pci/access.c.
> 
> If I understand correctly, this:
> 
>   dis_dev_get();
>   pci_read_config_dword(dis_dev, 0, _word);
>   dis_dev_put();
> 
> causes an immediate system hang, but if you only do this:
> 
>   dis_dev_get();
>   dis_dev_put();
> 
> the system hangs a few minutes later.  Right?
> 
>> Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
>>> On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
 Hi Bjorn,

 I am using the bbswitch kernel module to switch off/on the GPU and
 to obtain the GPU power state.
 Obtaining the GPU state immediately after starting the graphical user
 session freezes the system.

 This code triggers something, which is responsible for the freeze.

 ---
 // Returns 1 if the card is disabled, 0 if enabled
 static int is_card_disabled(void) {
 u32 cfg_word;
 // read first config word which contains Vendor and Device ID. If all 
 bits
 // are enabled, the device is assumed to be off
 pci_read_config_dword(dis_dev, 0, _word);
 // if one of the bits is not enabled (the card is enabled), the 
 inverted
 // result will be non-zero and hence logical not will make it 0 
 ("false")
 return !~cfg_word;
 }

 static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
 // show the card state. Example output: :01:00:00 ON
 dis_dev_get();
 seq_printf(seqfp, "%s %s\n", dev_name(_dev->dev),
  is_card_disabled() ? "OFF" : "ON");
 dis_dev_put();
 return 0;
 }
 ---

 Either dis_dev_get or pci_read_config_dword is the trigger.
>>>
>>> What happens if you remove the call to is_card_disabled()?  Does the
>>> system still freeze if you only do the dis_dev_get()/dis_dev_put()?
>>>
 Link to the bbswitch module source code:
 https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333


 Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> [+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?
>
> On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
>> Hi,
>>
>> hope somebody can help me fix this kernel problem which affects the 
>> following machines:
>>
>> - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are 
>> also affected)
>> - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
>> - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
>> - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
>>
>>
>> The kernel freezes if the graphical user session (Xorg & Wayland) is
>> started with a switched off discrete GPU card (NVIDIA).
>> If the discrete GPU is switched off after the graphical session start,
>> then everything works as expected, until the graphical session is 
>> restarted.
>>
>> This problem seams to be linked to specific BIOS settings. If the 
>> computer
>> is started with the following command line:
>>
>> acpi_osi=! acpi_osi="Windows 2009"
>>
>> then the kernel freeze does not occur anymore. However this required a 
>> 

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

[Laurent Pinchart]

Hi John,

Thank you for the patch.

On Monday 29 Aug 2016 16:41:33 John Stultz wrote:
> From: Archit Taneja 
> 
> This patch moves the adv7511 data structure to header file so that the
> audio driver file could use it.

Actually it doesn't, the data structure is already in the header file.

> Cc: David Airlie 
> Cc: Archit Taneja 
> Cc: Laurent Pinchart 
> Cc: Wolfram Sang 
> Cc: Srinivas Kandagatla 
> Cc: "Ville Syrjälä" 
> Cc: Boris Brezillon 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> Cc: Zhangfei Gao 
> Cc: Mark Brown 
> Cc: Lars-Peter Clausen 
> Cc: Jose Abreu 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Srinivas Kandagatla 
> Signed-off-by: John Stultz 
> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511.h | 8 
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 161c923..c7002a0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -16,6 +16,14 @@
>  #include 
>  #include 
> 
> +#include 

Isn't it enough to include that header once ? :-)

> +
> +struct regmap;

This isn't needed, the header includes linux/regmap.h.

> +struct adv7511;
> +
> +int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
> +int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);

You can move those two functions at the end, with all the other function 
declarations, and get rid of the forward declaration of struct adv7511.

>  #define ADV7511_REG_CHIP_REVISION0x00
>  #define ADV7511_REG_N0   0x01
>  #define ADV7511_REG_N1   0x02
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index ec8fb2e..f8eb7f8
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -160,7 +160,7 @@ static void adv7511_set_colormap(struct adv7511
> *adv7511, bool enable, ADV7511_CSC_UPDATE_MODE, 0);
>  }
> 
> -static int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int
> packet)
> +int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet)
>  {
>   if (packet & 0xff)
>   regmap_update_bits(adv7511->regmap, 
ADV7511_REG_PACKET_ENABLE0,
> @@ -175,7 +175,7 @@ static int adv7511_packet_enable(struct adv7511
> *adv7511, unsigned int packet) return 0;
>  }
> 
> -static int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int
> packet)
> +int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet)
>  {
>   if (packet & 0xff)
>   regmap_update_bits(adv7511->regmap, 
ADV7511_REG_PACKET_ENABLE0,

-- 
Regards,

Laurent Pinchart

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

On Tue, Aug 30, 2016 at 11:44 AM, Ilia Mirkin  wrote:
> On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer
>  wrote:
>> I tried these scenarios:
>>
>> 1. Booted the system without the bbswitch module. The nouveau module
>>was loaded and is responsible for the power management of the GPU.
>>The graphical session freezes after some minutes...
>>
>> 2. Booted the system without bbswitch and with nouveau blacklisted.
>>Manually loaded bbswitch to switch off the discrete GPU.
>>Same freeze after a while or by explicitly obtaining the GPU state.
>>
>> Is there a possibility to switch off the discrete card without bbswitch?
>> If this is possible, then I could test this without nouveau and bbswitch
>> at all. If the system hangs, then it is not the video driver nor bbswitch.
>
> You can use acpi_call (a random search points to
> https://github.com/mkottman/acpi_call, but I don't know if that's the
> "official" version) - need to find the right method to call, but
> that's basically all it takes to acpi-suspend a gpu.
>
> Separately, there was a recent fix to ... something, including but not
> limited to nouveau, involving hangs on gpu suspend on newer laptops. I
> don't think it's upstream yet. Look for patches from Lukas Wunner.

Er oops. Looks like I misremembered. Patches are from Peter Wu, and at
least one of them is in v4.8-rc1:

commit 692a17dcc2922a91c6bcf11b3321503a3377b1b1
Author: Peter Wu 
Date:   Fri Jul 15 15:12:18 2016 +0200

drm/nouveau/acpi: fix lockup with PCIe runtime PM

along with a number of other related patches. It's not clear which
kernel you were trying this with... can you give v4.8-rcN a shot?

  -ilia

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer
 wrote:
> I tried these scenarios:
>
> 1. Booted the system without the bbswitch module. The nouveau module
>was loaded and is responsible for the power management of the GPU.
>The graphical session freezes after some minutes...
>
> 2. Booted the system without bbswitch and with nouveau blacklisted.
>Manually loaded bbswitch to switch off the discrete GPU.
>Same freeze after a while or by explicitly obtaining the GPU state.
>
> Is there a possibility to switch off the discrete card without bbswitch?
> If this is possible, then I could test this without nouveau and bbswitch
> at all. If the system hangs, then it is not the video driver nor bbswitch.

You can use acpi_call (a random search points to
https://github.com/mkottman/acpi_call, but I don't know if that's the
"official" version) - need to find the right method to call, but
that's basically all it takes to acpi-suspend a gpu.

Separately, there was a recent fix to ... something, including but not
limited to nouveau, involving hangs on gpu suspend on newer laptops. I
don't think it's upstream yet. Look for patches from Lukas Wunner.

  -ilia

[PATCH v8 02/18] MAINTAINERS: Add st slim core rproc driver to STi section.

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the slim core rproc driver to the STi section
> of the MAINTAINERS file.
> 
> Signed-off-by: Peter Griffin 
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Lee Jones 

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0bbe4b1..5dd3b24 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1749,6 +1749,7 @@ F:  drivers/phy/phy-stih407-usb.c
>  F:   drivers/phy/phy-stih41x-usb.c
>  F:   drivers/pinctrl/pinctrl-st.c
>  F:   drivers/remoteproc/st_remoteproc.c
> +F:   drivers/remoteproc/st_slim_rproc.c
>  F:   drivers/reset/sti/
>  F:   drivers/rtc/rtc-st-lpc.c
>  F:   drivers/tty/serial/st-asc.c
> @@ -1757,6 +1758,7 @@ F:  drivers/usb/host/ehci-st.c
>  F:   drivers/usb/host/ohci-st.c
>  F:   drivers/watchdog/st_lpc_wdt.c
>  F:   drivers/ata/ahci_st.c
> +F:   include/linux/remoteproc/st_slim_rproc.h
>  
>  ARM/STM32 ARCHITECTURE
>  M:   Maxime Coquelin 

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

[PATCH v8 06/18] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 
> +++
>  1 file changed, 52 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>   clock-frequency = <6>;
>   st,syscfg   = <_core 0x224>;
>   };
> +
> + /* fdma audio */
> + fdma0: dma-controller at 8e2 {
> + compatible = "st,stih407-fdma-mpe31-11", 
> "st,slim-rproc";
> + reg = <0x8e2 0x8000>,
> +   <0x8e3 0x3000>,
> +   <0x8e37000 0x1000>,
> +   <0x8e38000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>,
> +  <_s_c0_flexgen CLK_EXT2F_A9>;
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + };
> +
> + /* fdma app */
> + fdma1: dma-controller at 8e4 {
> + compatible = "st,stih407-fdma-mpe31-12", 
> "st,slim-rproc";
> + reg = <0x8e4 0x8000>,
> +   <0x8e5 0x3000>,
> +   <0x8e57000 0x1000>,
> +   <0x8e58000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> + <_s_c0_flexgen CLK_TX_ICN_DMU>,
> + <_s_c0_flexgen CLK_TX_ICN_DMU>,
> + <_s_c0_flexgen CLK_EXT2F_A9>;
> +
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + };
> +
> + /* fdma free running */
> + fdma2: dma-controller at 8e6 {
> + compatible = "st,stih407-fdma-mpe31-13", 
> "st,slim-rproc";
> + reg = <0x8e6 0x8000>,
> +   <0x8e7 0x3000>,
> +   <0x8e77000 0x1000>,
> +   <0x8e78000 0x8000>;
> + reg-names = "slimcore", "dmem", "peripherals", "imem";
> + interrupts = ;
> + dma-channels = <16>;
> + #dma-cells = <3>;
> + clocks = <_s_c0_flexgen CLK_FDMA>,
> + <_s_c0_flexgen CLK_EXT2F_A9>,
> + <_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> + <_s_c0_flexgen CLK_EXT2F_A9>;
> + };
>   };
>  };

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

[PATCH v8 09/18] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.

[Lee Jones]

Nit: Remove full-stop from $SUBJECT

On Fri, 26 Aug 2016, Peter Griffin wrote:
> This patch enables the STi ALSA drivers found on STi platforms
> as well as the simple-card driver which is a dependency to have
> working sound.
> 
> Signed-off-by: Peter Griffin 
> Cc: arnaud.pouliquen at st.com
> Cc: broonie at kernel.org
> ---
>  arch/arm/configs/multi_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 998578a..51a38b1 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m
>  CONFIG_SND_SOC_SGTL5000=m
>  CONFIG_SND_SOC_SPDIF=m
>  CONFIG_SND_SOC_WM8978=m
> +CONFIG_SND_SOC_STI=m
> +CONFIG_SND_SOC_STI_SAS=m
> +CONFIG_SND_SIMPLE_CARD=m
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_MVEBU=y

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

[PATCH v8 10/18] ARM: DT: STiH407: Add i2s_out pinctrl configuration

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++
>  1 file changed, 23 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>   };
>   };
>  
> + i2s_out {
> + pinctrl_i2s_8ch_out: i2s_8ch_out{
> + st,pins {
> + mclk = < 5 ALT1 OUT>;
> + lrclk = < 7 ALT1 OUT>;
> + sclk = < 6 ALT1 OUT>;
> + data0 = < 4 ALT1 OUT>;
> + data1 = < 0 ALT1 OUT>;
> + data2 = < 1 ALT1 OUT>;
> + data3 = < 2 ALT1 OUT>;
> + };
> + };
> +
> + pinctrl_i2s_2ch_out: i2s_2ch_out{
> + st,pins {
> + mclk = < 5 ALT1 OUT>;
> + lrclk = < 7 ALT1 OUT>;
> + sclk = < 6 ALT1 OUT>;
> + data0 = < 4 ALT1 OUT>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {

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

[PATCH v8 11/18] ARM: DT: STiH407: Add i2s_in pinctrl configuration

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 
>  1 file changed, 24 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>   };
>   };
>  
> + i2s_in {
> + pinctrl_i2s_8ch_in: i2s_8ch_in{
> + st,pins {
> + mclk = < 5 ALT1 IN>;
> + lrclk = < 7 ALT1 IN>;
> + sclk = < 6 ALT1 IN>;
> + data0 = < 4 ALT1 IN>;
> + data1 = < 0 ALT1 IN>;
> + data2 = < 1 ALT1 IN>;
> + data3 = < 2 ALT1 IN>;
> + data4 = < 3 ALT1 IN>;
> + };
> + };
> +
> + pinctrl_i2s_2ch_in: i2s_2ch_in{
> + st,pins {
> + mclk = < 5 ALT1 IN>;
> + lrclk = < 7 ALT1 IN>;
> + sclk = < 6 ALT1 IN>;
> + data0 = < 4 ALT1 IN>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {

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

[PATCH v8 12/18] ARM: DT: STiH407: Add spdif_out pinctrl config

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 
>  1 file changed, 8 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
> b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>   };
>   };
>  
> + spdif_out {
> + pinctrl_spdif_out: spdif_out{
> + st,pins {
> + spdif_out = < 7 ALT1 OUT>;
> + };
> + };
> + };
> +
>   serial3 {
>   pinctrl_serial3: serial3-0 {
>   st,pins {

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

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

[Jani Nikula]

On Tue, 30 Aug 2016, Martin van Es  wrote:
> Hi Andrea,
>
> I'd be happy to test, but what am I testing when applying these boot 
> parameters? In other words: what should I report?

The point is, for an ivybridge setting those parameters should not make
*any* difference.

BR,
Jani.


>
> And just to be sure, I THINK I own an IVB but intel is not very vocal about 
> it 
> when searching for familyname. I have a
>
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 58
> model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
> stepping: 9
> microcode   : 0x17
>
> Regards,
> Martin
>
> On maandag 29 augustus 2016 20:48:43 CEST Andrea Arcangeli wrote:
>> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> > If it's an Iybridge, there's no low vswing, and that explanation is
>> > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> > on an unpatched kernel.
>> 
>> CC'ed Martin who filed the bz, he can reproduce too
>> https://bugzilla.kernel.org/show_bug.cgi?id=151731
>> 
>> Since you can reproduce would you have the time to test the two above
>> options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
>> I won't be able to test it today and I'll be mostly offline for a week
>> starting tomorrow.
>> 
>> Thanks,
>> Andrea

-- 
Jani Nikula, Intel Open Source Technology Center

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

[Martin van Es]

On dinsdag 30 augustus 2016 11:13:40 CEST Jani Nikula wrote:
> On Tue, 30 Aug 2016, Martin van Es  wrote:
> > Hi Andrea,
> > 
> > I'd be happy to test, but what am I testing when applying these boot
> > parameters? In other words: what should I report?
> 
> The point is, for an ivybridge setting those parameters should not make
> *any* difference.

I can confirm that neither i915.edp_vswing=1 nor i915.edp_vswing=2 fixes the 
problem in 4.7.2 for me (intel_backlight devices takes precedence).

Best regards,
Martin

[PATCH 2/2] libdrm: add etnaviv tests

[Daniel Vetter]

On Tue, Aug 30, 2016 at 09:14:51AM +0200, Christian Gmeiner wrote:
> From: The etnaviv authors 
> 
> This adds the following basic unit tests:
> 
> - etnaviv_2d_test
>   Let the 2D core render a defined pattern into a bo
>   and store it as bmp.
> 
> - etnaviv_bo_cache_test
>   Basic tests to validate the bo-cache behavior.
> 
> - etnaviv_cmd_stream_test
>   Tests for the etna_cmd_stream API.

igt (now at a new location at
https://cgit.freedesktop.org/drm/igt-gpu-tools/) would be a nice place for
these I think, if you want to participate there. vc4 has tests in there,
and collabora is porting a lot of the kms tests to be generic (so that
they can be run on any kms driver). Then you could just run those tests on
any driver and have a reasonable assurance you didn't break the world.

But up to you really.
-Daniel
> 
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Lucas Stach 
> ---
>  .gitignore  |3 +
>  configure.ac|1 +
>  tests/Makefile.am   |4 +
>  tests/etnaviv/Makefile.am   |   41 +
>  tests/etnaviv/cmdstream.xml.h   |  218 +
>  tests/etnaviv/etnaviv_2d_test.c |  238 +
>  tests/etnaviv/etnaviv_bo_cache_test.c   |  122 +++
>  tests/etnaviv/etnaviv_cmd_stream_test.c |  123 +++
>  tests/etnaviv/state.xml.h   |  348 
>  tests/etnaviv/state_2d.xml.h| 1473 
> +++
>  tests/etnaviv/write_bmp.c   |  152 
>  tests/etnaviv/write_bmp.h   |   34 +
>  12 files changed, 2757 insertions(+)
>  create mode 100644 tests/etnaviv/Makefile.am
>  create mode 100644 tests/etnaviv/cmdstream.xml.h
>  create mode 100644 tests/etnaviv/etnaviv_2d_test.c
>  create mode 100644 tests/etnaviv/etnaviv_bo_cache_test.c
>  create mode 100644 tests/etnaviv/etnaviv_cmd_stream_test.c
>  create mode 100644 tests/etnaviv/state.xml.h
>  create mode 100644 tests/etnaviv/state_2d.xml.h
>  create mode 100644 tests/etnaviv/write_bmp.c
>  create mode 100644 tests/etnaviv/write_bmp.h
> 
> diff --git a/.gitignore b/.gitignore
> index 3226b3a..d51e619 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -102,4 +102,7 @@ tests/radeon/radeon_ttm
>  tests/exynos/exynos_fimg2d_event
>  tests/exynos/exynos_fimg2d_perf
>  tests/exynos/exynos_fimg2d_test
> +tests/etnaviv/etnaviv_2d_test
> +tests/etnaviv/etnaviv_cmd_stream_test
> +tests/etnaviv/etnaviv_bo_cache_test
>  man/*.3
> diff --git a/configure.ac b/configure.ac
> index 64f3e6c..330358a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -551,6 +551,7 @@ AC_CONFIG_FILES([
>   tests/exynos/Makefile
>   tests/tegra/Makefile
>   tests/nouveau/Makefile
> + tests/etnaviv/Makefile
>   tests/util/Makefile
>   man/Makefile
>   libdrm.pc])
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 58feb12..4a499e4 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -22,6 +22,10 @@ if HAVE_TEGRA
>  SUBDIRS += tegra
>  endif
>  
> +if HAVE_ETNAVIV
> +SUBDIRS += etnaviv
> +endif
> +
>  AM_CFLAGS = \
>   $(WARN_CFLAGS)\
>   -I $(top_srcdir)/include/drm \
> diff --git a/tests/etnaviv/Makefile.am b/tests/etnaviv/Makefile.am
> new file mode 100644
> index 000..0631864
> --- /dev/null
> +++ b/tests/etnaviv/Makefile.am
> @@ -0,0 +1,41 @@
> +AM_CFLAGS = \
> + -I $(top_srcdir)/include/drm \
> + -I $(top_srcdir)/etnaviv \
> + -I $(top_srcdir)
> +
> +if HAVE_INSTALL_TESTS
> +bin_PROGRAMS = \
> + etnaviv_2d_test \
> + etnaviv_cmd_stream_test \
> + etnaviv_bo_cache_test
> +else
> +noinst_PROGRAMS = \
> + etnaviv_2d_test \
> + etnaviv_cmd_stream_test \
> + etnaviv_bo_cache_test
> +endif
> +
> +etnaviv_2d_test_LDADD = \
> + $(top_builddir)/libdrm.la \
> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
> +
> +etnaviv_2d_test_SOURCES = \
> + cmdstream.xml.h \
> + etnaviv_2d_test.c \
> + state.xml.h \
> + state_2d.xml.h \
> + write_bmp.c \
> + write_bmp.h
> +
> +etnaviv_cmd_stream_test_LDADD = \
> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
> +
> +etnaviv_cmd_stream_test_SOURCES = \
> + etnaviv_cmd_stream_test.c
> +
> +etnaviv_bo_cache_test_LDADD = \
> + $(top_builddir)/libdrm.la \
> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
> +
> +etnaviv_bo_cache_test_SOURCES = \
> + etnaviv_bo_cache_test.c
> diff --git a/tests/etnaviv/cmdstream.xml.h b/tests/etnaviv/cmdstream.xml.h
> new file mode 100644
> index 000..844f829
> --- /dev/null
> +++ b/tests/etnaviv/cmdstream.xml.h
> @@ -0,0 +1,218 @@
> +#ifndef CMDSTREAM_XML
> +#define CMDSTREAM_XML
> +
> +/* Autogenerated file, DO NOT EDIT manually!
> +
> +This file was generated by the rules-ng-ng headergen tool in this git 
> repository:
> +http://0x04.net/cgit/index.cgi/rules-ng-ng
> +git clone git://0x04.net/rules-ng-ng
> +
> +The rules-ng-ng source files this header was generated from are:
> +- 

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

[Tomi Valkeinen]

Hi,

On 12/08/16 14:14, Sean Paul wrote:
> On Thu, Aug 11, 2016 at 7:00 AM, Tomi Valkeinen  
> wrote:
>> On 11/08/16 13:56, Sean Paul wrote:
>>> On Thu, Aug 11, 2016 at 5:44 AM, Peter Chen  wrote:
>>>> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
>>>>
>>>> The of_get_next_parent will drop refcount on the passed node, so the 
>>>> reverted
>>>> patch is wrong, thanks for Tomi Valkeinen points it.
>>>>
>>>
>>> Indeed it is. Tomi, are you going to pick this up in your tree, or
>>> would you like it to go through -misc?
>>>
>>> Reviewed-by: Sean Paul 
>>
>> Acked-by: Tomi Valkeinen 
>>
>> I don't have any other fixes at the moment, so I'm fine with it going
>> via some other tree, or picked directly to drm-fixes.
>>
> 
> Applied to drm-misc

Hmm, did this go to drm-next? It should be in drm-fixes.

 Tomi

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

[PATCH v8 13/18] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>   <_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>   <_s_c0_flexgen CLK_EXT2F_A9>;
>   };
> +
> + sti_sasg_codec: sti-sasg-codec {
> + compatible = "st,stih407-sas-codec";
> + #sound-dai-cells = <1>;
> + status = "disabled";
> + st,syscfg = <_core>;
> + };
>   };
>  };

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

[PATCH v8 14/18] ARM: STi: DT: STiH407: Add uniperif player dt nodes

[Lee Jones]

On Tue, 30 Aug 2016, Lee Jones wrote:

> On Fri, 26 Aug 2016, Peter Griffin wrote:
> 
> > This patch adds the DT nodes for the uniperif player
> > IP blocks found on STiH407 family silicon.
> > 
> > Signed-off-by: Arnaud Pouliquen 
> > Signed-off-by: Peter Griffin 
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 76 
> > +++
> >  1 file changed, 76 insertions(+)
> 
> Same comments as in patch 14.

s/14/15/

> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> > b/arch/arm/boot/dts/stih407-family.dtsi
> > index d1258d5..d263c96 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -880,5 +880,81 @@
> > status = "disabled";
> > st,syscfg = <_core>;
> > };
> > +
> > +   sti_uni_player0: sti-uni-player at 0 {
> > +   compatible = "st,sti-uni-player";
> > +   status = "disabled";
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   clocks = <_s_d0_flexgen CLK_PCM_0>;
> > +   assigned-clocks = <_s_d0_quadfs 0>, 
> > <_s_d0_flexgen CLK_PCM_0>;
> > +   assigned-clock-parents = <0>, <_s_d0_quadfs 0>;
> > +   assigned-clock-rates = <5000>;
> > +   reg = <0x8D8 0x158>;
> > +   interrupts = ;
> > +   dmas = < 2 0 1>;
> > +   dai-name = "Uni Player #0 (HDMI)";
> > +   dma-names = "tx";
> > +   st,uniperiph-id = <0>;
> > +   st,version = <5>;
> > +   st,mode = "HDMI";
> > +   };
> > +
> > +   sti_uni_player1: sti-uni-player at 1 {
> > +   compatible = "st,sti-uni-player";
> > +   status = "disabled";
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   clocks = <_s_d0_flexgen CLK_PCM_1>;
> > +   assigned-clocks = <_s_d0_quadfs 1>, 
> > <_s_d0_flexgen CLK_PCM_1>;
> > +   assigned-clock-parents = <0>, <_s_d0_quadfs 1>;
> > +   assigned-clock-rates = <5000>;
> > +   reg = <0x8D81000 0x158>;
> > +   interrupts = ;
> > +   dmas = < 3 0 1>;
> > +   dai-name = "Uni Player #1 (PIO)";
> > +   dma-names = "tx";
> > +   st,uniperiph-id = <1>;
> > +   st,version = <5>;
> > +   st,mode = "PCM";
> > +   };
> > +
> > +   sti_uni_player2: sti-uni-player at 2 {
> > +   compatible = "st,sti-uni-player";
> > +   status = "disabled";
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   clocks = <_s_d0_flexgen CLK_PCM_2>;
> > +   assigned-clocks = <_s_d0_quadfs 2>, 
> > <_s_d0_flexgen CLK_PCM_2>;
> > +   assigned-clock-parents = <0>, <_s_d0_quadfs 2>;
> > +   assigned-clock-rates = <5000>;
> > +   reg = <0x8D82000 0x158>;
> > +   interrupts = ;
> > +   dmas = < 4 0 1>;
> > +   dai-name = "Uni Player #1 (DAC)";
> > +   dma-names = "tx";
> > +   st,uniperiph-id = <2>;
> > +   st,version = <5>;
> > +   st,mode = "PCM";
> > +   };
> > +
> > +   sti_uni_player3: sti-uni-player at 3 {
> > +   compatible = "st,sti-uni-player";
> > +   status = "disabled";
> > +   #sound-dai-cells = <0>;
> > +   st,syscfg = <_core>;
> > +   clocks = <_s_d0_flexgen CLK_SPDIFF>;
> > +   assigned-clocks = <_s_d0_quadfs 3>, 
> > <_s_d0_flexgen CLK_SPDIFF>;
> > +   assigned-clock-parents = <0>, <_s_d0_quadfs 3>;
> > +   assigned-clock-rates = <5000>;
> > +   reg = <0x8D85000 0x158>;
> > +   interrupts = ;
> > +   dmas = < 7 0 1>;
> > +   dma-names = "tx";
> > +   dai-name = "Uni Player #1 (PIO)";
> > +   st,uniperiph-id = <3>;
> > +   st,version = <5>;
> > +   st,mode = "SPDIF";
> > +   };
> > };
> >  };
> 

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

[PATCH v8 14/18] ARM: STi: DT: STiH407: Add uniperif player dt nodes

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 76 
> +++
>  1 file changed, 76 insertions(+)

Same comments as in patch 14.

> diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
> b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..d263c96 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,81 @@
>   status = "disabled";
>   st,syscfg = <_core>;
>   };
> +
> + sti_uni_player0: sti-uni-player at 0 {
> + compatible = "st,sti-uni-player";
> + status = "disabled";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_0>;
> + assigned-clocks = <_s_d0_quadfs 0>, 
> <_s_d0_flexgen CLK_PCM_0>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 0>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8D8 0x158>;
> + interrupts = ;
> + dmas = < 2 0 1>;
> + dai-name = "Uni Player #0 (HDMI)";
> + dma-names = "tx";
> + st,uniperiph-id = <0>;
> + st,version = <5>;
> + st,mode = "HDMI";
> + };
> +
> + sti_uni_player1: sti-uni-player at 1 {
> + compatible = "st,sti-uni-player";
> + status = "disabled";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_1>;
> + assigned-clocks = <_s_d0_quadfs 1>, 
> <_s_d0_flexgen CLK_PCM_1>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 1>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8D81000 0x158>;
> + interrupts = ;
> + dmas = < 3 0 1>;
> + dai-name = "Uni Player #1 (PIO)";
> + dma-names = "tx";
> + st,uniperiph-id = <1>;
> + st,version = <5>;
> + st,mode = "PCM";
> + };
> +
> + sti_uni_player2: sti-uni-player at 2 {
> + compatible = "st,sti-uni-player";
> + status = "disabled";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_PCM_2>;
> + assigned-clocks = <_s_d0_quadfs 2>, 
> <_s_d0_flexgen CLK_PCM_2>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 2>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8D82000 0x158>;
> + interrupts = ;
> + dmas = < 4 0 1>;
> + dai-name = "Uni Player #1 (DAC)";
> + dma-names = "tx";
> + st,uniperiph-id = <2>;
> + st,version = <5>;
> + st,mode = "PCM";
> + };
> +
> + sti_uni_player3: sti-uni-player at 3 {
> + compatible = "st,sti-uni-player";
> + status = "disabled";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + clocks = <_s_d0_flexgen CLK_SPDIFF>;
> + assigned-clocks = <_s_d0_quadfs 3>, 
> <_s_d0_flexgen CLK_SPDIFF>;
> + assigned-clock-parents = <0>, <_s_d0_quadfs 3>;
> + assigned-clock-rates = <5000>;
> + reg = <0x8D85000 0x158>;
> + interrupts = ;
> + dmas = < 7 0 1>;
> + dma-names = "tx";
> + dai-name = "Uni Player #1 (PIO)";
> + st,uniperiph-id = <3>;
> + st,version = <5>;
> + st,mode = "SPDIF";
> + };
>   };
>  };

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

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

[Lee Jones]

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'.  There isn't a functional difference
admittedly, but it would be my preference, since it's not describing
the device per se.

> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + reg = <0x8D83000 0x158>;

We usually use lower-case for the address.

Since this has a 'reg' property, the '0' in the node name does not
look appropriate.

> + interrupts = ;
> + dmas = < 5 0 1>;
> + dma-names = "rx";
> + 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.

> + st,version = <3>;

This will likely need a DT Ack too.  We usually encode this sort of
information in the compatible string.

> + };
> +
> + sti_uni_reader1: sti-uni-reader at 1 {
> + compatible = "st,sti-uni-reader";
> + status = "disabled";
> + #sound-dai-cells = <0>;
> + st,syscfg = <_core>;
> + reg = <0x8D84000 0x158>;
> + interrupts = ;
> + dmas = < 6 0 1>;
> + dma-names = "rx";
> + dai-name = "Uni Reader #1 (HDMI RX)";
> + st,version = <3>;
> + };

All as above.

>   };
>  };

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

[PATCH v8 18/18] drm/virtio: kconfig: Fixup white space.

[Lee Jones]

On Tue, 30 Aug 2016, Lee Jones wrote:

> On Fri, 26 Aug 2016, Peter Griffin wrote:
> 
> > Use tabs instead of spaces.
> > 
> > Signed-off-by: Peter Griffin 
> > ---
> >  drivers/gpu/drm/virtio/Kconfig | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> For my own reference:
>   Acked-by: Lee Jones 

Whoops!  Please ignore the "For my own reference" part.  I used the
wrong key-combo shortcut.

> > diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> > index 90357d9..2d83932 100644
> > --- a/drivers/gpu/drm/virtio/Kconfig
> > +++ b/drivers/gpu/drm/virtio/Kconfig
> > @@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
> > tristate "Virtio GPU driver"
> > depends on DRM
> > select VIRTIO
> > -select DRM_KMS_HELPER
> > -select DRM_TTM
> > +   select DRM_KMS_HELPER
> > +   select DRM_TTM
> > help
> >This is the virtual GPU driver for virtio.  It can be used with
> > -   QEMU based VMMs (like KVM or Xen).
> > +  QEMU based VMMs (like KVM or Xen).
> >  
> >If unsure say M.
> 

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

[RFC 1/2] gpu: ipu-v3: export memory reset function

[Ying Liu]

On Mon, Aug 29, 2016 at 6:33 PM, Philipp Zabel  
wrote:
> Add defines for the memory reset bits and export the memory reset
> function to IPU modules.

This one is probably unneeded since patch 2/2 is questionable.

>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/ipu-v3/ipu-common.c | 17 +
>  drivers/gpu/ipu-v3/ipu-prv.h| 24 
>  2 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 5e7af61..1ad33df 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -706,14 +706,14 @@ void ipu_idmac_enable_watermark(struct ipuv3_channel 
> *channel, bool enable)
>  }
>  EXPORT_SYMBOL_GPL(ipu_idmac_enable_watermark);
>
> -static int ipu_memory_reset(struct ipu_soc *ipu)
> +int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem)
>  {
> unsigned long timeout;
>
> -   ipu_cm_write(ipu, 0x807F, IPU_MEM_RST);
> +   ipu_cm_write(ipu, rst_mem | IPU_RST_MEM_START, IPU_MEM_RST);
>
> timeout = jiffies + msecs_to_jiffies(1000);
> -   while (ipu_cm_read(ipu, IPU_MEM_RST) & 0x8000) {
> +   while (ipu_cm_read(ipu, IPU_MEM_RST) & IPU_RST_MEM_START) {
> if (time_after(jiffies, timeout))
> return -ETIME;
> cpu_relax();
> @@ -1363,7 +1363,16 @@ static int ipu_probe(struct platform_device *pdev)
> dev_err(>dev, "failed to reset: %d\n", ret);
> goto out_failed_reset;
> }
> -   ret = ipu_memory_reset(ipu);
> +   ret = ipu_memory_reset(ipu, IPU_RST_MEM_SRM | IPU_RST_MEM_ALPHA |
> +  IPU_RST_MEM_CPMEM | IPU_RST_MEM_TPM |
> +  IPU_RST_MEM_MPM | IPU_RST_MEM_BM |
> +  IPU_RST_MEM_RM | IPU_RST_MEM_DSTM |
> +  IPU_RST_MEM_DSOM | IPU_RST_MEM_LUT0 |
> +  IPU_RST_MEM_LUT1 | IPU_RST_MEM_RAM_SMFC |
> +  IPU_RST_MEM_VDI_FIFO2 | IPU_RST_MEM_VDI_FIFO3 |
> +  IPU_RST_MEM_ICB | IPU_RST_MEM_VDI_FIFO1 |
> +  IPU_RST_MEM_DC_TEMPLATE | IPU_RST_MEM_DMFC_RD |
> +  IPU_RST_MEM_DMFC_WR);

Better to define all the bits with a single meaningful macro in ipu-prv.h,
which makes the code more readable.

> if (ret)
> goto out_failed_reset;
>  #endif
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index 6803cc7..8e9ef56 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -75,6 +75,28 @@ struct ipu_soc;
>  #define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
>  #define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))
>
> +#define IPU_RST_MEM_SRMBIT(0)
> +#define IPU_RST_MEM_ALPHA  BIT(1)
> +#define IPU_RST_MEM_CPMEM  BIT(2)
> +#define IPU_RST_MEM_TPMBIT(3)
> +#define IPU_RST_MEM_MPMBIT(4)
> +#define IPU_RST_MEM_BM BIT(5)
> +#define IPU_RST_MEM_RM BIT(6)
> +#define IPU_RST_MEM_DSTM   BIT(7)
> +#define IPU_RST_MEM_DSOM   BIT(8)
> +#define IPU_RST_MEM_LUT0   BIT(9)
> +#define IPU_RST_MEM_LUT1   BIT(10)
> +#define IPU_RST_MEM_RAM_SMFC   BIT(11)
> +#define IPU_RST_MEM_VDI_FIFO2  BIT(12)
> +#define IPU_RST_MEM_VDI_FIFO3  BIT(13)
> +#define IPU_RST_MEM_ICBBIT(14)
> +#define IPU_RST_MEM_VDI_FIFO1  BIT(15)
> +#define IPU_RST_MEM_DC_TEMPLATEBIT(20)
> +#define IPU_RST_MEM_DMFC_RDBIT(21)
> +#define IPU_RST_MEM_DMFC_WRBIT(22)
> +
> +#define IPU_RST_MEM_START  BIT(31)

Some bits have different meaning for i.MX51 IPUv3.
Please take a look at i.MX51 RM[1] page 1268.
I think i.MX6x IPUv3 and i.MX53 IPUv3 are the same wrt the bits.

[1] 
http://www.nxp.com/files/dsp/doc/ref_manual/MCIMX51RM.pdf?fasp=1_TYPE=Reference%20Manuals_VENDOR=FREESCALE_FILE_FORMAT=pdf_ASSET=Documentation=.pdf

> +
>  #define IPU_DI0_COUNTER_RELEASE(1 << 24)
>  #define IPU_DI1_COUNTER_RELEASE(1 << 25)
>
> @@ -401,6 +423,8 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, 
> u32 value,
>
>  void ipu_srm_dp_sync_update(struct ipu_soc *ipu);
>
> +int ipu_memory_reset(struct ipu_soc *ipu, u32 rst_mem);

Nit: To keep the same order with ipu-common.c, this line should be
under ipu_wait_interrupt().

Regards,
Liu Ying

> +
>  int ipu_module_enable(struct ipu_soc *ipu, u32 mask);
>  int ipu_module_disable(struct ipu_soc *ipu, u32 mask);
>
> --
> 2.8.1
>

[PATCH v8 16/18] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen 
> Signed-off-by: Peter Griffin 
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 
> 
>  1 file changed, 45 insertions(+)

Acked-by: Lee Jones 

> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
> b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..1f64bb6 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>   dvb-card= ;
>   };
>   };
> +
> + sti_uni_player2: sti-uni-player at 2 {
> + status = "okay";
> + };
> +
> + sti_uni_player3: sti-uni-player at 3 {
> + status = "okay";
> + };
> +
> + sti_sasg_codec: sti-sasg-codec {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_spdif_out>;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "sti audio card";
> + status = "okay";
> +
> + simple-audio-card,dai-link at 0 {
> + /* DAC */
> + format = "i2s";
> + mclk-fs = <256>;
> + cpu {
> + sound-dai = <_uni_player2>;
> + };
> +
> + codec {
> + sound-dai = <_sasg_codec 1>;
> + };
> + };
> + simple-audio-card,dai-link at 1 {
> + /* SPDIF */
> + format = "left_j";
> + mclk-fs = <128>;
> + cpu {
> + sound-dai = <_uni_player3>;
> + };
> +
> + codec {
> + sound-dai = <_sasg_codec 0>;
> + };
> + };
> + };
>   };
>  };

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

[PATCH v8 17/18] drm/virtio: kconfig: Fix recursive dependency.

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> [..]
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:5:symbol FB is selected by 
> DRM_KMS_FB_HELPER
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/Kconfig:42:   symbol DRM_KMS_FB_HELPER depends on 
> DRM_KMS_HELPER
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/Kconfig:36:   symbol DRM_KMS_HELPER is selected by 
> DRM_VIRTIO_GPU
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by 
> ST_SLIM_REMOTEPROC
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/remoteproc/Kconfig:103:   symbol ST_SLIM_REMOTEPROC is selected 
> by ST_FDMA
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/dma/Kconfig:440:  symbol ST_FDMA depends on DMADEVICES
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/dma/Kconfig:5:symbol DMADEVICES is selected by SND_SOC_SH4_SIU
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> sound/soc/sh/Kconfig:29:  symbol SND_SOC_SH4_SIU is selected by 
> SND_SIU_MIGOR
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> sound/soc/sh/Kconfig:64:  symbol SND_SIU_MIGOR depends on I2C
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/i2c/Kconfig:7:symbol I2C is selected by FB_DDC
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:63:   symbol FB_DDC is selected by 
> FB_CYBER2000_DDC
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:378:  symbol FB_CYBER2000_DDC depends on 
> FB_CYBER2000
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> drivers/video/fbdev/Kconfig:366:  symbol FB_CYBER2000 depends on FB

An explanation of why this is happening and why your fix works is
usually helpful here.

> Signed-off-by: Peter Griffin 
> ---
>  drivers/gpu/drm/virtio/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index e1afc3d..90357d9 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_VIRTIO_GPU
>   tristate "Virtio GPU driver"
> - depends on DRM && VIRTIO
> + depends on DRM
> + select VIRTIO
>  select DRM_KMS_HELPER
>  select DRM_TTM
>   help

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

[PATCH v8 18/18] drm/virtio: kconfig: Fixup white space.

[Lee Jones]

On Fri, 26 Aug 2016, Peter Griffin wrote:

> Use tabs instead of spaces.
> 
> Signed-off-by: Peter Griffin 
> ---
>  drivers/gpu/drm/virtio/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

For my own reference:
  Acked-by: Lee Jones 

> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index 90357d9..2d83932 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
>   tristate "Virtio GPU driver"
>   depends on DRM
>   select VIRTIO
> -select DRM_KMS_HELPER
> -select DRM_TTM
> + select DRM_KMS_HELPER
> + select DRM_TTM
>   help
>  This is the virtual GPU driver for virtio.  It can be used with
> -   QEMU based VMMs (like KVM or Xen).
> +QEMU based VMMs (like KVM or Xen).
>  
>  If unsure say M.

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

[PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

[Eric Engestrom]

On Fri, Aug 26, 2016 at 06:50:56PM +0100, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
> provides several other useful intermediate levels such as NOTICE and
> WARNING. So this patch fills out the set by providing simple macros for
> the additional levels. We don't provide _DEV_ or _ONCE or RATELIMITED
> versions yet as it seems unlikely that they'll be as useful.
> 
> v2:
> Fix whitespace, missing ## (Eric Engestrom)
> v5:
> Much simplified after underlying functions were reworked.
> 
> Signed-off-by: Dave Gordon 
> Previously-Reviewed-by: Eric Engestrom  (v2)

My r-b still stands on the v5 (and I really like the simplification!)
Thanks for CC'ing me on the updates :)

Cheers,
  Eric

> Cc: Eric Engestrom 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  include/drm/drmP.h | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 94eb138..cd52624 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -168,6 +168,13 @@ void drm_printk(const char *level, unsigned int category,
>  /** \name Macros to make printk easier */
>  /*@{*/
>  
> +#define DRM_INFO(fmt, ...)   \
> + drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
> +#define DRM_NOTE(fmt, ...)   \
> + drm_printk(KERN_NOTICE, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
> +#define DRM_WARN(fmt, ...)   \
> + drm_printk(KERN_WARNING, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
> +
>  /**
>   * Error output.
>   *
> @@ -202,8 +209,6 @@ void drm_printk(const char *level, unsigned int category,
>  #define DRM_DEV_INFO(dev, fmt, ...)  \
>   drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
>  ##__VA_ARGS__)
> -#define DRM_INFO(fmt, ...)   \
> - drm_printk(KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
>  
>  #define DRM_DEV_INFO_ONCE(dev, fmt, ...) \
>  ({   \
> -- 
> 1.9.1
> 

[PATCH 2/2] libdrm: add etnaviv tests

[Rob Clark]

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

well, I guess you wouldn't run these tests on, for example radeon hw ;-)

but using common framework isn't a horrible idea..  one of these days
I'd like to move my few msmtest's to igt.. but, $bigger_fires ;-)

BR,
-R

> But up to you really.
> -Daniel
>>
>> Signed-off-by: Christian Gmeiner 
>> Signed-off-by: Lucas Stach 
>> ---
>>  .gitignore  |3 +
>>  configure.ac|1 +
>>  tests/Makefile.am   |4 +
>>  tests/etnaviv/Makefile.am   |   41 +
>>  tests/etnaviv/cmdstream.xml.h   |  218 +
>>  tests/etnaviv/etnaviv_2d_test.c |  238 +
>>  tests/etnaviv/etnaviv_bo_cache_test.c   |  122 +++
>>  tests/etnaviv/etnaviv_cmd_stream_test.c |  123 +++
>>  tests/etnaviv/state.xml.h   |  348 
>>  tests/etnaviv/state_2d.xml.h| 1473 
>> +++
>>  tests/etnaviv/write_bmp.c   |  152 
>>  tests/etnaviv/write_bmp.h   |   34 +
>>  12 files changed, 2757 insertions(+)
>>  create mode 100644 tests/etnaviv/Makefile.am
>>  create mode 100644 tests/etnaviv/cmdstream.xml.h
>>  create mode 100644 tests/etnaviv/etnaviv_2d_test.c
>>  create mode 100644 tests/etnaviv/etnaviv_bo_cache_test.c
>>  create mode 100644 tests/etnaviv/etnaviv_cmd_stream_test.c
>>  create mode 100644 tests/etnaviv/state.xml.h
>>  create mode 100644 tests/etnaviv/state_2d.xml.h
>>  create mode 100644 tests/etnaviv/write_bmp.c
>>  create mode 100644 tests/etnaviv/write_bmp.h
>>
>> diff --git a/.gitignore b/.gitignore
>> index 3226b3a..d51e619 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -102,4 +102,7 @@ tests/radeon/radeon_ttm
>>  tests/exynos/exynos_fimg2d_event
>>  tests/exynos/exynos_fimg2d_perf
>>  tests/exynos/exynos_fimg2d_test
>> +tests/etnaviv/etnaviv_2d_test
>> +tests/etnaviv/etnaviv_cmd_stream_test
>> +tests/etnaviv/etnaviv_bo_cache_test
>>  man/*.3
>> diff --git a/configure.ac b/configure.ac
>> index 64f3e6c..330358a 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -551,6 +551,7 @@ AC_CONFIG_FILES([
>>   tests/exynos/Makefile
>>   tests/tegra/Makefile
>>   tests/nouveau/Makefile
>> + tests/etnaviv/Makefile
>>   tests/util/Makefile
>>   man/Makefile
>>   libdrm.pc])
>> diff --git a/tests/Makefile.am b/tests/Makefile.am
>> index 58feb12..4a499e4 100644
>> --- a/tests/Makefile.am
>> +++ b/tests/Makefile.am
>> @@ -22,6 +22,10 @@ if HAVE_TEGRA
>>  SUBDIRS += tegra
>>  endif
>>
>> +if HAVE_ETNAVIV
>> +SUBDIRS += etnaviv
>> +endif
>> +
>>  AM_CFLAGS = \
>>   $(WARN_CFLAGS)\
>>   -I $(top_srcdir)/include/drm \
>> diff --git a/tests/etnaviv/Makefile.am b/tests/etnaviv/Makefile.am
>> new file mode 100644
>> index 000..0631864
>> --- /dev/null
>> +++ b/tests/etnaviv/Makefile.am
>> @@ -0,0 +1,41 @@
>> +AM_CFLAGS = \
>> + -I $(top_srcdir)/include/drm \
>> + -I $(top_srcdir)/etnaviv \
>> + -I $(top_srcdir)
>> +
>> +if HAVE_INSTALL_TESTS
>> +bin_PROGRAMS = \
>> + etnaviv_2d_test \
>> + etnaviv_cmd_stream_test \
>> + etnaviv_bo_cache_test
>> +else
>> +noinst_PROGRAMS = \
>> + etnaviv_2d_test \
>> + etnaviv_cmd_stream_test \
>> + etnaviv_bo_cache_test
>> +endif
>> +
>> +etnaviv_2d_test_LDADD = \
>> + $(top_builddir)/libdrm.la \
>> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
>> +
>> +etnaviv_2d_test_SOURCES = \
>> + cmdstream.xml.h \
>> + etnaviv_2d_test.c \
>> + state.xml.h \
>> + state_2d.xml.h \
>> + write_bmp.c \
>> + write_bmp.h
>> +
>> +etnaviv_cmd_stream_test_LDADD = \
>> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
>> +
>> +etnaviv_cmd_stream_test_SOURCES = \
>> + etnaviv_cmd_stream_test.c
>> +
>> +etnaviv_bo_cache_test_LDADD = \
>> + $(top_builddir)/libdrm.la \
>> + $(top_builddir)/etnaviv/libdrm_etnaviv.la
>> +
>> +etnaviv_bo_cache_test_SOURCES = \
>> + etnaviv_bo_cache_test.c
>> diff --git a/tests/etnaviv/cmdstream.xml.h b/tests/etnaviv/cmdstream.xml.h
>> new file mode 100644
>> index 000..844f829
>> --- /dev/null
>> +++ b/tests/etnaviv/cmdstream.xml.h
>> @@ 

[RFC 2/2] gpu: ipu-v3: reset DMFC memory when disabling

[Ying Liu]

On Mon, Aug 29, 2016 at 6:33 PM, Philipp Zabel  
wrote:
> Reset the write FIFO memories after disabling the DMFC
> to make sure no stale data is kept around.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
> index a40f211..e1e5506 100644
> --- a/drivers/gpu/ipu-v3/ipu-dmfc.c
> +++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
> @@ -131,8 +131,10 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)
>
> priv->use_count--;
>
> -   if (!priv->use_count)
> +   if (!priv->use_count) {
> ipu_module_disable(priv->ipu, IPU_CONF_DMFC_EN);
> +   ipu_memory_reset(priv->ipu, IPU_RST_MEM_DMFC_WR);

We've got use counter for DMFC as DMFC can be used by several channels
simultaneously.  That means only the last user may trigger the DMFC_WR
memory reset operation.  I assume this is not what we want - we need
every channel's dedicated DMFC write memory could be reset separately.
However, it looks that the hardware hasn't got the capability to do that.
I think writing 1 to DMFC_WR resets all DMFC writing channels' memory.

Regards,
Liu Ying

> +   }
>
> if (priv->use_count < 0)
> priv->use_count = 0;
> --
> 2.8.1
>

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

[Jani Nikula]

On Mon, 29 Aug 2016, Andrea Arcangeli  wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> CC'ed Martin who filed the bz, he can reproduce too
> https://bugzilla.kernel.org/show_bug.cgi?id=151731
>
> Since you can reproduce would you have the time to test the two above
> options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
> I won't be able to test it today and I'll be mostly offline for a week
> starting tomorrow.

As I tried to explain, the low voltage swing is not related to backlight
issues.

BR,
Jani.

>
> Thanks,
> Andrea

-- 
Jani Nikula, Intel Open Source Technology Center

[GIT PULL] imx-drm atomic modeset regression fixes

[Philipp Zabel]

Hi Dave,

this tag contains two fixes for regressions introduced by the atomic
modeset conversion. The first adds active plane reconfiguration support
via modesets (otherwise starting weston with fbdev emulation and
framebuffer console enabled would result in a black screen), and the
second adds back the drm_crtc_vblank_on/off notification.

The active plane reconfiguration support patch is v2 on the list. I'll
update this to the latest v4 version of the patch (that grew a
dependency on current drm-misc) with the next imx-drm/next pull request.

regards
Philipp

The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2016-08-30

for you to fetch changes up to a474478642d57641ea06645104a15acc0420f01a:

  drm/imx: fix crtc vblank state regression (2016-08-30 08:35:22 +0200)


imx-drm atomic modeset regression fixes

- add active plane reconfiguration support
- add back crtc vblank state reporting


Liu Ying (1):
  drm/imx: Add active plane reconfiguration support

Lucas Stach (1):
  drm/imx: fix crtc vblank state regression

 drivers/gpu/drm/imx/imx-drm-core.c | 26 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  4 
 drivers/gpu/drm/imx/ipuv3-plane.c  | 21 ++---
 3 files changed, 43 insertions(+), 8 deletions(-)

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

[Bjorn Andersson]

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.

Regards,
Bjorn

[PATCH] drm/imx: fix crtc vblank state regression

[Philipp Zabel]

Am Montag, den 29.08.2016, 17:51 +0200 schrieb Lucas Stach:
> The atomic conversion lost the notification to let the DRM core
> know about the current state of the CRTC vblank interrupts. This
> regressed the ability of the core to reject page flip attempts
> on currently disabled CRTCs. Add back the notifications.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 08e188bc10fc..462056e4b9e4 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -76,6 +76,8 @@ static void ipu_crtc_disable(struct drm_crtc *crtc)
>   crtc->state->event = NULL;
>   }
>   spin_unlock_irq(>dev->event_lock);
> +
> + drm_crtc_vblank_off(crtc);
>  }
>  
>  static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> @@ -175,6 +177,8 @@ static int ipu_crtc_atomic_check(struct drm_crtc *crtc,
>  static void ipu_crtc_atomic_begin(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state)
>  {
> + drm_crtc_vblank_on(crtc);
> +
>   spin_lock_irq(>dev->event_lock);
>   if (crtc->state->event) {
>   WARN_ON(drm_crtc_vblank_get(crtc));

Applied, thanks.

regards
Philipp

[PATCH 2/2] libdrm: add etnaviv tests

[Christian Gmeiner]

From: The etnaviv authors 

This adds the following basic unit tests:

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

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

- etnaviv_cmd_stream_test
  Tests for the etna_cmd_stream API.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
---
 .gitignore  |3 +
 configure.ac|1 +
 tests/Makefile.am   |4 +
 tests/etnaviv/Makefile.am   |   41 +
 tests/etnaviv/cmdstream.xml.h   |  218 +
 tests/etnaviv/etnaviv_2d_test.c |  238 +
 tests/etnaviv/etnaviv_bo_cache_test.c   |  122 +++
 tests/etnaviv/etnaviv_cmd_stream_test.c |  123 +++
 tests/etnaviv/state.xml.h   |  348 
 tests/etnaviv/state_2d.xml.h| 1473 +++
 tests/etnaviv/write_bmp.c   |  152 
 tests/etnaviv/write_bmp.h   |   34 +
 12 files changed, 2757 insertions(+)
 create mode 100644 tests/etnaviv/Makefile.am
 create mode 100644 tests/etnaviv/cmdstream.xml.h
 create mode 100644 tests/etnaviv/etnaviv_2d_test.c
 create mode 100644 tests/etnaviv/etnaviv_bo_cache_test.c
 create mode 100644 tests/etnaviv/etnaviv_cmd_stream_test.c
 create mode 100644 tests/etnaviv/state.xml.h
 create mode 100644 tests/etnaviv/state_2d.xml.h
 create mode 100644 tests/etnaviv/write_bmp.c
 create mode 100644 tests/etnaviv/write_bmp.h

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

+if HAVE_ETNAVIV
+SUBDIRS += etnaviv
+endif
+
 AM_CFLAGS = \
$(WARN_CFLAGS)\
-I $(top_srcdir)/include/drm \
diff --git a/tests/etnaviv/Makefile.am b/tests/etnaviv/Makefile.am
new file mode 100644
index 000..0631864
--- /dev/null
+++ b/tests/etnaviv/Makefile.am
@@ -0,0 +1,41 @@
+AM_CFLAGS = \
+   -I $(top_srcdir)/include/drm \
+   -I $(top_srcdir)/etnaviv \
+   -I $(top_srcdir)
+
+if HAVE_INSTALL_TESTS
+bin_PROGRAMS = \
+   etnaviv_2d_test \
+   etnaviv_cmd_stream_test \
+   etnaviv_bo_cache_test
+else
+noinst_PROGRAMS = \
+   etnaviv_2d_test \
+   etnaviv_cmd_stream_test \
+   etnaviv_bo_cache_test
+endif
+
+etnaviv_2d_test_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_2d_test_SOURCES = \
+   cmdstream.xml.h \
+   etnaviv_2d_test.c \
+   state.xml.h \
+   state_2d.xml.h \
+   write_bmp.c \
+   write_bmp.h
+
+etnaviv_cmd_stream_test_LDADD = \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_cmd_stream_test_SOURCES = \
+   etnaviv_cmd_stream_test.c
+
+etnaviv_bo_cache_test_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/etnaviv/libdrm_etnaviv.la
+
+etnaviv_bo_cache_test_SOURCES = \
+   etnaviv_bo_cache_test.c
diff --git a/tests/etnaviv/cmdstream.xml.h b/tests/etnaviv/cmdstream.xml.h
new file mode 100644
index 000..844f829
--- /dev/null
+++ b/tests/etnaviv/cmdstream.xml.h
@@ -0,0 +1,218 @@
+#ifndef CMDSTREAM_XML
+#define CMDSTREAM_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://0x04.net/cgit/index.cgi/rules-ng-ng
+git clone git://0x04.net/rules-ng-ng
+
+The rules-ng-ng source files this header was generated from are:
+- /home/orion/projects/etna_viv/rnndb/cmdstream.xml (  12589 bytes, from 
2013-09-01 10:53:22)
+- /home/orion/projects/etna_viv/rnndb/common.xml(  18379 bytes, from 
2014-01-27 15:58:05)
+
+Copyright (C) 2013
+*/
+
+
+#define FE_OPCODE_LOAD_STATE   0x0001
+#define FE_OPCODE_END  0x0002
+#define FE_OPCODE_NOP  0x0003
+#define FE_OPCODE_DRAW_2D  0x0004
+#define FE_OPCODE_DRAW_PRIMITIVES  0x0005
+#define FE_OPCODE_DRAW_INDEXED_PRIMITIVES  0x0006
+#define FE_OPCODE_WAIT 

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

[Christian Gmeiner]

From: The etnaviv authors 

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

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

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

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

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

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

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

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

[PATCH 0/2] etnaviv_libdrm

[Christian Gmeiner]

as the original patchstack is now about 70 patches, I have choosen to
squash the patches together into two seperate parts. The libdrm_etnaviv
implementation and tests. All seperate patches can be found here:
https://github.com/austriancoder/libdrm/tree/master

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

Happy reviewing!

Christian

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

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

-- 
2.7.4

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Russell King - ARM Linux]

On Mon, Aug 29, 2016 at 05:41:10PM +0100, Emil Velikov wrote:
> Hi all,
> 
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
>  wrote:
> 
> >  MODULE_AUTHOR("Sascha Hauer ");
> >  MODULE_AUTHOR("Andy Yan ");
> >  MODULE_AUTHOR("Yakir Yang ");
> > +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant to start a flame-war or alike but to educate myself:
> Where does one draw the line about adding new author(s) of said
> module/subsystem ?
> 
> Afaict this is the most common (?) driver in DRM where the list has
> grown over time. Should we do the same with others ?

... and I'm responsible for just over half the commits in the mainline
kernel and I haven't added myself.  I generally only add myself if I'm
creating new code or been involved in adding new code, I don't add if
I'm merely modifying existing code unless I've replaced a large
quantity of the code.  I think the question people need to ask is:

  "Have I contributed a significant set of changes to be able to claim
   shared authorship of that code?"

You wouldn't claim authorship of a 500 page book if you suggested a
few edits here and there.

Looking at co-authorship in google, I came across:

http://www.southernfriedscience.com/to-co-author-or-not-to-co-author/

which has an interesting list of points on this subject, although more
biased to research papers, which is where this problem normally arises.
That seems to back up my idea of "significant contribution" not just
a few minor changes.

The question then becomes... what is a significant contribution. :)

-- 
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 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Martin van Es]

Hi Andrea,

I'd be happy to test, but what am I testing when applying these boot 
parameters? In other words: what should I report?

And just to be sure, I THINK I own an IVB but intel is not very vocal about it 
when searching for familyname. I have a

vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
stepping: 9
microcode   : 0x17

Regards,
Martin

On maandag 29 augustus 2016 20:48:43 CEST Andrea Arcangeli wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> > If it's an Iybridge, there's no low vswing, and that explanation is
> > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> > on an unpatched kernel.
> 
> CC'ed Martin who filed the bz, he can reproduce too
> https://bugzilla.kernel.org/show_bug.cgi?id=151731
> 
> Since you can reproduce would you have the time to test the two above
> options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
> I won't be able to test it today and I'll be mostly offline for a week
> starting tomorrow.
> 
> Thanks,
> Andrea

Kernel Freeze with American Megatrends BIOS

[Bjorn Helgaas]

On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
> Thanks for pointing it out.
> 
> Yeah that's right. The system will hang randomly a few minutes later,
> because some certain actions in the graphical user session will trigger
> the freeze.
> 
> I had a look at the function body of pci_read_config_dword:
> 
>   #define PCI_OP_READ(size, type, len) \
>   int pci_bus_read_config_##size \
>   (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \
>   {   \
>   int res;\
>   unsigned long flags;\
>   u32 data = 0;   \
>   if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER;   \
>   raw_spin_lock_irqsave(_lock, flags);\
>   res = bus->ops->read(bus, devfn, pos, len, );  \
>   *value = (type)data;\
>   raw_spin_unlock_irqrestore(_lock, flags);   \
>   return res; \
>   }
> 
> I guess, that bus->ops->read(...) might be the trigger.
> Any hints how to continue debugging?

It's not likely that the problem is in the bus->ops->read() path.  That
is used by every device driver, so a problem there would cause more
serious problems than what you're seeing.

My guess would be some problem in the video driver or the bbswitch
thing.

> Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas:
> > On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
> >> Just tried it and the system didn't freeze. However it will freeze
> >> after some time (few minutes while working).
> >>
> >> Seams to be pci_read_config_dword. Where is this exactly defined?
> > 
> > pci_read_config_dword() is defined in include/linux/pci.h.  It calls
> > pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro
> > in drivers/pci/access.c.
> > 
> > If I understand correctly, this:
> > 
> >   dis_dev_get();
> >   pci_read_config_dword(dis_dev, 0, _word);
> >   dis_dev_put();
> > 
> > causes an immediate system hang, but if you only do this:
> > 
> >   dis_dev_get();
> >   dis_dev_put();
> > 
> > the system hangs a few minutes later.  Right?
> > 
> >> Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
> >>> On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
>  Hi Bjorn,
> 
>  I am using the bbswitch kernel module to switch off/on the GPU and
>  to obtain the GPU power state.
>  Obtaining the GPU state immediately after starting the graphical user
>  session freezes the system.
> 
>  This code triggers something, which is responsible for the freeze.
> 
>  ---
>  // Returns 1 if the card is disabled, 0 if enabled
>  static int is_card_disabled(void) {
>  u32 cfg_word;
>  // read first config word which contains Vendor and Device ID. If 
>  all bits
>  // are enabled, the device is assumed to be off
>  pci_read_config_dword(dis_dev, 0, _word);
>  // if one of the bits is not enabled (the card is enabled), the 
>  inverted
>  // result will be non-zero and hence logical not will make it 0 
>  ("false")
>  return !~cfg_word;
>  }
> 
>  static int bbswitch_proc_show(struct seq_file *seqfp, void *p) {
>  // show the card state. Example output: :01:00:00 ON
>  dis_dev_get();
>  seq_printf(seqfp, "%s %s\n", dev_name(_dev->dev),
>   is_card_disabled() ? "OFF" : "ON");
>  dis_dev_put();
>  return 0;
>  }
>  ---
> 
>  Either dis_dev_get or pci_read_config_dword is the trigger.
> >>>
> >>> What happens if you remove the call to is_card_disabled()?  Does the
> >>> system still freeze if you only do the dis_dev_get()/dis_dev_put()?
> >>>
>  Link to the bbswitch module source code:
>  https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
> 
> 
>  Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
> > [+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?
> >
> > On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
> >> Hi,
> >>
> >> hope somebody can help me fix this kernel problem which affects the 
> >> following machines:
> >>
> >> - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which 
> >> are also affected)
> >> - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
> >> - Gigabyte P35V5 (i7-6700HQ/GTX 970M)
> >> - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
> >>
> >>
> >> The kernel freezes if the graphical user session (Xorg & Wayland) is
> >> 

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

[Randy Li]

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>;
+   };
 };

 _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 = <>;
+   };
+   };
+};
-- 
2.7.4

[PATCH v2] drm/fsl-dcu: Fix endian issue when using clk_register_divider

[Meng Yi]

> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > b/drivers/gpu/drm/fsl- dcu/fsl_dcu_drm_drv.c index 7882387..a590ce8
> > 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > @@ -386,7 +386,8 @@ static int fsl_dcu_drm_probe(struct
> > platform_device
> > *pdev)
> > snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix",
> > pix_clk_in_name);
> > fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
> > pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> > -   0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> > +   !strcmp(fsl_dev->soc->name, "ls1021a")?24:0, 8,
> > +   CLK_DIVIDER_ROUND_CLOSEST, NULL);
> 
> Tested-by: Meng Yi 

On LS1021A-TWR board.
> 
> > if (IS_ERR(fsl_dev->pix_clk)) {
> > dev_err(dev, "failed to register pix clk\n");
> > ret = PTR_ERR(fsl_dev->pix_clk);
> > --
> > 2.1.0.27.g96db324

[PATCH v2] drm/fsl-dcu: Fix endian issue when using clk_register_divider

[Meng Yi]

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_drv.c
> index 7882387..a590ce8 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -386,7 +386,8 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
>   snprintf(pix_clk_name, sizeof(pix_clk_name), "%s_pix",
> pix_clk_in_name);
>   fsl_dev->pix_clk = clk_register_divider(dev, pix_clk_name,
>   pix_clk_in_name, 0, base + DCU_DIV_RATIO,
> - 0, 8, CLK_DIVIDER_ROUND_CLOSEST, NULL);
> + !strcmp(fsl_dev->soc->name, "ls1021a")?24:0, 8,
> + CLK_DIVIDER_ROUND_CLOSEST, NULL);

Tested-by: Meng Yi 

>   if (IS_ERR(fsl_dev->pix_clk)) {
>   dev_err(dev, "failed to register pix clk\n");
>   ret = PTR_ERR(fsl_dev->pix_clk);
> --
> 2.1.0.27.g96db324

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

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

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

--- Comment #2 from Malcolm Lewis  ---
Created attachment 126111
  --> https://bugs.freedesktop.org/attachment.cgi?id=126111=edit
Ourput from dmesg

-- 
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/20160830/37b7488e/attachment-0001.html>

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

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

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

--- Comment #1 from Michel Dänzer  ---
Please attach the corresponding dmesg output.

-- 
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/20160830/806ee25f/attachment.html>

[Bug 92912] Full GPU lockups in TF2 - R600

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

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

Vedran Miletić  changed:

   What|Removed |Added

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

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

[Bug 92912] Full GPU lockups in TF2 - R600

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

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

--- Comment #8 from hofmann.zachary at gmail.com ---
It's definitely fixed now, just disappointed that in this whole time the bug
never got recognized.

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