Enable AMDGPU for CIK by default

[Kai Wasserbäch]

Hey everybody,
Sandeep wrote on 06.11.2016 19:56:
> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
> upstream kernel (or is this upto individual distros?)
> 
> Is there any work left to be done/bugs to be fixed before it can be enabled
> by default?

just some feedback on this: I've been using amdgpu since 4.7 (end of of 4.6 to
be precise) with my Hawaii Pro (R9 290) and haven't observed any issues because
of the change. The performance seems to be identical or within the margin of
error, when compared to radeon.

As far as I'm concerned a switch for CIK to amdgpu would be fine. ;-)

Cheers,
Kai

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

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #6 from smoki  ---

 That was pure information :), as i tried to reproduce it with that old
affected one and newest which does not have an issue since it does not have
decode... so no offense, bug is there.

-- 
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/20161106/ad9f1d10/attachment.html>

[Bug 98619] amdgpu 0000:01:00.0: GPU fault detected: 146 0x09d88404 (Shadow of Mordor)

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

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

Bug ID: 98619
   Summary: amdgpu :01:00.0: GPU fault detected: 146
0x09d88404 (Shadow of Mordor)
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: marco.grimaldi at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 127805
  --> https://bugs.freedesktop.org/attachment.cgi?id=127805=edit
dmesg output

Hi,

Shadow of Mordor freezes randomly, but regularly.
AMD rx480
Linux 4.8.6-1-ARCH #1 SMP PREEMPT
X.Org X Server 1.18.4
Release Date: 2016-07-19

dmesg: see attachment

Xorg.0.log (after reboot):
[ 3.767] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[ 3.767] X Protocol Version 11, Revision 0
[ 3.767] Build Operating System: Linux 4.5.4-1-ARCH x86_64 
[ 3.767] Current Operating System: Linux moby 4.8.6-1-ARCH #1 SMP PREEMPT
Mon Oct 31 18:51:30 CET 2016 x86_64
[ 3.767] Kernel command line: BOOT_IMAGE=/vmlinuz-linux
root=UUID=2b402667-cf03-48e1-9d18-117f4accc01c rw quiet
resume=UUID=0db00e31-4a18-4edf-aa40-8cd9c3c2393d
[ 3.767] Build Date: 19 July 2016  05:54:24PM
[ 3.767]  
[ 3.767] Current version of pixman: 0.34.0
[ 3.767]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 3.767] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 3.767] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov  6 19:59:27
2016
[ 3.769] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 3.769] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 3.770] (==) No Layout section.  Using the first Screen section.
[ 3.770] (==) No screen section available. Using defaults.
[ 3.771] (**) |-->Screen "Default Screen Section" (0)
[ 3.771] (**) |   |-->Monitor ""
[ 3.771] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[ 3.771] (**) |   |-->Device "AMD"
[ 3.771] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 3.771] (**) Option "DontZap" "false"
[ 3.771] (==) Automatically adding devices
[ 3.771] (==) Automatically enabling devices
[ 3.771] (==) Automatically adding GPU devices
[ 3.771] (==) Max clients allowed: 256, resource mask: 0x1f
[ 3.773] (WW) The directory "/usr/share/fonts/Type1/" does not exist.
[ 3.773]Entry deleted from font path.
[ 3.773] (WW) `fonts.dir' not found (or not valid) in
"/usr/share/fonts/100dpi/".
[ 3.773]Entry deleted from font path.
[ 3.773](Run 'mkfontdir' on "/usr/share/fonts/100dpi/").
[ 3.774] (WW) `fonts.dir' not found (or not valid) in
"/usr/share/fonts/75dpi/".
[ 3.774]Entry deleted from font path.
[ 3.774](Run 'mkfontdir' on "/usr/share/fonts/75dpi/").
[ 3.774] (==) FontPath set to:
/usr/share/fonts/misc/,
/usr/share/fonts/TTF/,
/usr/share/fonts/OTF/
[ 3.774] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 3.774] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[ 3.774] (II) Loader magic: 0x821d40
[ 3.774] (II) Module ABI versions:
[ 3.774]X.Org ANSI C Emulation: 0.4
[ 3.774]X.Org Video Driver: 20.0
[ 3.774]X.Org XInput driver : 22.1
[ 3.774]X.Org Server Extension : 9.0
[ 3.775] (++) using VT number 7

