Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

2017-10-01 Thread Daniel Thompson

On 02/10/17 06:58, Daniel Thompson wrote:

On 01/10/17 18:26, Meghana Madhyastha wrote:

Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) as part of the
if directive for the function declaration of
of_find_backlight_by_node in order to avoid module dependency
errors.


Module dependency errors? Does you mean mean use of undefined symbols?


Sorry, drafting error! Could you pretend I wrote "Do you mean use of..." 
instead of the nonsense above!






Signed-off-by: Meghana Madhyastha 
---
Changes in v7:
-This patch did not exist in v6.


So I'm coming to this patchset cold but can you explain *why* something 
wants to call of_find_backlight_by_node() when there is no backlight 
support enabled. Why isn't the code that called is conditional on 
BACKLIGHT_CLASS_DEVICE?


The undefined symbol issue is a pain but to be honest I'd rather solve 
the use of undefined symbols by avoiding declaring them; this making 
them into compile errors rather than link errors.




  include/linux/backlight.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f2fd61..a52ce82 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,7 +162,7 @@ struct generic_bl_info {
  void (*kick_battery)(void);
  };
-#ifdef CONFIG_OF
+#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)


The above comments are more important but why does this mix defined and 
IS_ENABLED? Couldn't they both use defined (and preferably with the 
optional brackets around the CONFIG_ symbol).



Daniel.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

2017-10-01 Thread Daniel Thompson

On 01/10/17 18:26, Meghana Madhyastha wrote:

Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) as part of the
if directive for the function declaration of
of_find_backlight_by_node in order to avoid module dependency
errors.


Module dependency errors? Does you mean mean use of undefined symbols?



Signed-off-by: Meghana Madhyastha 
---
Changes in v7:
-This patch did not exist in v6.


So I'm coming to this patchset cold but can you explain *why* something 
wants to call of_find_backlight_by_node() when there is no backlight 
support enabled. Why isn't the code that called is conditional on 
BACKLIGHT_CLASS_DEVICE?


The undefined symbol issue is a pain but to be honest I'd rather solve 
the use of undefined symbols by avoiding declaring them; this making 
them into compile errors rather than link errors.




  include/linux/backlight.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f2fd61..a52ce82 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,7 +162,7 @@ struct generic_bl_info {
void (*kick_battery)(void);
  };
  
-#ifdef CONFIG_OF

+#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)


The above comments are more important but why does this mix defined and 
IS_ENABLED? Couldn't they both use defined (and preferably with the 
optional brackets around the CONFIG_ symbol).



Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/18] use ARRAY_SIZE macro

2017-10-01 Thread Greg KH
On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote:
> On Mon, 2 Oct 2017 09:01:31 +1100
> "Tobin C. Harding"  wrote:
> 
> > > In order to reduce the size of the To: and Cc: lines, each patch of the
> > > series is sent only to the maintainers and lists concerned by the patch.
> > > This cover letter is sent to every list concerned by this series.  
> > 
> > Why don't you just send individual patches for each subsystem? I'm not a 
> > maintainer but I don't see
> > how any one person is going to be able to apply this whole series, it is 
> > making it hard for
> > maintainers if they have to pick patches out from among the series (if 
> > indeed any will bother
> > doing that).
> Yeah, maybe it would have been better to send individual patches.
> 
> From my point of view it's a series because the patches are related (I
> did a git format-patch from my local branch). But for the maintainers
> point of view, they are individual patches.

And the maintainers view is what matters here, if you wish to get your
patches reviewed and accepted...

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

2017-10-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196615

--- Comment #17 from Peter Spiess-Knafl (p...@autistici.org) ---
Same for me here. Arch 4.13.3. Was the original patch reapplied?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] drm/nouveau: Document nouveau support for Tegra in DRIVER_DESC

2017-10-01 Thread Rhys Kidd
nouveau supports the Tegra K1 and higher after the SoC-based GPUs converged
with the main GeForce GPU families.

v2:
- Qualify that support is Tegra K1+ (Martin Peres)

Signed-off-by: Rhys Kidd 
Reviewed-by: Martin Peres 
Acked-by: Pierre Moreau 
---
 drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 822fe1d4d35e..ec60d52790e3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -5,7 +5,7 @@
 #define DRIVER_EMAIL   "nouv...@lists.freedesktop.org"
 
 #define DRIVER_NAME"nouveau"
-#define DRIVER_DESC"nVidia Riva/TNT/GeForce/Quadro/Tesla"
+#define DRIVER_DESC"nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra K1+"
 #define DRIVER_DATE"20120801"
 
 #define DRIVER_MAJOR   1
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Nouveau nullptr on NVIDIA NVA8

2017-10-01 Thread Woody Suwalski
Starting with the drm merge af3c8d98508d37541d4bf57f13a984a7f73a328c for 
4.13-rc1, the NVidia NVS3100M display on Dell Latitude E6410 had a 
nullptr crash on startup. As a result later the suspend2ram was locking 
up. Traced to a null ptr in nv50_mstm_service(), which seems to be 
called only from

nouveau_connector_hotplug().

Fixed by checking if mstm is not NULL before calling the service function.

[1.176456] Linux agpgart interface v0.103
[1.176610] [drm] radeon kernel modesetting enabled.
[1.17] [drm] amdgpu kernel modesetting enabled.
[1.176749] ACPI Warning: \_SB.PCI0.AGP.VID._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20170531/nsarguments-95)

[1.176780] ACPI: \_SB_.PCI0.AGP_.VID_: failed to evaluate _DSM
[1.176948] nouveau :01:00.0: NVIDIA GT218 (0a8600b1)
[1.196734] nouveau :01:00.0: bios: version 70.18.53.00.04
[1.198112] nouveau :01:00.0: fb: 512 MiB DDR3
[1.251598] [TTM] Zone  kernel: Available graphics memory: 1496332 kiB
[1.251600] [TTM] Initializing pool allocator
[1.251605] [TTM] Initializing DMA pool allocator
[1.251625] nouveau :01:00.0: DRM: VRAM: 512 MiB
[1.251628] nouveau :01:00.0: DRM: GART: 1048576 MiB
[1.251634] nouveau :01:00.0: DRM: TMDS table version 2.0
[1.251637] nouveau :01:00.0: DRM: DCB version 4.0
[1.251641] nouveau :01:00.0: DRM: DCB outp 00: 048003b6 0f200014
[1.251644] nouveau :01:00.0: DRM: DCB outp 01: 02033300 
[1.251647] nouveau :01:00.0: DRM: DCB outp 02: 088223a6 0f220010
[1.251650] nouveau :01:00.0: DRM: DCB outp 03: 08022362 00020010
[1.251652] nouveau :01:00.0: DRM: DCB outp 04: 028113c6 0f220010
[1.251655] nouveau :01:00.0: DRM: DCB outp 05: 02011382 00020010
[1.251657] nouveau :01:00.0: DRM: DCB conn 00: 2047
[1.251660] nouveau :01:00.0: DRM: DCB conn 01: 00101146
[1.251662] nouveau :01:00.0: DRM: DCB conn 02: 00410246
[1.251664] nouveau :01:00.0: DRM: DCB conn 03: 0300
[1.278401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.278403] [drm] Driver supports precise vblank timestamp query.
[1.323205] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
[1.473861] nouveau :01:00.0: DRM: allocated 1440x900 fb: 
0x7, bo 8800b7baa000

[1.476208] fbcon: nouveaufb (fb0) is primary device
[1.830143] BUG: unable to handle kernel NULL pointer dereference at 
0020

[1.830152] IP: nv50_mstm_service+0xc/0xb0
[1.830153] PGD 0
[1.830154] P4D 0

