[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 muncrief (rmuncr...@humanavance.com) changed: What|Removed |Added CC|

Re: [Intel-gfx] [RFC v2 03/12] drm/i915/svm: Implicitly migrate BOs upon CPU access

On Sat, Dec 14, 2019 at 10:58:35AM +, Chris Wilson wrote: Quoting Niranjana Vishwanathapura (2019-12-13 21:56:05) +int i915_gem_object_migrate_region(struct drm_i915_gem_object *obj, + u32 *regions, int size) +{ + struct drm_i915_private *dev_priv =

Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support

On Sat, Dec 14, 2019 at 10:56:54AM +, Chris Wilson wrote: Quoting Niranjana Vishwanathapura (2019-12-13 21:56:04) Shared Virtual Memory (SVM) runtime allocator support allows binding a shared virtual address to a buffer object (BO) in the device page table through an ioctl call. Cc: Joonas

Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support

On Sat, Dec 14, 2019 at 10:31:37AM +, Chris Wilson wrote: Quoting Jason Ekstrand (2019-12-14 00:36:19) On Fri, Dec 13, 2019 at 5:24 PM Niranjan Vishwanathapura < niranjana.vishwanathap...@intel.com> wrote: On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote: > >     

Re: [RFC v1 0/1] drm: lima: devfreq and cooling device support

On Mon, Dec 16, 2019 at 5:12 AM Martin Blumenstingl wrote: > > This is my attempt at adding devfreq (and cooling device) support to > the lima driver. > I didn't have much time to do in-depth testing. However, I'm sending > this out early because there are many SoCs with Mali-400/450 GPU so > I

Re: [RFC v1 0/1] drm: lima: devfreq and cooling device support

Thanks for adding this. As the license, it's up to you, I think it's OK for now. For the code, I think you may need some lock to protect the time records as there are two kernel threads gp/pp will try to mark GPU busy and several interrupts try to mark GPU idle. Regards, Qiang On Mon, Dec 16,

linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/bridge/analogix/analogix-anx6345.c: In function 'anx6345_i2c_probe': drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:30: error: implicit declaration of function

linux-next: manual merge of the drm-misc tree with Linus' tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: include/drm/drm_dp_mst_helper.h between commit: 14692a3637d4 ("drm/dp_mst: Add probe_lock") from the Linus' tree and commit: f79489074c59 ("drm/dp_mst: Clear all payload id tables downstream when initializing")

linux-next: manual merge of the drm-misc tree with Linus' tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/drm_dp_mst_topology.c between commit: 14692a3637d4 ("drm/dp_mst: Add probe_lock") 3f9b3f02dda5 ("drm/dp_mst: Protect drm_dp_mst_port members with locking") 6f85f73821f6 ("drm/dp_mst: Add basic

[PATCH v2 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272

From: Heiko Stuebner The XPP055C272 is a 5.5" 720x1280 DSI display. changes in v2: - add size info into binding title (Sam) - add more required properties (Sam) Signed-off-by: Heiko Stuebner Reviewed-by: Sam Ravnborg --- .../display/panel/xinpeng,xpp055c272.yaml | 48 +++

[PATCH v2 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels

From: Heiko Stuebner Base on the somewhat similar Rocktech driver but adapted for panel-specific init of the XPP055C272. changes in v2: - move to drm-panel-internal backlight handling (Sam) - adapt to changes that happened to drm_panel structs+functions (Sam) - sort includes (Sam) - drop

[PATCH v2 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology

From: Heiko Stuebner Shenzhen Xinpeng Technology Co., Ltd produces for example display panels. Signed-off-by: Heiko Stuebner Acked-by: Sam Ravnborg --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 2/2] drm/i915/dp: Use BDB_GENERAL_FEATURES VBT block info for builtin panel-orientation

Some devices with a builtin panel have the panel mounted upside down, this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT block. We store this info in dev_priv->vbt.orientation, use this to set the connector's orientation property so that fbcon and userspace will show the

[PATCH 1/2] drm/i915/dsi: Remove readback of panel orientation on BYT / CHT

Commit 82daca297506 ("drm/i915: Add "panel orientation" property to the panel connector, v6.") uses hardware state readback to determine if the GOP is rotating the image by 180 degrees to compensate for upside-down mounted panels. When I wrote that commit I tried to find the VBT bits the GOP used

[GITLAB] spelling/typo: Shouldn't this thing called 'Merge Bot'?

Hello Eric, hello all, saw latest commits: committer Marge Bot [-] Reviewed-by: Jason Ekstrand Tested-by: Marge Bot etc. What do you think? Greetings, Dieter ___ dri-devel

[PATCH 2/2] fixup! drm/bridge: ti-sn65dsi86: Skip non-standard DP rates

From: Rob Clark --- Note however, the panel I have on the yoga c630 is not eDP 1.4+, so I cannot test that path. But I think it looks correct. drivers/gpu/drm/bridge/ti-sn65dsi86.c | 110 +- 1 file changed, 89 insertions(+), 21 deletions(-) diff --git

[PATCH 1/2] fixup! drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail

From: Rob Clark Fixes: In file included from ../drivers/gpu/drm/bridge/ti-sn65dsi86.c:25: ../drivers/gpu/drm/bridge/ti-sn65dsi86.c: In function ‘ti_sn_bridge_enable’: ../include/drm/drm_print.h:339:2: warning: ‘last_err_str’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Re: [PATCH 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other low res DP

On Fri, Dec 13, 2019 at 3:46 PM Douglas Anderson wrote: > > This series contains a pile of patches that was created to support > hooking up the AUO B116XAK01 panel to the eDP side of the bridge. In > general it should be useful for hooking up a wider variety of DP > panels to the bridge,

Re: [PATCH] drm: panel-orientation-quirks: Add quirk for Teclast X89 tablet

Hi, On 11-12-2019 18:38, Hans de Goede wrote: Hi, I know these kinda patches are sorta trivial, still I prefer to get an Acked-by before pushing this to drm-misc-next. Can someone review this please? Alternative I guess we could agree that pushing patches which just add a dmi quirk to

[PATCH 5/5] drm/i915/dsi: Control panel and backlight enable GPIOs on BYT

On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels do not control the LCD panel- and backlight-enable GPIOs. So far, when the VBT indicates we should use the SoC for backlight control, we have been relying on these GPIOs being configured as output and driven high by the Video

[PATCH 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT

Hi All, This is a new (completely rewritten) version of my patches to make the i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail devices when the VBT indicates that the SoC should be used for backlight control. This fixes the panel not lighting up on various devices when

[PATCH 4/5] drm/i915/dsi: Move Crystal Cove PMIC panel GPIO lookup from mfd to the i915 driver

Move the Crystal Cove PMIC panel GPIO lookup-table from drivers/mfd/intel_soc_pmic_core.c to the i915 driver. The moved looked-up table is adding a GPIO lookup to the i915 PCI device and the GPIO subsys allows only one lookup table per device, The intel_soc_pmic_core.c code only adds

[PATCH 2/5] drm/i915/dsi: Move poking of panel-enable GPIO to intel_dsi_vbt.c

On some older devices (BYT, CHT) which may use v2 VBT MIPI-sequences, we need to manually control the panel enable GPIO as v2 sequences do not do this. So far we have been carrying the code to do this on BYT/CHT devices with a Crystal Cove PMIC in vlv_dsi.c, but as this really is a shortcoming of

[PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off

When the LCD has not been turned on by the firmware/GOP, because e.g. the device was booted with an external monitor connected over HDMI, we should not turn on the panel-enable GPIO when we request it. Turning on the panel-enable GPIO when we request it, means we turn it on too early in the

[PATCH 1/5] pinctrl: Export pinctrl_unregister_mappings

Rename pinctrl_unregister_map to pinctrl_unregister_mappings so that its naming matches its pinctrl_register_mappings counter-part and export it. The purpose of this patch is to allow non-dt platforms to register pinctrl mappings from code which is build as a module, which requires being able to

dri and screen casting.

Hello List, I am using 4.9 kernel on an embedded system with an imx6 processor. For GPU driver I am using etnaviv and fb emulation. The application I am using is based on Qt 5.6. Two cards are created card0 and card1 where card0 is the VGA and card1 the GPU. A /dev/fb0 is created to emulate the

Re: [PATCH 2/2 v6] drm/panel: Add driver for Sony ACX424AKP panel

Hi Linus. Thanks for another panel driver. A mixed set of review comments in the following. Sam On Thu, Nov 14, 2019 at 02:15:25PM +0100, Linus Walleij wrote: > The Sony ACX424AKP is a command/videomode DSI panel for > mobile devices. It is used on the ST-Ericsson HREF520 > reference

Re: [PATCH] drm/panel: seperate panel power control from panel prepare/unprepare

Hi Jitao. On Wed, Nov 06, 2019 at 02:40:05PM +0800, Jitao Shi wrote: > Some dsi panels require the dsi lanes keeping low before panel power > on. So seperate the panel power control and the communication with panel. > > And put the power control in drm_panel_prepare_power and >

Re: [PATCH v3 00/50] drm/omap: Replace custom display drivers with drm_bridge and drm_panel

Hi Laurent. I have now been through this impressive series of patches. It is a nice series properly split into small readable chunks. A few nits in a few patches - already sent by separate mails. Patch 2,4,13 (with nits addressed): Reviewed-by: Sam Ravnborg Patch 1-20 (except the ones with

Re: [PATCH v3 11/50] drm/bridge: Add bridge driver for display connectors

Hi Laurent. One nit below. > + > +struct display_connector { > + struct drm_bridge bridge; > + > + const char *label; label is defined here. > + struct gpio_desc*hpd_gpio; > + int hpd_irq; > +}; > + ... > + > + /* Get the

Re: [PATCH v3 04/50] drm/bridge: Add connector-related bridge operations and data

Hi Laurent Small nit below. > /** > * struct drm_bridge_funcs - drm_bridge control functions > @@ -338,6 +343,119 @@ struct drm_bridge_funcs { >*/ > void (*atomic_post_disable)(struct drm_bridge *bridge, > struct drm_atomic_state *old_state); >

Re: [PATCH v3 35/50] drm/omap: Create connector for bridges

Hi Laurent. On Wed, Dec 11, 2019 at 12:57:35AM +0200, Laurent Pinchart wrote: > Use the drm_bridge_connector helper to create a connector for pipelines > that use drm_bridge. This allows splitting connector operations across > multiple bridges when necessary, instead of having the last bridge in

Re: [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels

Hi Heiko. > > The idea was that if a write returned an error then do not even attempt > > more writes. So if a write fails we do not loose the original error > > code, assuming subsequent write would also fail. > > Shouldn't the code above do exactly that? ... Because it's like > > ret =

Re: [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels

Hi Sam, Am Sonntag, 15. Dezember 2019, 09:29:16 CET schrieb Sam Ravnborg: > Hi Heiko. > > > Am Samstag, 14. Dezember 2019, 09:17:30 CET schrieb Sam Ravnborg: > > > > +#define dsi_generic_write_seq(dsi, cmd, seq...) do { > > > > \ > > > > + static const u8 d[] = {

Re: [PATCH 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels

Hi Heiko. > Am Samstag, 14. Dezember 2019, 09:17:30 CET schrieb Sam Ravnborg: > > > +#define dsi_generic_write_seq(dsi, cmd, seq...) do { > > > \ > > > + static const u8 d[] = { seq }; \ > > > + int ret;