[ 3.775] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[ 3.777] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 3.795] (--) PCI:*(0:1:0:0) 1002:67df:174b:e347 rev 199, Mem @
0xe000/268435456, 0xf000/2097152, 0xf7e0/262144, I/O @
0xe000/256, BIOS @ 0x/131072
[ 3.795] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or
directory)
[ 3.795] (II) LoadModule: "glx"
[ 3.797] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 3.807] (II) Module glx: vendor="X.Org Foundation"
[ 3.807]compiled for 1.18.4, module version = 1.0.0
[ 3.807]ABI class: X.Org Server Extension, version 9.0
[ 3.807] (==) AIGLX enabled
[ 3.807] (II) LoadModule: "amdgpu"
[ 3.807] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[ 3.810] (II) Module amdgpu: vendor="X.Org Foundation"
[ 3.810]compiled for 1.18.4, module version = 1.1.2
[ 3.810]Module class: X.Org Video Driver
[

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #5 from Chris Rankin  ---
(In reply to smoki from comment #4)
> In couple months 11.2.x seems will cease to be supported anymore, so this
> might be time fixable... well in case they did not decide to enable VDPAU
> again :)

I don't see your point here. AFAIK the Flash plugin knows nothing about either
DRI2 or DRI3, and it works fine with DRI2. So why shouldn't it work with DRI3
too? Especially since Broadwell + DRI3 is unaffected.

To my mind, the Flash plugin has probably revealed a bug in Gallium's DRI3
layer. In which case, hoping that Adobe will "shoot the messenger" soon is just
silly.

-- 
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/20161106/09b7fee7/attachment.html>

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #4 from smoki  ---

 But yeah newer does not have VDPAU support, neither this 24 beta it seems:

 http://labs.adobe.com/downloads/flashplayer.html

 In couple months 11.2.x seems will cease to be supported anymore, so this
might be time fixable... well in case they did not decide to enable VDPAU again
:)

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

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #3 from smoki  ---

 Reproducable on Kabini APU too. DRI3 issue yes, it works only in DRI2 session,
but LIBGL_DRI3_DISABLE=1 does not help in this case.

-- 
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/20161106/52f5c97e/attachment.html>

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

[Maxime Ripard]

On Sat, Nov 05, 2016 at 11:54:28PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
>  wrote:
> > The A33 has a significantly different pipeline, with components that differ
> > too.
> >
> > Make sure we had compatible for them.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++-
> >  drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
> >  drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +---
> >  drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 +++-
> >  4 files changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index df8f4aeefe4c..bd3136a5cba5 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -26,7 +26,9 @@ TCON
> >  The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> >
> >  Required properties:
> > - - compatible: value should be "allwinner,sun5i-a13-tcon".
> > + - compatible: value must be either:
> > +   * allwinner,sun5i-a13-tcon
> > +   * allwinner,sun8i-a33-tcon
> >   - reg: base address and size of memory-mapped region
> >   - interrupts: interrupt associated to this IP
> >   - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > @@ -59,6 +61,7 @@ system.
> >  Required properties:
> >- compatible: value must be one of:
> >  * allwinner,sun5i-a13-display-backend
> > +* allwinner,sun8i-a33-display-backend
> >- reg: base address and size of the memory-mapped region.
> >- clocks: phandles to the clocks feeding the frontend and backend
> >  * ahb: the backend interface clock
> > @@ -80,6 +83,7 @@ deinterlacing and color space conversion.
> >  Required properties:
> >- compatible: value must be one of:
> >  * allwinner,sun5i-a13-display-frontend
> > +* allwinner,sun8i-a33-display-frontend
> 
> I just looked at the A23. It seems it's the same display frontend as the A33.
> Should we change the compatible string to a23 while it's still in RC?
> 
> The backend is probably different. The A33 only claims to support 2048x2048
> layers, while the A23 claims to support 8192x8192 layers.

I think we can still keep it. Especially if we're not sure, we might
need to make use of it in the future.

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: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161106/3920c312/attachment.sig>

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #6 from Lukas Jirkovsky  ---
Another trace (a big one), this time from Dreamfall Chapters. There are some
small white glitches throughout the trace (which look a bit different than the
reported glitch), but at the end of the trace there's supposed to be a liquid
dripping and it's all covered with white specks. It may be a different problem,
but it looks very similar to the one in Ethan Carter.