[1.830158] Oops:  [#1] PREEMPT SMP
[1.830159] Modules linked in:
[1.830164] CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 4.13-pingu #1
[1.830166] Hardware name: Dell Inc. Latitude E6410/0K42JR, BIOS A16 
12/05/2013

[1.830171] Workqueue: events nvif_notify_work
[1.830173] task: 8800b79f1680 task.stack: c9154000
[1.830176] RIP: 0010:nv50_mstm_service+0xc/0xb0
[1.830178] RSP: :c9157df0 EFLAGS: 00010286
[1.830180] RAX: 8800b7096800 RBX: 8800b71b9418 RCX: 
8800b7096800
[1.830182] RDX: 8800b7a98b9c RSI: 002b RDI: 

[1.830183] RBP: 0008 R08: 8800b7096818 R09: 

[1.830185] R10:  R11: 0040 R12: 
8800b71b9000
[1.830187] R13:  R14:  R15: 
8800b71b9418
[1.830189] FS:  () GS:8800bb2c() 
knlGS:

[1.830191] CS:  0010 DS:  ES:  CR0: 80050033
[1.830193] CR2: 0020 CR3: 02209000 CR4: 
06e0

[1.830194] Call Trace:
[1.830200]  ? find_encoder+0x33/0x70
[1.830204]  ? nouveau_connector_hotplug+0x56/0x100
[1.830206]  ? nvif_notify_work+0x1f/0xa0
[1.830210]  ? nvkm_notify_work+0x64/0x70
[1.830214]  ? process_one_work+0x1a3/0x320
[1.830217]  ? worker_thread+0x42/0x3d0
[1.830220]  ? kthread+0xf2/0x130
[1.830223]  ? process_one_work+0x320/0x320
[1.830225]  ? kthread_create_on_node+0x40/0x40
[1.830228]  ? call_usermodehelper_exec_async+0x125/0x130
[1.830233]  ? ret_from_fork+0x25/0x30
[1.830234] Code: 89 04 24 e8 d7 2f ca ff 48 89 df e8 2f 72 c8 ff 48 
89 df e8 f7 ac 99 ff 48 83 c4 08 5b c3 90 41 54 55 48 8d 6f 08 53 48 83 
ec 18 <48> 8b 5f 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 c6

[1.830276] RIP: nv50_mstm_service+0xc/0xb0 RSP: c9157df0
[1.830277] CR2: 0020
[1.830281] ---[ end trace 9578c3b6b1cff0d4 ]---
[1.957826] Console: switching to colour frame buffer device 180x56
[1.975000] nouveau :01:00.0: fb0: nouveaufb frame buffer device
[1.975037] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 
on minor 0



Signed-off-by: Woody Suwalski 
---

diff --git 

[PATCH v2 2/4] drm: Add support for a panel-orientation connector property

2017-10-01 Thread Hans de Goede
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).

This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.

Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
 access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
 create and attach functions. The caller is expected to set
 drm_display_info.panel_orientation before calling this, then this will
 check for platform specific quirks overriding the panel_orientation and if
 the panel_orientation is set after this then it will attach the property.
---
 drivers/gpu/drm/drm_connector.c | 86 +
 include/drm/drm_connector.h | 11 ++
 include/drm/drm_mode_config.h   |  7 
 include/uapi/drm/drm_mode.h |  7 
 4 files changed, 111 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ba9f36cef68c..0159800b30a7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -212,6 +212,8 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
connector->status = connector_status_unknown;
+   connector->display_info.panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
drm_connector_get_cmdline_mode(connector);
 
@@ -665,6 +667,13 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
+   { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
+   { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
+   { DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
+   { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
+};
+
 static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
@@ -746,6 +755,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *
  * CRTC_ID:
  * Mode object ID of the _crtc this connector should be connected to.
+ *
+ * Connectors for LCD panels may also have one standardized property:
+ *
+ * panel orientation:
+ * On some devices the LCD panel is mounted in the casing in such a way
+ * that the up/top side of the panel does not match with the top side of
+ * the device. Userspace can use this property to check for this.
+ * Note that input coordinates from touchscreens (input devices with
+ * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
+ * coordinates, so if userspace rotates the picture to adjust for
+ * the orientation it must also apply the same transformation to the
+ * touchscreen input coordinates.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1212,6 +1233,71 @@ void drm_mode_connector_set_link_status_property(struct 
drm_connector *connector
 }
 EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * initialize the connecters panel_orientation property
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function should only be called for built-in panels, after setting
+ * connector->display_info.panel_orientation first (if known).
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+   struct drm_connector *connector, int width, int height)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_display_info *info = >display_info;
+   struct drm_property *prop;
+
+   /*
+* Note fb_get_panel_rotate_quirk returns the rotation needed to
+* *correct* for the panel orientation.
+*/
+   switch (fb_get_panel_rotate_quirk(width, height)) {
+   case FB_ROTATE_UR:
+   info->panel_orientation = 

Re: [RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

2017-10-01 Thread Jernej Škrabec
Hi,

Dne sobota, 30. september 2017 ob 13:58:03 CEST je Alexey Kardashevskiy 
napisal(a):
> On 21/09/17 06:01, Jernej Skrabec wrote:
> > [added media mailing list due to CEC question]
> > 
> > This patch series adds a HDMI glue driver for Allwinner H3 SoC. For now,
> > only video and CEC functionality is supported. Audio needs more tweaks.
> > 
> > Series is based on the H3 DE2 patch series available on mailing list:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/522697.h
> > tml (ignore patches marked with [NOT FOR REVIEW NOW] tag)
> > 
> > Patch 1 adds support for polling plug detection since custom PHY used here
> > doesn't support HPD interrupt.
> > 
> > Patch 2 enables overflow workaround for v1.32a. This HDMI controller
> > exhibits same issues as HDMI controller used in iMX6 SoCs.
> > 
> > Patch 3 adds CLK_SET_RATE_PARENT to hdmi clock.
> > 
> > Patch 4 adds dt bindings documentation.
> > 
> > Patch 5 adds actual H3 HDMI glue driver.
> > 
> > Patch 6 and 7 add HDMI node to DT and enable it where needed.
> > 
> > Allwinner used DW HDMI controller in a non standard way:
> > - register offsets obfuscation layer, which can fortunately be turned off
> > - register read lock, which has to be disabled by magic number
> > - custom PHY, which have to be initialized before DW HDMI controller
> > - non standard clocks
> > - no HPD interrupt
> > 
> > Because of that, I have two questions:
> > - Since HPD have to be polled, is it enough just to enable poll mode? I'm
> > 
> >   mainly concerned about invalidating CEC address here.
> > 
> > - PHY has to be initialized before DW HDMI controller to disable offset
> > 
> >   obfuscation and read lock among other things. This means that all clocks
> >   have to be enabled in glue driver. This poses a problem, since when
> >   using component model, dw-hdmi bridge uses drvdata for it's own private
> >   data and prevents glue layer to pass a pointer to unbind function,
> >   where clocks should be disabled. I noticed same issue in meson DW HDMI
> >   glue driver, where clocks are also not disabled when unbind callback is
> >   called. I noticed that when H3 SoC is shutdown, HDMI output is still
> >   enabled and lastest image is shown on monitor until it is unplugged
> >   from power supply. Is there any simple solution to this?
> > 
> > Chen-Yu,
> > TL Lim was unable to obtain any answer from Allwinner about HDMI clocks. I
> > think it is safe to assume that divider in HDMI clock doesn't have any
> > effect.
> > 
> > Branch based on linux-next from 1. September with integrated patches is
> > available here:
> > https://github.com/jernejsk/linux-1/tree/h3_hdmi_rfc
> 
> Out of curiosity I tried this one and got:
> 
> 
> 
> [0.071711] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
> [0.074809] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO
> driver [0.076167] sun8i-h3-r-pinctrl 1f02c00.pinctrl: initialized sunXi
> PIO driver [0.148009] [ cut here ]
> [0.148035] WARNING: CPU: 0 PID: 1 at
> drivers/clk/sunxi-ng/ccu_common.c:41 ccu_nm_set_rate+0x1d0/0x274
> [0.148046] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.13.0-rc6-next-20170825-aik-aik #24
> [0.148051] Hardware name: Allwinner sun8i Family
> [0.148082] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [0.148101] [] (show_stack) from []
> (dump_stack+0x84/0x98)
> [0.148117] [] (dump_stack) from []
> (__warn+0xe0/0xfc) [0.148132] [] (__warn) from []
> (warn_slowpath_null+0x20/0x28)
> [0.148145] [] (warn_slowpath_null) from []
> (ccu_nm_set_rate+0x1d0/0x274)
> [0.148161] [] (ccu_nm_set_rate) from []
> (clk_change_rate+0x19c/0x250)
> [0.148175] [] (clk_change_rate) from []
> (clk_core_set_rate_nolock+0x68/0xb0)
> [0.148187] [] (clk_core_set_rate_nolock) from []
> (clk_set_rate+0x20/0x30)
> [0.148202] [] (clk_set_rate) from []
> (of_clk_set_defaults+0x200/0x364)
> [0.148219] [] (of_clk_set_defaults) from []
> (platform_drv_probe+0x18/0xb0)
> [0.148233] [] (platform_drv_probe) from []
> (driver_probe_device+0x234/0x2e8)
> [0.148246] [] (driver_probe_device) from []
> (__driver_attach+0xb8/0xbc)
> [0.148258] [] (__driver_attach) from [ Unable to handle kernel NULL pointer dereference at virtual address 0008
> 

Patch for that is already merged upstream and can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/
drivers/clk/sunxi-ng?id=62d212bdb022deeb875f92f6e376c799e3f35eca

> and a bit later:
> 
> [1.995572] Rebooting in 10 seconds..

I'm not sure about that one. Kernel config issue?

Regards,
Jernej

> 
> Orange PI PC, script.bin.OPI-PC_1080p60_hdmi.
> 
> What do I miss? Thanks.
> 
> 
> 
> --
> Alexey


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/4] fb/drm: Add support for a panel-orientation connector prop

2017-10-01 Thread Hans de Goede
Hi All,

This is a resend of v2 of my panel-orientation drm connector property
series. I already send this out 2 weeks ago from my Red Hat email, but
that does not get picked up by the drm subsys scripts to run tests, so
hence this resend from my gmail.

The 2 biggest changes in v2 are:

1) Add support to drm-fb-helper.c for the panel-orientation prop and
make it apply the rotation to the fb to get fbcon to show the right way up.

2) Change the patch to enable the panel-orientation prop in the i915 driver
to read back to rotation setup by the BIOS from the hardware (the VBT
has a panel rotation field for this, but it reads 0 on hardware where
the GOP does correctly rotate the screen, so its useless).

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/4] drm/i915: Add "panel orientation" property to the panel connector

2017-10-01 Thread Hans de Goede
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.

Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.

So instead we end up reading the rotation from the primary plane,
which is a bit more complicated.

The code to read back the rotation from the hardware is based on an
earlier attempt to fix fdo#94894 by Ville Syrjala.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Cc: Ville Syrjala 
Suggested-by: Ville Syrjala 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Readback primary plane rotation from the hardware and use that to
 set the panel orientation
-This (readback) fixes fdo#94894, add Fixes: tag
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 drivers/gpu/drm/i915/intel_drv.h |  5 +
 drivers/gpu/drm/i915/intel_panel.c   | 33 ++
 4 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18d9da53282b..c4c8590972b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2151,6 +2151,8 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
 };
 
+struct intel_panel;
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2200,6 +2202,7 @@ struct drm_i915_private {
struct i915_gem_context *kernel_context;
struct intel_engine_cs *engine[I915_NUM_ENGINES];
struct i915_vma *semaphore;
+   struct intel_panel *panel;
 
struct drm_dma_handle *status_page_dmah;
struct resource mch_res;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 00cd17c76fdc..fbd61f92b60d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2891,6 +2891,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
return;
}
 
+   intel_panel_set_orientation_from_crtc(dev_priv->panel, intel_crtc,
+ plane_config->panel_orientation);
+
plane_state->src_x = 0;
plane_state->src_y = 0;
plane_state->src_w = fb->width << 16;
@@ -7523,6 +7526,10 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
plane_config->tiling = I915_TILING_X;
fb->modifier = I915_FORMAT_MOD_X_TILED;
}
+
+   if (val & DISPPLANE_ROTATE_180)
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
}
 
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -8576,6 +8583,24 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
goto error;
}
 
+   /* The rotation is used to *correct* for the panel orientation */
+   switch (val & PLANE_CTL_ROTATE_MASK) {
+   case PLANE_CTL_ROTATE_0:
+   break;
+   case PLANE_CTL_ROTATE_90:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   break;
+   case PLANE_CTL_ROTATE_180:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   break;
+   case PLANE_CTL_ROTATE_270:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   break;
+   }
+
base = I915_READ(PLANE_SURF(pipe, 0)) & 0xf000;
plane_config->base = base;
 
@@ -8661,6 +8686,10 @@ ironlake_get_initial_plane_config(struct intel_crtc 
*crtc,
plane_config->tiling = I915_TILING_X;
fb->modifier = I915_FORMAT_MOD_X_TILED;
}
+
+   if (val & DISPPLANE_ROTATE_180)
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
}
 
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -14578,7 +14607,9 @@ int intel_modeset_init(struct drm_device *dev)
drm_modeset_unlock_all(dev);
 
for_each_intel_crtc(dev, crtc) {
-   struct intel_initial_plane_config plane_config = {};
+   struct intel_initial_plane_config plane_config = {
+   .panel_orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL,
+   };
 
if (!crtc->active)
continue;
@@ -14600,6 +14631,12 @@ int intel_modeset_init(struct drm_device *dev)
   

Re: [PATCH] drm/armada: Remove unused #include

2017-10-01 Thread Haneen Mohammed
On Fri, Sep 29, 2017 at 02:29:31PM +0200, Noralf Trønnes wrote:
> 
> Den 29.09.2017 09.25, skrev Daniel Vetter:
> >On Wed, Sep 27, 2017 at 01:38:46AM -0600, Haneen Mohammed wrote:
> >>Remove drmP.h as it is not needed anymore since nothing it
> >>defines is used in these files.
> >>
> >>Signed-off-by: Haneen Mohammed 
> >Applied, thanks.
> 
> drivers/gpu/drm/armada/armada_fb.c uses DRM_ERROR() which is defined in
> include/drm/drmP.h. Doesn't that warrant an inclusion?
> 
> Noralf.
> 
> >-Daniel

Actually most of them do use DRM_ERROR. It's my mistake, I did not check every 
function,
and just relied on not getting an error when compiled. 

But this would mean almost all the files would need to include the
drmP.h then, since they are encouraged to use DRM_DEV_*, right?

> >>---
> >>  drivers/gpu/drm/armada/armada_510.c   | 1 -
> >>  drivers/gpu/drm/armada/armada_drv.c   | 1 -
> >>  drivers/gpu/drm/armada/armada_fb.c| 1 -
> >>  drivers/gpu/drm/armada/armada_fbdev.c | 1 -
> >>  drivers/gpu/drm/armada/armada_gem.c   | 1 -
> >>  5 files changed, 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/armada/armada_510.c 
> >>b/drivers/gpu/drm/armada/armada_510.c
> >>index ad3d2eb..41a784f 100644
> >>--- a/drivers/gpu/drm/armada/armada_510.c
> >>+++ b/drivers/gpu/drm/armada/armada_510.c
> >>@@ -9,7 +9,6 @@
> >>   */
> >>  #include 
> >>  #include 
> >>-#include 
> >>  #include 
> >>  #include "armada_crtc.h"
> >>  #include "armada_drm.h"
> >>diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> >>b/drivers/gpu/drm/armada/armada_drv.c
> >>index c993bcc..17bb675 100644
> >>--- a/drivers/gpu/drm/armada/armada_drv.c
> >>+++ b/drivers/gpu/drm/armada/armada_drv.c
> >>@@ -9,7 +9,6 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>-#include 
> >>  #include 
> >>  #include 
> >>  #include "armada_crtc.h"
> >>diff --git a/drivers/gpu/drm/armada/armada_fb.c 
> >>b/drivers/gpu/drm/armada/armada_fb.c
> >>index 51839c1..a38d5a0 100644
> >>--- a/drivers/gpu/drm/armada/armada_fb.c
> >>+++ b/drivers/gpu/drm/armada/armada_fb.c
> >>@@ -5,7 +5,6 @@
> >>   * it under the terms of the GNU General Public License version 2 as
> >>   * published by the Free Software Foundation.
> >>   */
> >>-#include 
> >>  #include 
> >>  #include 
> >>  #include "armada_drm.h"
> >>diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> >>b/drivers/gpu/drm/armada/armada_fbdev.c
> >>index cf6bad1..a2ce83f 100644
> >>--- a/drivers/gpu/drm/armada/armada_fbdev.c
> >>+++ b/drivers/gpu/drm/armada/armada_fbdev.c
> >>@@ -10,7 +10,6 @@
> >>  #include 
> >>  #include 
> >>-#include 
> >>  #include 
> >>  #include "armada_crtc.h"
> >>  #include "armada_drm.h"
> >>diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> >>b/drivers/gpu/drm/armada/armada_gem.c
> >>index 49d40aa..190280e 100644
> >>--- a/drivers/gpu/drm/armada/armada_gem.c
> >>+++ b/drivers/gpu/drm/armada/armada_gem.c
> >>@@ -8,7 +8,6 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>-#include 
> >>  #include "armada_drm.h"
> >>  #include "armada_gem.h"
> >>  #include 
> >>-- 
> >>2.7.4
> >>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/4] drm/fb-helper: Apply panel orientation connector prop to the primary plane

2017-10-01 Thread Hans de Goede
Apply the "panel orientation" drm connector prop to the primary plane,
so that fbcon and fbdev using userspace programs display the right way
up.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set
---
 drivers/gpu/drm/drm_fb_helper.c | 53 +++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1b8f013ffa65..75c409430a26 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 
+#include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
 
 static bool drm_fbdev_emulation = true;
@@ -347,6 +348,53 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
 }
 EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 