https://drive.google.com/open?id=0B2YvkwbBDwKYTzI4Q2V6QzNSWXM

-- 
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/20161106/a4ceee4e/attachment.html>

[PATCH] drm: panel: simple-panel: get the enable gpio as-is

[Icenowy Zheng]

The enable gpio of simple-panel may be used by a simplefb or other
driver on the panel's display before the KMS driver get load.

Get the GPIO as-is, so the panel won't be disabled, and the simplefb
can work.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..ccee4c1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -312,7 +312,7 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
return PTR_ERR(panel->supply);

panel->enable_gpio = devm_gpiod_get_optional(dev, "enable",
-GPIOD_OUT_LOW);
+GPIOD_ASIS);
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
dev_err(dev, "failed to request GPIO: %d\n", err);
-- 
2.10.1

[linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Jean-Francois Moine]

On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai  wrote:

> On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine  
> wrote:
> > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> >
> > Signed-off-by: Jean-Francois Moine 
> > ---
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
> 
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.

I started to add the H3 into the sun4i-i2s, but I am blocked with
regmap.
Many H3 registers are common with the A10, but some of them have more
or less fields, the fields may be at different offsets. And, finally,
some registers are completely different.
This would not raise any problem, except with regmap which is really
painful.

As I may understood, regmap is used to simplify suspend/resume, but, is
it useful to save the I2S register on suspend?
Practically, I am streaming some tune on my device. I suspend it for
any reason. The next morning, I resume it. Are you sure I want to
continue to hear the end of the tune?

I better think that streaming should be simply stopped on suspend.
Then, there is no need to save the playing registers, and, here I am,
there is no need to use regmap.

May I go this way?

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

Enable AMDGPU for CIK by default

[Sandeep]

Hello,

I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
upstream kernel (or is this upto individual distros?)

Is there any work left to be done/bugs to be fixed before it can be enabled
by default?

Yours sincerely,
Sandeep
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161106/b0feecc3/attachment-0001.html>

[Bug 98351] LibreOffice' OpenGL backend hangs GPU (ring 0&3 stalled)

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

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

--- Comment #4 from Clemens Eisserer  ---
Worked out of the box - maybe radeonsi supports some extensions LO requires and
r600 is missing?

After all, at least with mesa LO's OpenGL backend is not worth the trouble - it
is slow and rendering isn't pixel-perfect.

-- 
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/20161106/7ba1ddd9/attachment.html>

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #2 from Chris Rankin  ---
Broadwells work OK with DRI3, but I have now reproduced this problem with both
radeonsi and r600g.

-- 
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/20161106/a305cedf/attachment.html>

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

Chris Rankin  changed:

   What|Removed |Added

Summary|[VDPAU, radeonsi]   |[VDPAU, DRI3] Fullscreen
   |Fullscreen flash video  |flash video fails when
   |fails when hardware |hardware acceleration is
   |acceleration is enabled.|enabled.

-- 
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/20161106/32f5b47b/attachment.html>

[pull] drm/msm: fixes for 4.9

[Rob Clark]

The following changes since commit b0a6af8b34c9ad20894aa46f85f4bf59d444f286:

  drm/nouveau/acpi: fix check for power resources support (2016-11-01
14:52:03 +1000)

are available in the git repository at:

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

for you to fetch changes up to 16976085a114ae293c6fa7a463d74600ffcfeb4b:

  drm/msm: Fix error handling crashes seen when VRAM allocation fails
(2016-11-04 11:51:37 -0400)


Archit Taneja (3):
  drm/msm/dsi: Queue HPD helper work in attach/detach callbacks
  drm/msm: Set CLK_IGNORE_UNUSED flag for PLL clocks
  drm/msm: Fix error handling crashes seen when VRAM allocation fails

Rob Clark (3):
  drm/msm/mdp5: handle non-fullscreen base plane case
  drm/msm/mdp5: no scaling support on RGBn pipes for 8x16
  drm/msm/mdp5: 8x16 actually has 8 mixer stages

 drivers/gpu/drm/msm/dsi/dsi_host.c  | 14 ++--
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c  |  1 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c|  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c|  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |  4 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 46 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  9 ++---
 drivers/gpu/drm/msm/msm_drv.c   |  2 +-
 drivers/gpu/drm/msm/msm_gem_shrinker.c  |  7 ++--
 10 files changed, 55 insertions(+), 31 deletions(-)