+static int get_plane_rotation_from_panel_orientation(
+   struct drm_fb_helper *fb_helper, struct drm_plane *plane)
+{
+   int i, rotation = DRM_MODE_ROTATE_0;
+   struct drm_connector *conn;
+   uint64_t valid_mask = 0;
+
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   conn = fb_helper->connector_info[i]->connector;
+   if (conn->state->crtc && conn->state->crtc->primary == plane) {
+   switch (conn->display_info.panel_orientation) {
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   rotation = DRM_MODE_ROTATE_180;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   rotation = DRM_MODE_ROTATE_90;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   rotation = DRM_MODE_ROTATE_270;
+   break;
+   }
+   break;
+   }
+   }
+
+   /*
+* Check the necessary rotation to compensate for the panel orientation
+* is supported.
+* Note currently we simply leave things as is when not supported, maybe
+* we shouls set a hint in fb_info to tell fbcon to rotate in this case
+* so that atleast the console ends up the right way. Maybe, but this:
+* a) Is not necessary for any known models with a non upright panel
+* b) Is tricky because fbcon rotation applies to all outputs rather
+*then a single one
+*/
+   if (!plane->rotation_property)
+   return DRM_MODE_ROTATE_0;
+
+   for (i = 0; i < plane->rotation_property->num_values; i++)
+   valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+   if (rotation & ~valid_mask)
+   return DRM_MODE_ROTATE_0;
+
+   return rotation;
+}
+
 static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
active)
 {
struct drm_device *dev = fb_helper->dev;
@@ -376,8 +424,9 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
goto out_state;
}
 
-   plane_state->rotation = DRM_MODE_ROTATE_0;
-
+   plane_state->rotation =
+   get_plane_rotation_from_panel_orientation(fb_helper,
+ plane);
plane->old_fb = plane->fb;
plane_mask |= 1 << drm_plane_index(plane);
 
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/4] video: fb: Make fbcon dmi quirks usuable for drm drivers too

2017-10-01 Thread Hans de Goede
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / let user space deal with this.

The fbcon code has a set of DMI based quirks to automatically detect
such tablet LCD panels and rotate the fbcon to compensate.

The plan was for userspace (e.g. a Wayland compositor) to simply read
/sys/class/graphics/fbcon/rotate and apply the rotation from there to
the LCD panel to compensate.

However this will not work when an external monitor gets plugged in,
since with fbcon rotation is not per output, so the fbcon quirk code
disables the rotation when an external monitor is present.

Using /sys/class/graphics/fbcon/rotate will not help in that case
since it will indicate no rotation is in use. So instead we are going
to need a drm connecter property for this.

This commit is a preparation patch for adding the drm-connecter
property, by making the fbcon quirk code generally usable so that
the drm code can use it to check for rotation quirks.

Note this commit re-uses the FB_CMDLINE Kconfig option for selecting
if the quirk code should be build, since that is already selected by
both the drm and fbcon code.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
---
 drivers/video/fbdev/core/Makefile  |  6 +++---
 .../core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c}   | 15 +--
 drivers/video/fbdev/core/fbcon.c   | 22 ++
 drivers/video/fbdev/core/fbcon.h   |  6 --
 include/linux/fb.h |  6 ++
 5 files changed, 32 insertions(+), 23 deletions(-)
 rename drivers/video/fbdev/core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c} (91%)

diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..06caf037a822 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,7 @@
 obj-$(CONFIG_FB_CMDLINE)  += fb_cmdline.o
+ifeq ($(CONFIG_DMI),y)
+obj-$(CONFIG_FB_CMDLINE)  += fb_dmi_quirks.o
+endif
 obj-$(CONFIG_FB_NOTIFY)   += fb_notify.o
 obj-$(CONFIG_FB)  += fb.o
 fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
@@ -14,9 +17,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
 fb-y += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
 fbcon_ccw.o
 endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
 endif
 fb-objs   := $(fb-y)
 
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c 
b/drivers/video/fbdev/core/fb_dmi_quirks.c
similarity index 91%
rename from drivers/video/fbdev/core/fbcon_dmi_quirks.c
rename to drivers/video/fbdev/core/fb_dmi_quirks.c
index 6904e47d1e51..d5fdf3245f83 100644
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ b/drivers/video/fbdev/core/fb_dmi_quirks.c
@@ -1,5 +1,5 @@
 /*
- *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
+ *  fb_dmi_quirks.c -- DMI based LCD panel rotation quirk detection
  *
  * Copyright (C) 2017 Hans de Goede 
  *
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include "fbcon.h"
 
 /*
  * Some x86 clamshell design devices use portrait tablet screens and a display
@@ -112,7 +111,11 @@ static const struct dmi_system_id rotate_data[] = {
{}
 };
 
-int fbcon_platform_get_rotate(struct fb_info *info)
+/*
+ * Note this function returns the rotation necessary to put the display
+ * the right way up, or -1 if there is no quirk.
+ */
+int fb_get_panel_rotate_quirk(int width, int height)
 {
const struct dmi_system_id *match;
const struct fbcon_dmi_rotate_data *data;
@@ -124,8 +127,7 @@ int fbcon_platform_get_rotate(struct fb_info *info)
 match = dmi_first_match(match + 1)) {
data = match->driver_data;
 
-   if (data->width != info->var.xres ||
-   data->height != info->var.yres)
+   if (data->width != width || data->height != height)
continue;
 
if (!data->bios_dates)
@@ -141,5 +143,6 @@ int fbcon_platform_get_rotate(struct fb_info *info)
}
}
 
-   return FB_ROTATE_UR;
+   return -1;
 }
+EXPORT_SYMBOL_GPL(fb_get_panel_rotate_quirk);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..2e17ea02c295 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -963,10 +963,13 @@ static const char *fbcon_startup(void)
ops->cur_rotate = -1;
ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   