[PATCH] drm: move allocation out of drm_get_format_name()

[Christian König]

Am 05.11.2016 um 17:49 schrieb Rob Clark:
> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom  wrote:
>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
 +typedef char drm_format_name_buf[32];
>>> Please don't use a typedef for this, just define the maximum size of
>>> characters the function might write somewhere.
>>>
>>> See the kernel coding style as well:
 In general, a pointer, or a struct that has elements that can reasonably
 be directly accessed should **never** be a typedef.
>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
>> them way too much), and your way was what I wrote at first, but Rob Clark's
>> typedef idea makes it much harder for someone to allocate a buffer of
>> the wrong size, which IMO is good thing here.
> IMHO I would make a small test program to verify this actually helps
> the compiler catch problems.  And if it does, I would stick with it.
> The coding-style should be guidelines, not something that supersedes
> common sense / practicality.

Well completely agree that we should be able to question the coding 
style rules, but when we do it we discuss this on a the mailing list 
first and then start to use it in code. Not the other way around.

>
> That is my $0.02 anyways.. if others vehemently disagree and want to
> dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
> this approach doesn't help the compiler catch issues, then it isn't
> worth it.

Yeah, exactly that's the point. If I'm not completely mistaken the 
compiler won't issue a warning here if you pass an array with the wrong 
size.

I think you need something like "struct drm_format_name_buf { char 
str[32]; };" to trigger this.

Apart from that is this function really called so often that using 
kasprintf() is a problem here? Or is there another motivation behind the 
change?

Regards,
Christian.

>
> BR,
> -R
>
>> I can rewrite the typedef out if you think it's better.
>>
>> Cheers,
>>Eric
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: move allocation out of drm_get_format_name()

[Rob Clark]

On Sun, Nov 6, 2016 at 4:47 AM, Christian König
 wrote:
> Am 05.11.2016 um 17:49 schrieb Rob Clark:
>>
>> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom  wrote:
>>>
>>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:

 Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>
> +typedef char drm_format_name_buf[32];

 Please don't use a typedef for this, just define the maximum size of
 characters the function might write somewhere.

 See the kernel coding style as well:
>
> In general, a pointer, or a struct that has elements that can
> reasonably
> be directly accessed should **never** be a typedef.
>>>
>>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
>>> them way too much), and your way was what I wrote at first, but Rob
>>> Clark's
>>> typedef idea makes it much harder for someone to allocate a buffer of
>>> the wrong size, which IMO is good thing here.
>>
>> IMHO I would make a small test program to verify this actually helps
>> the compiler catch problems.  And if it does, I would stick with it.
>> The coding-style should be guidelines, not something that supersedes
>> common sense / practicality.
>
>
> Well completely agree that we should be able to question the coding style
> rules, but when we do it we discuss this on a the mailing list first and
> then start to use it in code. Not the other way around.

if I'm not mistaken, that is what we are doing ;-)

>>
>> That is my $0.02 anyways.. if others vehemently disagree and want to
>> dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
>> this approach doesn't help the compiler catch issues, then it isn't
>> worth it.
>
>
> Yeah, exactly that's the point. If I'm not completely mistaken the compiler
> won't issue a warning here if you pass an array with the wrong size.
>
> I think you need something like "struct drm_format_name_buf { char str[32];
> };" to trigger this.

hmm, actually the struct is a nice idea then if the compiler wouldn't
catch the wrong-size-array

> Apart from that is this function really called so often that using
> kasprintf() is a problem here? Or is there another motivation behind the
> change?

Two things trouble me about the kasprintf approach.. (ignoring the
fact that atm it is not GFP_ATOMIC)
1) you can't do DRM_DEBUG("format: %s\n", drm_get_format_name(..)) so
it pulls the memory allocation and sprintf outside of the drm_debug
check
2) seems awfully easy to forget the kfree...  I wouldn't have even
known that now you need to free the result (with some patches I'm
working on) if it weren't for the fact that lockdep alerted me to the
GFP_KERNEL allocation in atomic ctx ;-)

BR,
-R

> Regards,
> Christian.
>
>
>>
>> BR,
>> -R
>>
>>> I can rewrite the typedef out if you think it's better.
>>>
>>> Cheers,
>>>Eric
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>

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

[Chen-Yu Tsai]

Hi,

On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
 wrote:
> The A33 has a significantly different pipeline, with components that differ
> too.
>
> Make sure we had compatible for them.
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++-
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 +++-
>  4 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index df8f4aeefe4c..bd3136a5cba5 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -26,7 +26,9 @@ TCON
>  The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
>
>  Required properties:
> - - compatible: value should be "allwinner,sun5i-a13-tcon".
> + - compatible: value must be either:
> +   * allwinner,sun5i-a13-tcon
> +   * allwinner,sun8i-a33-tcon
>   - reg: base address and size of memory-mapped region
>   - interrupts: interrupt associated to this IP
>   - clocks: phandles to the clocks feeding the TCON. Three are needed:
> @@ -59,6 +61,7 @@ system.
>  Required properties:
>- compatible: value must be one of:
>  * allwinner,sun5i-a13-display-backend
> +* allwinner,sun8i-a33-display-backend
>- reg: base address and size of the memory-mapped region.
>- clocks: phandles to the clocks feeding the frontend and backend
>  * ahb: the backend interface clock
> @@ -80,6 +83,7 @@ deinterlacing and color space conversion.
>  Required properties:
>- compatible: value must be one of:
>  * allwinner,sun5i-a13-display-frontend
> +* allwinner,sun8i-a33-display-frontend

I just looked at the A23. It seems it's the same display frontend as the A33.
Should we change the compatible string to a23 while it's still in RC?

The backend is probably different. The A33 only claims to support 2048x2048
layers, while the A23 claims to support 8192x8192 layers.

Regards
ChenYu

>- reg: base address and size of the memory-mapped region.
>- interrupts: interrupt associated to this IP
>- clocks: phandles to the clocks feeding the frontend and backend
> @@ -104,6 +108,7 @@ extra node.
>  Required properties:
>- compatible: value must be one of:
>  * allwinner,sun5i-a13-display-engine
> +* allwinner,sun8i-a33-display-engine
>
>- allwinner,pipelines: list of phandle to the display engine
>  frontends available.
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 3ab560450a82..9bfd2e45fceb 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -345,6 +345,7 @@ static int sun4i_backend_remove(struct platform_device 
> *pdev)
>
>  static const struct of_device_id sun4i_backend_of_table[] = {
> { .compatible = "allwinner,sun5i-a13-display-backend" },
> +   { .compatible = "allwinner,sun8i-a33-display-backend" },
> { }
>  };
>  MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 942f62e2441c..c4d03c1b6db8 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -199,13 +199,14 @@ static const struct component_master_ops 
> sun4i_drv_master_ops = {
>
>  static bool sun4i_drv_node_is_frontend(struct device_node *node)
>  {
> -   return of_device_is_compatible(node,
> -  
> "allwinner,sun5i-a13-display-frontend");
> +   return of_device_is_compatible(node, 
> "allwinner,sun5i-a13-display-frontend") ||
> +   of_device_is_compatible(node, 
> "allwinner,sun8i-a33-display-frontend");
>  }
>
>  static bool sun4i_drv_node_is_tcon(struct device_node *node)
>  {
> -   return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon");
> +   return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
> +   of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
>  }
>
>  static int compare_of(struct device *dev, void *data)
> @@ -320,6 +321,7 @@ static int sun4i_drv_remove(struct platform_device *pdev)
>
>  static const struct of_device_id sun4i_drv_of_table[] = {
> { .compatible = "allwinner,sun5i-a13-display-engine" },
> +   { .compatible = "allwinner,sun8i-a33-display-engine" },
> { }
>  };
>  MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index fde6af1230d2..cadacb517f95 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -488,8 +488,13 @@ static int 

[Bug 98604] [VDPAU, radeonsi] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #1 from Chris Rankin  ---
I think this bug is related to DRI3, because this change "fixes" the problem:

diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 81b7582..cd5afe2 100644
--- a/src/gallium/state_trackers/vdpau/device.c
+++ b/src/gallium/state_trackers/vdpau/device.c
@@ -64,7 +64,7 @@ vdp_imp_device_create_x11(Display *display, int screen,
VdpDevice *device,
pipe_reference_init(>reference, 1);

 #if defined(HAVE_DRI3)
-   dev->vscreen = vl_dri3_screen_create(display, screen);
+   //dev->vscreen = vl_dri3_screen_create(display, screen);
 #endif
if (!dev->vscreen)
   dev->vscreen = vl_dri2_screen_create(display, screen);

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