Re: [RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

2017-10-01 Thread Alexey Kardashevskiy
On 01/10/17 04:56, Jernej Škrabec wrote:
> Hi,
> 
> Dne sobota, 30. september 2017 ob 13:58:03 CEST je Alexey Kardashevskiy 
> napisal(a):
>> On 21/09/17 06:01, Jernej Skrabec wrote:
>>> [added media mailing list due to CEC question]
>>>
>>> This patch series adds a HDMI glue driver for Allwinner H3 SoC. For now,
>>> only video and CEC functionality is supported. Audio needs more tweaks.
>>>
>>> Series is based on the H3 DE2 patch series available on mailing list:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/522697.h
>>> tml (ignore patches marked with [NOT FOR REVIEW NOW] tag)
>>>
>>> Patch 1 adds support for polling plug detection since custom PHY used here
>>> doesn't support HPD interrupt.
>>>
>>> Patch 2 enables overflow workaround for v1.32a. This HDMI controller
>>> exhibits same issues as HDMI controller used in iMX6 SoCs.
>>>
>>> Patch 3 adds CLK_SET_RATE_PARENT to hdmi clock.
>>>
>>> Patch 4 adds dt bindings documentation.
>>>
>>> Patch 5 adds actual H3 HDMI glue driver.
>>>
>>> Patch 6 and 7 add HDMI node to DT and enable it where needed.
>>>
>>> Allwinner used DW HDMI controller in a non standard way:
>>> - register offsets obfuscation layer, which can fortunately be turned off
>>> - register read lock, which has to be disabled by magic number
>>> - custom PHY, which have to be initialized before DW HDMI controller
>>> - non standard clocks
>>> - no HPD interrupt
>>>
>>> Because of that, I have two questions:
>>> - Since HPD have to be polled, is it enough just to enable poll mode? I'm
>>>
>>>   mainly concerned about invalidating CEC address here.
>>>
>>> - PHY has to be initialized before DW HDMI controller to disable offset
>>>
>>>   obfuscation and read lock among other things. This means that all clocks
>>>   have to be enabled in glue driver. This poses a problem, since when
>>>   using component model, dw-hdmi bridge uses drvdata for it's own private
>>>   data and prevents glue layer to pass a pointer to unbind function,
>>>   where clocks should be disabled. I noticed same issue in meson DW HDMI
>>>   glue driver, where clocks are also not disabled when unbind callback is
>>>   called. I noticed that when H3 SoC is shutdown, HDMI output is still
>>>   enabled and lastest image is shown on monitor until it is unplugged
>>>   from power supply. Is there any simple solution to this?
>>>
>>> Chen-Yu,
>>> TL Lim was unable to obtain any answer from Allwinner about HDMI clocks. I
>>> think it is safe to assume that divider in HDMI clock doesn't have any
>>> effect.
>>>
>>> Branch based on linux-next from 1. September with integrated patches is
>>> available here:
>>> https://github.com/jernejsk/linux-1/tree/h3_hdmi_rfc
>>
>> Out of curiosity I tried this one and got:
>>
>>
>>
>> [0.071711] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
>> [0.074809] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO
>> driver [0.076167] sun8i-h3-r-pinctrl 1f02c00.pinctrl: initialized sunXi
>> PIO driver [0.148009] [ cut here ]
>> [0.148035] WARNING: CPU: 0 PID: 1 at
>> drivers/clk/sunxi-ng/ccu_common.c:41 ccu_nm_set_rate+0x1d0/0x274
>> [0.148046] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>> 4.13.0-rc6-next-20170825-aik-aik #24
>> [0.148051] Hardware name: Allwinner sun8i Family
>> [0.148082] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [0.148101] [] (show_stack) from []
>> (dump_stack+0x84/0x98)
>> [0.148117] [] (dump_stack) from []
>> (__warn+0xe0/0xfc) [0.148132] [] (__warn) from []
>> (warn_slowpath_null+0x20/0x28)
>> [0.148145] [] (warn_slowpath_null) from []
>> (ccu_nm_set_rate+0x1d0/0x274)
>> [0.148161] [] (ccu_nm_set_rate) from []
>> (clk_change_rate+0x19c/0x250)
>> [0.148175] [] (clk_change_rate) from []
>> (clk_core_set_rate_nolock+0x68/0xb0)
>> [0.148187] [] (clk_core_set_rate_nolock) from []
>> (clk_set_rate+0x20/0x30)
>> [0.148202] [] (clk_set_rate) from []
>> (of_clk_set_defaults+0x200/0x364)
>> [0.148219] [] (of_clk_set_defaults) from []
>> (platform_drv_probe+0x18/0xb0)
>> [0.148233] [] (platform_drv_probe) from []
>> (driver_probe_device+0x234/0x2e8)
>> [0.148246] [] (driver_probe_device) from []
>> (__driver_attach+0xb8/0xbc)
>> [0.148258] [] (__driver_attach) from [> Unable to handle kernel NULL pointer dereference at virtual address 0008
>>
> 
> Patch for that is already merged upstream and can be found here:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/
> drivers/clk/sunxi-ng?id=62d212bdb022deeb875f92f6e376c799e3f35eca

Lovely, it works, thanks!


>> and a bit later:
>>
>> [1.995572] Rebooting in 10 seconds..
> 
> I'm not sure about that one. Kernel config issue?



Yup, I did not have CMA enabled.




-- 
Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-10-01 Thread Meghana Madhyastha
On Sun, Oct 01, 2017 at 04:47:26PM +0200, Noralf Trønnes wrote:
> 
> Den 01.10.2017 15.34, skrev Meghana Madhyastha:
> >On Sun, Oct 01, 2017 at 03:26:36PM +0200, Noralf Trønnes wrote:
> >>Den 01.10.2017 06.14, skrev Meghana Madhyastha:
> >>>On Sat, Sep 30, 2017 at 09:04:57PM +0200, Noralf Trønnes wrote:
> Den 30.09.2017 19.12, skrev Meghana Madhyastha:
> >Rename tinydrm_of_find_backlight to drm_of_find_backlight
> >and move it into drm_of.c from tinydrm-helpers.c. This is
> >because other drivers in the drm subsystem might need to call
> >this function. In that case and otherwise, it is better from
> >an organizational point of view to move it into drm_of.c along
> >with the other _of.c functions.
> >
> >Signed-off-by: Meghana Madhyastha 
> >---
> >Changes in v6:
> >-Move function declarations to linux/backlight.h to resolve
> >  module dependency issues.
> >
> >  drivers/gpu/drm/drm_of.c   | 44 
> > ++
> >  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> > ---
> >  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
> >  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> >  include/linux/backlight.h  | 11 +++
> >  5 files changed, 56 insertions(+), 42 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> >index 8dafbdf..d878d3a 100644
> >--- a/drivers/gpu/drm/drm_of.c
> >+++ b/drivers/gpu/drm/drm_of.c
> >@@ -1,6 +1,7 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  #include 
> >  #include 
> >  #include 
> >@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct 
> >device_node *np,
> > return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> >+
> >+/**
> >+ * drm_of_find_backlight - Find backlight device in device-tree
> >+ * @dev: Device
> >+ *
> >+ * This function looks for a DT node pointed to by a property named 
> >'backlight'
> >+ * and uses of_find_backlight_by_node() to get the backlight device.
> >+ * Additionally if the brightness property is zero, it is set to
> >+ * max_brightness.
> >+ *
> >+ * Note: It is the responsibility of the caller to call put_device() 
> >when
> >+ * releasing the resource.
> >+ *
> >+ * Returns:
> >+ * NULL if there's no backlight property.
> >+ * Error pointer -EPROBE_DEFER if the DT node is found, but no 
> >backlight device
> >+ * is found.
> >+ * If the backlight device is found, a pointer to the structure is 
> >returned.
> >+ */
> >+struct backlight_device *drm_of_find_backlight(struct device *dev)
> >+{
> >+struct backlight_device *backlight;
> >+struct device_node *np;
> >+
> >+np = of_parse_phandle(dev->of_node, "backlight", 0);
> >+if (!np)
> >+return NULL;
> >+
> >+backlight = of_find_backlight_by_node(np);
> >+of_node_put(np);
> >+
> >+if (!backlight)
> >+return ERR_PTR(-EPROBE_DEFER);
> >+
> >+if (!backlight->props.brightness) {
> >+backlight->props.brightness = 
> >backlight->props.max_brightness;
> >+DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> >+  backlight->props.brightness);
> >+}
> >+
> >+return backlight;
> >+}
> >+EXPORT_SYMBOL(drm_of_find_backlight);
> >diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> >b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >index bd6cce0..cd4c6a5 100644
> >--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void 
> >*vaddr, struct drm_framebuffer *fb,
> >  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
> >  /**
> >- * tinydrm_of_find_backlight - Find backlight device in device-tree
> >- * @dev: Device
> >- *
> >- * This function looks for a DT node pointed to by a property named 
> >'backlight'
> >- * and uses of_find_backlight_by_node() to get the backlight device.
> >- * Additionally if the brightness property is zero, it is set to
> >- * max_brightness.
> >- *
> >- * Returns:
> >- * NULL if there's no backlight property.
> >- * Error pointer -EPROBE_DEFER if the DT node is found, but no 
> >backlight device
> >- * is found.
> >- * If the backlight device is found, a pointer to the structure is 
> >returned.
> >- */
> >-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> >-{
> >-struct backlight_device 

[PATCH v7 3/3] drm/tinydrm: Add devres versions of drm_of_find_backlight

2017-10-01 Thread Meghana Madhyastha
Add devm_drm_of_find_backlight and the corresponding release
function because some drivers use devres versions of functions
for requiring device resources.

Signed-off-by: Meghana Madhyastha 
---
Changes in v7:
-None

 drivers/gpu/drm/drm_of.c   | 40 ++
 drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
 include/drm/drm_of.h   |  7 +++
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 7417725..82b5113 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -305,3 +305,43 @@ struct backlight_device *drm_of_find_backlight(struct 
device *dev)
return backlight;
 }
 EXPORT_SYMBOL(drm_of_find_backlight);
+
+static void devm_drm_of_find_backlight_release(void *data)
+{
+   put_device(data);
+}
+
+/**
+ * devm_drm_of_find_backlight - Find backlight device in device-tree
+ * devres version of the function
+ * @dev: Device
+ *
+ * This is the devres version of the function drm_of_find_backlight.
+ * Some drivers use devres versions of functions for
+ * requiring device resources.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   int ret;
+
+   backlight = drm_of_find_backlight(dev);
+   if (IS_ERR_OR_NULL(backlight))
+   return backlight;
+
+   ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
+ >dev);
+   if (ret) {
+   put_device(>dev);
+   return ERR_PTR(ret);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(devm_drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 5e3d635..d37f658 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -190,7 +190,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
 
-   mipi->backlight = drm_of_find_backlight(dev);
+   mipi->backlight = devm_drm_of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
 
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 6e93311..b95f3fb 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -30,6 +30,7 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
 struct backlight_device *drm_of_find_backlight(struct device *dev);
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -72,6 +73,12 @@ drm_of_find_backlight(struct device *dev)
 {
return NULL;
 }
+
+static inline struct backlight_device *
+devm_drm_of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
 #endif
 
 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v7 2/3] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-10-01 Thread Meghana Madhyastha
Rename tinydrm_of_find_backlight to drm_of_find_backlight
and move it into drm_of.c from tinydrm-helpers.c. This is
because other drivers in the drm subsystem might need to call
this function. In that case and otherwise, it is better from
an organizational point of view to move it into drm_of.c along
with the other _of.c functions.

Signed-off-by: Meghana Madhyastha 
---
Changes in v7:
-Move function declarations back to drm_of.h

 drivers/gpu/drm/drm_of.c   | 45 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
 drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
 include/drm/drm_of.h   |  7 
 include/drm/tinydrm/tinydrm-helpers.h  |  1 -
 5 files changed, 54 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..7417725 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -1,7 +1,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -260,3 +262,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
 }
 EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/**
+ * drm_of_find_backlight - Find backlight device in device-tree
+ * @dev: Device
+ *
+ * This function looks for a DT node pointed to by a property named 'backlight'
+ * and uses of_find_backlight_by_node() to get the backlight device.
+ * Additionally if the brightness property is zero, it is set to
+ * max_brightness.
+ *
+ * Note: It is the responsibility of the caller to call put_device() when
+ * releasing the resource.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   struct device_node *np;
+
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (!np)
+   return NULL;
+
+   backlight = of_find_backlight_by_node(np);
+   of_node_put(np);
+
+   if (!backlight)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (!backlight->props.brightness) {
+   backlight->props.brightness = backlight->props.max_brightness;
+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
+ backlight->props.brightness);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bd6cce0..cd4c6a5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
 EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
 
 /**
- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
-/**
  * tinydrm_enable_backlight - Enable backlight helper
  * @backlight: Backlight device
  *
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..5e3d635 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -189,7 +190,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
 
-   mipi->backlight = 

[PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

2017-10-01 Thread Meghana Madhyastha
Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) as part of the
if directive for the function declaration of
of_find_backlight_by_node in order to avoid module dependency
errors.

Signed-off-by: Meghana Madhyastha 
---
Changes in v7:
-This patch did not exist in v6. 

 include/linux/backlight.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f2fd61..a52ce82 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,7 +162,7 @@ struct generic_bl_info {
void (*kick_battery)(void);
 };
 
-#ifdef CONFIG_OF
+#if defined CONFIG_OF && IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
 struct backlight_device *of_find_backlight_by_node(struct device_node *node);
 #else
 static inline struct backlight_device *
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v7 0/3] drm/tinydrm: drm_of_find_backlight helper

2017-10-01 Thread Meghana Madhyastha
Move tinydrm_of_find_backlight to drm_of.c and rename it to
drm_of_find_backlight for better organizational structure.

Changes in v7:
-Move the function definitions/declarations back to drm_of.h
 and modify the config option for of_find_backlight_by_node
 in linux/backlight.h to resolve the build errors.

Meghana Madhyastha (3):
  backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
  drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c
  drm/tinydrm: Add devres versions of drm_of_find_backlight

 drivers/gpu/drm/drm_of.c   | 85 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
 drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
 include/drm/drm_of.h   | 14 +
 include/drm/tinydrm/tinydrm-helpers.h  |  1 -
 include/linux/backlight.h  |  2 +-
 6 files changed, 102 insertions(+), 43 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102009] Blender crashes when compiling OpenCL kernel

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102009

--- Comment #7 from Markus  ---
I tried to obtain debug information from Mesa but was unable to do so (i.e.
starting Blender with `MESA_DEBUG=context CYCLES_OPENCL_SPLIT_KERNEL_TEST=1
./blender` did not generate any visible debug information).

What I did instead, is run Blender via gdb which then gave the attached stack
trace at the time of crash. Looking at the trace, it appears like the crash is
inside LLVM.

What is the best way to debug this further?

P.S.: As I just updated to Ubuntu 17.10 (Beta 2), I've also attached new
glxinfo and clinfo output.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102009] Blender crashes when compiling OpenCL kernel

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102009

--- Comment #6 from Markus  ---
Created attachment 134601
  --> https://bugs.freedesktop.org/attachment.cgi?id=134601=edit
clinfo - Ubuntu 17.10

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102009] Blender crashes when compiling OpenCL kernel

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102009

--- Comment #5 from Markus  ---
Created attachment 134600
  --> https://bugs.freedesktop.org/attachment.cgi?id=134600=edit
glxinfo - Ubuntu 17.10

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102009] Blender crashes when compiling OpenCL kernel

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102009

--- Comment #4 from Markus  ---
Created attachment 134599
  --> https://bugs.freedesktop.org/attachment.cgi?id=134599=edit
gdb Stacktrace - Ubuntu 17.10

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322

2017-10-01 Thread Rob Herring
On Sat, Sep 30, 2017 at 6:42 PM, Linus Walleij  wrote:
> On Sun, Sep 24, 2017 at 10:36 PM, Rob Herring  wrote:
>> On Wed, Sep 20, 2017 at 6:56 AM, Linus Walleij  
>> wrote:
>>> On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij  
>>> wrote:
>
> Normally, we the physical panel is described which would imply all these
> settings. Are there lots of panels with this controller that would
> justify all these settings?

 The datasheet for the ili9322 just says it "drives panels" essentially.
 Googling around gives at hand that it is used pretty frequently in
 Shenzhen China for adapting different off-the-shelf panels to
 different inputs.

 I can't really answer how many of these products that run one or
 another OS using device tree to describe the configuration. It feels more
 like I'm paving the road for others to travel.
>>
>> Not really a road I want to pave and encourage others.
>
> It's good when maintainers say "no"! :)

Only other maintainers think so. :)


>> +  - ilitek,entry-mode: the panel can be connected to various input 
>> streams
>> +and four of them can be selected by electronic straps on the 
>> display.
>> +However it is possible to select another mode or override the
>> +electronic default with this property. Valid values:
>> +0: 8 bit serial RGB through
>> +1: 8 bit serial RGB aligned
>> +2: 8 bit serial RGB dummy 320x240
>> +3: 8 bit serial RGB dummy 360x240
>> +4: disabled
>> +5: 24 bit parallel RGB through
>> +6: 24 bit parallel RGB aligned
>> +7: 24 bit YUV 640Y 320CbCr
>> +8: 24 bit YUV 720Y 360CbCr
>> +9: disabled
>> +10: 8 bit ITU-R BT.656 720Y 360CbCr
>> +11: 8 bit ITU-R BT.656 640Y 320CbCr
>
> To some extent, we have some standard bindings to describe this.

 I don't find any. Maybe I'm looking in the wrong places :(
>>
>> I guess bus-width is all we have. Normally, this is all implied by the
>> compatible strings of either the controller, panel or both.
>>
>> Another way to look at it is, we already have support for lots of
>> panels and controllers. If those haven't needed to specify this
>> information, then why do you?
>
> It's a question about devicetree vs driver configuration data altogether.
> An intuitive thing, gray area. Your intuition is likely better.
>
> I feel the same about the people who push too much pin control
> data into the device tree instead of the driver so I understand the
> issue. (If it is that.)

Yes, that's it. We don't want bindings that try to parameterize
*everything* in "generic" bindings.

 Also the input modes of ili9322 is coupled with resolution so
 it would need two more cells or so for resolution so I feel
 it would over-complicate things for these 12 enumerators.
>>>
>>> Can we proceed with these patches?
>>>
>>> Any opinion from DT or panel maintainers?
>>
>> You have my opinion. I don't think Thierry's will be different.
>>
>> My suggestion is to move the settings you need into the panel driver
>> and out of DT. We can always move things to DT later if it makes
>> sense.
>
> Sure thing. I will take the approach of compatible string like this:
>
> compatible = "ilitek,ili9322", "dlink,dir685-panel";
>
> And use the latter compatible to set up all the stuff in the panel
> driver, what about that?

Sounds good, but you need to reverse the order here. Most specific first.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 00/10] drm: Add GEM backed framebuffer library

2017-10-01 Thread Noralf Trønnes


Den 25.09.2017 18.25, skrev Eric Anholt:

Noralf Trønnes  writes:


This adds helpers for drivers that don't subclass drm_framebuffer and
are backed by drm_gem_object(s). drm_fb_cma_helper is converted to use
the helpers.

Ack's have been trickling in the last month but seem to have stopped
now, so these are the ones left plus a new one: tve200

This series is:

Reviewed-by: Eric Anholt 


Thanks! Series applied to drm-misc.

Noralf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-10-01 Thread Noralf Trønnes


Den 01.10.2017 15.34, skrev Meghana Madhyastha:

On Sun, Oct 01, 2017 at 03:26:36PM +0200, Noralf Trønnes wrote:

Den 01.10.2017 06.14, skrev Meghana Madhyastha:

On Sat, Sep 30, 2017 at 09:04:57PM +0200, Noralf Trønnes wrote:

Den 30.09.2017 19.12, skrev Meghana Madhyastha:

Rename tinydrm_of_find_backlight to drm_of_find_backlight
and move it into drm_of.c from tinydrm-helpers.c. This is
because other drivers in the drm subsystem might need to call
this function. In that case and otherwise, it is better from
an organizational point of view to move it into drm_of.c along
with the other _of.c functions.

Signed-off-by: Meghana Madhyastha 
---
Changes in v6:
-Move function declarations to linux/backlight.h to resolve
  module dependency issues.

  drivers/gpu/drm/drm_of.c   | 44 ++
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
  include/linux/backlight.h  | 11 +++
  5 files changed, 56 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..d878d3a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -1,6 +1,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
  }
  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/**
+ * drm_of_find_backlight - Find backlight device in device-tree
+ * @dev: Device
+ *
+ * This function looks for a DT node pointed to by a property named 'backlight'
+ * and uses of_find_backlight_by_node() to get the backlight device.
+ * Additionally if the brightness property is zero, it is set to
+ * max_brightness.
+ *
+ * Note: It is the responsibility of the caller to call put_device() when
+ * releasing the resource.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   struct device_node *np;
+
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (!np)
+   return NULL;
+
+   backlight = of_find_backlight_by_node(np);
+   of_node_put(np);
+
+   if (!backlight)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (!backlight->props.brightness) {
+   backlight->props.brightness = backlight->props.max_brightness;
+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
+ backlight->props.brightness);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bd6cce0..cd4c6a5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
  /**
- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
-/**
   * tinydrm_enable_backlight - Enable backlight helper
   * @backlight: Backlight device
   *
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..682b4db 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ 

[Bug 103056] Artifacts in CS:GO

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=103056

Bug ID: 103056
   Summary: Artifacts in CS:GO
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: network...@rkmail.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 134597
  --> https://bugs.freedesktop.org/attachment.cgi?id=134597=edit
Artifacts on Cache

There are flashing artifacts on the ground textures in CS:GO on certain maps.
The affected maps are: cache, overpass.

openSUSE 42.3
Mesa: git master d5e7ce28b5f6e0a7e4857d1e56143c00eba0c265
LLVM: trunk revision 314551
Kernel: 4.13.4

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Nouveau] [PATCH] drm/nouveau: Document nouveau support for Tegra in DRIVER_DESC

2017-10-01 Thread Pierre Moreau
You are right, Tegra should probably be part of the description, even if we do
not support pre-K1 Tegras.

Acked-by: Pierre Moreau 

On 2017-08-11 — 10:56, Rhys Kidd wrote:
> nouveau supports the Tegra K1 and higher after the SoC-based GPUs converged
> with the main GeForce GPU families.
> 
> Signed-off-by: Rhys Kidd 
> ---
>  drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 822fe1d4d35e..fbe42ec0a5f1 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -5,7 +5,7 @@
>  #define DRIVER_EMAIL "nouv...@lists.freedesktop.org"
>  
>  #define DRIVER_NAME  "nouveau"
> -#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla"
> +#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra"
>  #define DRIVER_DATE  "20120801"
>  
>  #define DRIVER_MAJOR 1
> -- 
> 2.11.0
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/nouveau: Document nouveau support for Tegra in DRIVER_DESC

2017-10-01 Thread Martin Peres
On 11/08/17 13:56, Rhys Kidd wrote:
> nouveau supports the Tegra K1 and higher after the SoC-based GPUs converged
> with the main GeForce GPU families.
> 
> Signed-off-by: Rhys Kidd 
> ---
>  drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 822fe1d4d35e..fbe42ec0a5f1 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -5,7 +5,7 @@
>  #define DRIVER_EMAIL "nouv...@lists.freedesktop.org"
>  
>  #define DRIVER_NAME  "nouveau"
> -#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla"
> +#define DRIVER_DESC  "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra"

The problem is that we do not support all Tegras. How about Tegra TK1+?

I really do not care much about this string, but I guess I probably
should a bit.

With the TK1 added, this is:

Reviewed-by" Martin Peres 

>  #define DRIVER_DATE  "20120801"
>  
>  #define DRIVER_MAJOR 1
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-10-01 Thread Meghana Madhyastha
On Sun, Oct 01, 2017 at 03:26:36PM +0200, Noralf Trønnes wrote:
> 
> Den 01.10.2017 06.14, skrev Meghana Madhyastha:
> >On Sat, Sep 30, 2017 at 09:04:57PM +0200, Noralf Trønnes wrote:
> >>Den 30.09.2017 19.12, skrev Meghana Madhyastha:
> >>>Rename tinydrm_of_find_backlight to drm_of_find_backlight
> >>>and move it into drm_of.c from tinydrm-helpers.c. This is
> >>>because other drivers in the drm subsystem might need to call
> >>>this function. In that case and otherwise, it is better from
> >>>an organizational point of view to move it into drm_of.c along
> >>>with the other _of.c functions.
> >>>
> >>>Signed-off-by: Meghana Madhyastha 
> >>>---
> >>>Changes in v6:
> >>>-Move function declarations to linux/backlight.h to resolve
> >>>  module dependency issues.
> >>>
> >>>  drivers/gpu/drm/drm_of.c   | 44 
> >>> ++
> >>>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> >>> ---
> >>>  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
> >>>  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> >>>  include/linux/backlight.h  | 11 +++
> >>>  5 files changed, 56 insertions(+), 42 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> >>>index 8dafbdf..d878d3a 100644
> >>>--- a/drivers/gpu/drm/drm_of.c
> >>>+++ b/drivers/gpu/drm/drm_of.c
> >>>@@ -1,6 +1,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>>+#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>>@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct 
> >>>device_node *np,
> >>>   return ret;
> >>>  }
> >>>  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> >>>+
> >>>+/**
> >>>+ * drm_of_find_backlight - Find backlight device in device-tree
> >>>+ * @dev: Device
> >>>+ *
> >>>+ * This function looks for a DT node pointed to by a property named 
> >>>'backlight'
> >>>+ * and uses of_find_backlight_by_node() to get the backlight device.
> >>>+ * Additionally if the brightness property is zero, it is set to
> >>>+ * max_brightness.
> >>>+ *
> >>>+ * Note: It is the responsibility of the caller to call put_device() when
> >>>+ * releasing the resource.
> >>>+ *
> >>>+ * Returns:
> >>>+ * NULL if there's no backlight property.
> >>>+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> >>>device
> >>>+ * is found.
> >>>+ * If the backlight device is found, a pointer to the structure is 
> >>>returned.
> >>>+ */
> >>>+struct backlight_device *drm_of_find_backlight(struct device *dev)
> >>>+{
> >>>+  struct backlight_device *backlight;
> >>>+  struct device_node *np;
> >>>+
> >>>+  np = of_parse_phandle(dev->of_node, "backlight", 0);
> >>>+  if (!np)
> >>>+  return NULL;
> >>>+
> >>>+  backlight = of_find_backlight_by_node(np);
> >>>+  of_node_put(np);
> >>>+
> >>>+  if (!backlight)
> >>>+  return ERR_PTR(-EPROBE_DEFER);
> >>>+
> >>>+  if (!backlight->props.brightness) {
> >>>+  backlight->props.brightness = backlight->props.max_brightness;
> >>>+  DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> >>>+backlight->props.brightness);
> >>>+  }
> >>>+
> >>>+  return backlight;
> >>>+}
> >>>+EXPORT_SYMBOL(drm_of_find_backlight);
> >>>diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> >>>b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>>index bd6cce0..cd4c6a5 100644
> >>>--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>>+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>>@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
> >>>struct drm_framebuffer *fb,
> >>>  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
> >>>  /**
> >>>- * tinydrm_of_find_backlight - Find backlight device in device-tree
> >>>- * @dev: Device
> >>>- *
> >>>- * This function looks for a DT node pointed to by a property named 
> >>>'backlight'
> >>>- * and uses of_find_backlight_by_node() to get the backlight device.
> >>>- * Additionally if the brightness property is zero, it is set to
> >>>- * max_brightness.
> >>>- *
> >>>- * Returns:
> >>>- * NULL if there's no backlight property.
> >>>- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> >>>device
> >>>- * is found.
> >>>- * If the backlight device is found, a pointer to the structure is 
> >>>returned.
> >>>- */
> >>>-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> >>>-{
> >>>-  struct backlight_device *backlight;
> >>>-  struct device_node *np;
> >>>-
> >>>-  np = of_parse_phandle(dev->of_node, "backlight", 0);
> >>>-  if (!np)
> >>>-  return NULL;
> >>>-
> >>>-  backlight = of_find_backlight_by_node(np);
> >>>-  of_node_put(np);
> >>>-
> >>>-  if (!backlight)
> >>>-  return ERR_PTR(-EPROBE_DEFER);
> >>>-
> >>>-  if (!backlight->props.brightness) {
> >>>-  backlight->props.brightness = backlight->props.max_brightness;
> >>>-  

Re: [PATCH v6 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-10-01 Thread Noralf Trønnes


Den 01.10.2017 06.14, skrev Meghana Madhyastha:

On Sat, Sep 30, 2017 at 09:04:57PM +0200, Noralf Trønnes wrote:

Den 30.09.2017 19.12, skrev Meghana Madhyastha:

Rename tinydrm_of_find_backlight to drm_of_find_backlight
and move it into drm_of.c from tinydrm-helpers.c. This is
because other drivers in the drm subsystem might need to call
this function. In that case and otherwise, it is better from
an organizational point of view to move it into drm_of.c along
with the other _of.c functions.

Signed-off-by: Meghana Madhyastha 
---
Changes in v6:
-Move function declarations to linux/backlight.h to resolve
  module dependency issues.

  drivers/gpu/drm/drm_of.c   | 44 ++
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
  drivers/gpu/drm/tinydrm/mi0283qt.c |  2 +-
  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
  include/linux/backlight.h  | 11 +++
  5 files changed, 56 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..d878d3a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -1,6 +1,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
  }
  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/**
+ * drm_of_find_backlight - Find backlight device in device-tree
+ * @dev: Device
+ *
+ * This function looks for a DT node pointed to by a property named 'backlight'
+ * and uses of_find_backlight_by_node() to get the backlight device.
+ * Additionally if the brightness property is zero, it is set to
+ * max_brightness.
+ *
+ * Note: It is the responsibility of the caller to call put_device() when
+ * releasing the resource.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   struct device_node *np;
+
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (!np)
+   return NULL;
+
+   backlight = of_find_backlight_by_node(np);
+   of_node_put(np);
+
+   if (!backlight)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (!backlight->props.brightness) {
+   backlight->props.brightness = backlight->props.max_brightness;
+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
+ backlight->props.brightness);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bd6cce0..cd4c6a5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
  /**
- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
-/**
   * tinydrm_enable_backlight - Enable backlight helper
   * @backlight: Backlight device
   *
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..682b4db 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -189,7 +189,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if 

[Bug 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98324

--- Comment #9 from Darren Salt  ---
Created attachment 134594
  --> https://bugs.freedesktop.org/attachment.cgi?id=134594=edit
Apparent EDID errors

HDMI monitor set to 1920×1080, but on unblanking gets set to 1152×864.

This is the second time that I've seen this. Both times it's happened on the
first unblanking after boot; both times, using drm-next-4.15-dc.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/etnaviv: remove stale comment

2017-10-01 Thread Christian Gmeiner
2017-09-29 16:38 GMT+02:00 Lucas Stach :
> This comment is outdated as the driver is taking care about clock
> gating and the pulse eater for quite some time already.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 180b6a0f16ed..e3fbfdb46efe 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -434,13 +434,6 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
> unsigned long timeout;
> bool failed = true;
>
> -   /* TODO
> -*
> -* - clock gating
> -* - puls eater
> -* - what about VG?
> -*/
> -
> /* We hope that the GPU resets in under one second */
> timeout = jiffies + msecs_to_jiffies(1000);
>
> --
> 2.11.0
>

greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/etnaviv: rework clock initialization

2017-10-01 Thread Christian Gmeiner
2017-09-29 16:38 GMT+02:00 Lucas Stach :
> The reset path wants to initialize the clock control register regardless
> of the DYNAMIC_FREQUENCY_SCALING feature, so don't call clock update, but
> explicitly load the register.
>
> Also disabling of the debug registers is moved into the reset function,
> so we always get to the same state after a GPU reset. This means the
> clock update function should not touch the bits already set in the clock
> control register, but instead only update the scaling bits.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index fc9a6a83dfc7..180b6a0f16ed 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -420,9 +420,10 @@ static void etnaviv_gpu_update_clock(struct etnaviv_gpu 
> *gpu)
>  gpu->base_rate_shader >> gpu->freq_scale);
> } else {
> unsigned int fscale = 1 << (6 - gpu->freq_scale);
> -   u32 clock = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
> -   VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
> +   u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
>
> +   clock &= ~VIVS_HI_CLOCK_CONTROL_FSCALE_VAL__MASK;
> +   clock |= VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
> etnaviv_gpu_load_clock(gpu, clock);
> }
>  }
> @@ -445,9 +446,9 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
>
> while (time_is_after_jiffies(timeout)) {
> /* enable clock */
> -   etnaviv_gpu_update_clock(gpu);
> -
> -   control = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
> +   control = VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(1 << (6 -
> +  gpu->freq_scale));
> +   etnaviv_gpu_load_clock(gpu, control);
>

Just a little nit pick which can be ignored: add variable to make code
a tiny bit more
readable as it does not needs to code lines to assign control.

+   unsigned int fscale = 1 << (6 - gpu->freq_scale);
+   control = VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
+   etnaviv_gpu_load_clock(gpu, control);

> /* Wait for stable clock.  Vivante's code waited for 1ms */
> usleep_range(1000, 1);
> @@ -490,6 +491,10 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
> continue;
> }
>
> +   /* disable debug registers, as they are not normally needed */
> +   control |= VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS;
> +   gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, control);
> +
> failed = false;
> break;
> }
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] amdgpu: Add deadlock detection test suit.

2017-10-01 Thread Christian König

Am 29.09.2017 um 21:50 schrieb Andrey Grodzovsky:

From: Andrey Grodzovsky 

Adding initial tests for locks detection when SW
scheduler FIFO is full.

The test works by submitting a batch of identical commands which make the CP
stall waiting for condition to become true. The condition is later satisfied
form a helper thread. Other events that happen during this time
might create deadlock situations. One such example is GPU reset
triggered by this stall when  amdgpu_lockup_timeout != 0.

Change-Id: Ifc3a571481a85c947b107680cf17f59187180fe0
Signed-off-by: Andrey Grodzovsky 


A few nit picks below, with those fixed the patch is Reviewed-by: 
Christian König 



---
  tests/amdgpu/Makefile.am  |   6 +-
  tests/amdgpu/amdgpu_test.c|   6 ++
  tests/amdgpu/amdgpu_test.h|  15 +++
  tests/amdgpu/deadlock_tests.c | 244 ++
  4 files changed, 269 insertions(+), 2 deletions(-)
  create mode 100644 tests/amdgpu/deadlock_tests.c

diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 9c02fd6..8700c4d 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -1,7 +1,8 @@
  AM_CFLAGS = \
-I $(top_srcdir)/include/drm \
-I $(top_srcdir)/amdgpu \
-   -I $(top_srcdir)
+   -I $(top_srcdir) \
+   -pthread
  
  LDADD = $(top_builddir)/libdrm.la \

$(top_builddir)/amdgpu/libdrm_amdgpu.la \
@@ -29,4 +30,5 @@ amdgpu_test_SOURCES = \
frame.h \
uvd_enc_tests.c \
vcn_tests.c \
-   uve_ib.h
+   uve_ib.h \
+   deadlock_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index cd6b826..9925503 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -97,6 +97,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_uvd_enc_tests_clean,
.pTests = uvd_enc_tests,
},
+   {
+   .pName = "Deadlock Tests",
+   .pInitFunc = suite_deadlock_tests_init,
+   .pCleanupFunc = suite_deadlock_tests_clean,
+   .pTests = deadlock_tests,
+   },
CU_SUITE_INFO_NULL,
  };
  
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h

index d0b61ba..ece93f4 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -135,6 +135,21 @@ int suite_uvd_enc_tests_clean();
  extern CU_TestInfo uvd_enc_tests[];
  
  /**

+ * Initialize deadlock test suite
+ */
+int suite_deadlock_tests_init();
+
+/**
+ * Deinitialize deadlock test suite
+ */
+int suite_deadlock_tests_clean();
+
+/**
+ * Tests in uvd enc test suite
+ */
+extern CU_TestInfo deadlock_tests[];
+
+/**
   * Helper functions
   */
  static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
new file mode 100644
index 000..992d191
--- /dev/null
+++ b/tests/amdgpu/deadlock_tests.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.


You need to update the year here.


+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#ifdef HAVE_ALLOCA_H
+# include 
+#endif
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+
+#include 
+
+
+/*
+ * This defines the delay in MS after which memory location designated for
+ * compression against reference value is written to, unblocking command
+ * processor
+ */
+#define WRITE_MEM_ADDRESS_DELAY_MS 2


I would use at least 10 here, maybe 100 would be even better.


+
+#definePACKET_TYPE33
+
+#define PACKET3(op, n) ((PACKET_TYPE3 << 30) |   \
+(((op) & 0xFF) << 8) |   \
+((n) & 0x3FFF) << 16)
+
+#define

[Bug 102955] HyperZ related rendering issue in ARK: Survival Evolved

2017-10-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102955

Christian Lanig  changed:

   What|Removed |Added

 CC||freedesktop@lanig.email

--- Comment #2 from Christian Lanig  ---
I confirm this issue and that R600_DEBUG=nohyperz does fix it.

Thanks to Elliot Thomas for finding a temporary solution.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel