[Bug 92912] Full GPU lockups in TF2 - R600
https://bugs.freedesktop.org/show_bug.cgi?id=92912 --- Comment #6 from Luca Osvaldo --- Having the same problem with linux 4.5 + AMDGPU drivers with powerplay enabled. AMD r9 380, with fglrx I don't have any problems. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/b9c0bd25/attachment.html>
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On 11 March 2016 at 23:45, Rafael J. Wysocki wrote: > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote: >> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote: >> > > It doesn't seem to do any runtime PM, >> > > I do wonder if pcieport should be doing it's own runtime PM handling, >> > > but that is a >> > > larger task than I'm thinking to tackle here. >> > >> > PCIe ports don't do PM - yet. Mika has posted a series of patches to >> > implement >> > that, however, that are waiting for comments now: >> > >> > https://patchwork.kernel.org/patch/8453311/ >> > https://patchwork.kernel.org/patch/8453381/ >> > https://patchwork.kernel.org/patch/8453391/ >> > https://patchwork.kernel.org/patch/8453411/ >> > https://patchwork.kernel.org/patch/8453371/ >> > https://patchwork.kernel.org/patch/8453351/ >> > >> > > Maybe I should be doing >> > > >> > > pci_set_power_state(pdev->bus->self, PCI_D3cold) ? I'm not really sure. >> > >> > Using pci_set_power_state() would be more appropriate IMO, but you can get >> > to the bridge via dev->parent too, can't you? >> > >> > In any case, it looks like you and Mika need to talk. :-) >> >> When the vga_switcheroo device gets runtime suspended (with the above >> runtime PM patchs for PCIe root ports) the root port should also be >> runtime suspended by the PM core. > > Right, after your patches have been applied, the additional handling > won't be needed. > > So Dave, maybe you can check if the Mika's patches help? Hi Mika, I tested your patches with a couple of changes on the Lenovo W541. The attached patch contains the two things I needed to get the same functionality as my patches. I'm really not in love with the per-chipset enablement for this, really any chipsets after a certain year should probably be better, as we'll constantly be adding PCI Ids for every chipset ever made, and I expect we'll forget some. Dave. -- next part -- A non-text attachment was scrubbed... Name: 0001-RFC-PCI-enable-runtime-PM-on-pcieports-to-let-second.patch Type: text/x-patch Size: 1772 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/275f843f/attachment.bin>
[Bug 94284] [radeonsi] outlast segfault on start
https://bugs.freedesktop.org/show_bug.cgi?id=94284 --- Comment #7 from Nicolai H�hnle --- Almost certainly not, please open a separate bug report. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/e5fa0173/attachment.html>
[PATCH v2] drm/rockchip: vop: fix crtc size in plane check
On 2016å¹´03æ04æ¥ 19:04, John Keeping wrote:
> If the geometry of a crtc is changing in an atomic update then we must
> validate the plane size against the new state of the crtc and not the
> current size, otherwise if the crtc size is increasing the plane will be
> cropped at the previous size and will not fill the screen.
>
> Signed-off-by: John Keeping
> ---
> On Fri, 04 Mar 2016 09:04:57 +0800, Mark yao wrote:
>> On 2016å¹´02æ22æ¥ 20:22, John Keeping wrote:
>>> If the geometry of a crtc is changing in an atomic update then we much
>> I think "we much validate" should be "we must validate".:-)
> Yes, here's v2 with that fixed.
>
>>> validate the plane size against the new state of the crtc and not the
>>> current size, otherwise if the crtc size is increasing the plane will be
>>> cropped at the previous size and will not fill the screen.
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fd37054..82d55bd 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -549,6 +549,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> struct drm_crtc *crtc = state->crtc;
> + struct drm_crtc_state *crtc_state;
> struct drm_framebuffer *fb = state->fb;
> struct vop_win *vop_win = to_vop_win(plane);
> struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
> @@ -563,12 +564,13 @@ static int vop_plane_atomic_check(struct drm_plane
> *plane,
> int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
> DRM_PLANE_HELPER_NO_SCALING;
>
> - crtc = crtc ? crtc : plane->state->crtc;
> - /*
> - * Both crtc or plane->state->crtc can be null.
> - */
> if (!crtc || !fb)
> goto out_disable;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> + if (WARN_ON(!crtc_state))
> + return -EINVAL;
> +
> src->x1 = state->src_x;
> src->y1 = state->src_y;
> src->x2 = state->src_x + state->src_w;
> @@ -580,8 +582,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
>
> clip.x1 = 0;
> clip.y1 = 0;
> - clip.x2 = crtc->mode.hdisplay;
> - clip.y2 = crtc->mode.vdisplay;
> + clip.x2 = crtc_state->adjusted_mode.hdisplay;
> + clip.y2 = crtc_state->adjusted_mode.vdisplay;
>
> ret = drm_plane_helper_check_update(plane, crtc, state->fb,
> src, dest, &clip,
Looks good for me, applied into my drm-fixes.
Thanks for the fix.
--
ï¼ark Yao
[PATCH] drm/rockchip: cancel pending vblanks on close
On 2016å¹´03æ12æ¥ 01:21, John Keeping wrote: > When closing the DRM device while a vblank is pending, we access > file_priv after it has been free'd, which gives: > >Unable to handle kernel NULL pointer dereference at virtual address > >... >PC is at __list_add+0x5c/0xe8 >LR is at send_vblank_event+0x54/0x1f0 >... >[] (__list_add) from [] (send_vblank_event+0x54/0x1f0) >[] (send_vblank_event) from [] > (drm_send_vblank_event+0x70/0x78) >[] (drm_send_vblank_event) from [] > (drm_crtc_send_vblank_event+0x30/0x34) >[] (drm_crtc_send_vblank_event) from [] > (vop_isr+0x224/0x28c) >[] (vop_isr) from [] > (handle_irq_event_percpu+0x12c/0x3e4) > > This can be triggered somewhat reliably with: > > modetest -M rockchip -v -s ... > > Add a preclose hook to the driver so that we can discard any pending > vblank events when the device is closed. > > Signed-off-by: John Keeping Looks good for me, applied into my drm-fixes. Thanks for the fix. -- ï¼ark Yao
[PATCH v7 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC
Hi David, As DT binding docs have been acked by Rob Herring since v6, https://lists.freedesktop.org/archives/dri-devel/2016-March/102135.html And it seems there is no comments on v7. I wonder if we get a chance that v7 be merge into v4.6 mainline. Or if no chance for v4.6, when? Thanks, -xinliang On 4 March 2016 at 18:54, Xinliang Liu wrote: > This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC. > Current testing and support board is Hikey board which is one of Linaro > 96boards. It is an arm64 open source board. For more information about > this board, please access https://www.96boards.org. > > Hardware Detail > --- > The display subsystem of Hi6220 SoC is shown as bellow: > +-+ +--+ +-+ +-+ > | | | | | | | | > | FB |-->| ADE|>| DSI |>| External | > | | | | | | | HDMI/panel | > +-+ +--+ +-+ +-+ > > - ADE(Advanced Display Engine) is the display controller. It contains 7 > channels, 3 overlay compositors and a LDI. > - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc). > - Overlay compositor is response to compose planes which come from 7 > channels and pass composed image to LDI. > - LDI is response to generate timings and RGB data stream. > - DSI converts the RGB data stream from ADE to DSI packets. > - External HDMI/panel module is connected with DSI bus. Now Hikey use a > ADI's ADV7533 external HDMI chip. > > Change History > - > Changes in v7: > - Add config.mutex protection when accessing mode_config.connector_list. > - Clean up match data getting of kirin_drm_drv.c. > - A few Regs define clean up and typo fixs for ADE crtc and DSI encoder > driver. > - Fix vblank irq flag "DRIVER_IRQF_SHARED" to "IRQF_SHARED". > Changes in v6: > - Cleanup values part of reg and clocks relevant properties. > - Change "pclk_dsi" clock name to "pclk". > > Changes in v5: > - Remove endpoint unit address of dsi output port. > - Use syscon to access ADE media NOC QoS registers instread of directly > writing registers. > - Use reset controller to reset ADE instead of directly writing registers. > > Changes in v4: > - Describe more specific of clocks and ports of binding docs. > - Fix indentation of binding docs. > > Changes in v3: > - Move and rename all the files to kirin sub-directory. > So that we could separate different seires SoCs' driver. > - Make ade as the drm master node. > - Replace drm_platform_init, load, unload implementation. > - Use assigned-clocks to set clock rate. > - Use ports to connect display relevant nodes. > - Rename hisi_drm_dsi.c to dw_drm_dsi.c > - Make encoder type as DRM_MODE_ENCODER_DSI. > - A few cleanup on regs and code. > > Changes in v2: > - Remove abtraction layer of plane/crtc/encoder/connector. > - Refactor atomic implementation according to Daniel Vetter's guides: > http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html > http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html > http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html > - Use bridge instead of slave encoder to connect external HDMI. > - Move dt binding docs to bindings/display/hisilicon directory. > > Xinliang Liu (11): > drm/hisilicon: Add device tree binding for hi6220 display subsystem > drm/hisilicon: Add hisilicon kirin drm master driver > drm/hisilicon: Add crtc driver for ADE > drm/hisilicon: Add plane driver for ADE > drm/hisilicon: Add vblank driver for ADE > drm/hisilicon: Add cma fbdev and hotplug > drm/hisilicon: Add designware dsi encoder driver > drm/hisilicon: Add designware dsi host driver > drm/hisilicon: Add support for external bridge > MAINTAINERS: Add maintainer for hisilicon DRM driver > arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220 > > .../bindings/display/hisilicon/dw-dsi.txt | 72 ++ > .../bindings/display/hisilicon/hisi-ade.txt| 64 ++ > MAINTAINERS| 10 + > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 40 + > arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 55 + > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/hisilicon/Kconfig |5 + > drivers/gpu/drm/hisilicon/Makefile |5 + > drivers/gpu/drm/hisilicon/kirin/Kconfig| 10 + > drivers/gpu/drm/hisilicon/kirin/Makefile |5 + > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 857 > drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h | 103 ++ > drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h| 230 + > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1057 > > drivers/gpu/drm/hisilicon/kirin/kirin_drm
[PULL] topic/drm-misc
On Wed, Mar 09, 2016 at 10:56:46AM +0100, Daniel Vetter wrote: > Hi Dave, > > I expect this to be the final drm-misc pull for 4.6: > - color manager core patch from Lionel - i915 side is ready too, but will > only land in 4.7, but I figured it's better to land this earlier for > better coordination with other plane stuff (like alpha/blending) going > on. > - more mode_fixup dummy func removal from Carlos (I think that's all now). > - atomic connector stealing fixes Maarten (maybe this time around, Maarten > added testcases for it to igt too). Color manager patch from Lionel needed some fixup. And somehow the 2nd pull request got lost, so third time's the charm ;-) I've thrown the SAD extraction patch from Ville on top for this one. -Daniel The following changes since commit 44ab4042178bd596275927ea050980aa4257581b: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-02-26 13:02:57 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-03-14 for you to fetch changes up to c1f415c9acb5877c408d9311eb837d7d50636a68: drm: atomic helper: do not unreference error pointer (2016-03-13 19:39:54 +0100) Carlos Palminha (15): drm/cirrus: removed optional dummy crtc mode_fixup function. drm/mgag200: removed optional dummy crtc mode_fixup function. drm/udl: removed optional dummy crtc mode_fixup function. drm/gma: removed optional dummy crtc mode_fixup function. drm/rcar-du: removed optional dummy crtc mode_fixup function. drm/omapdrm: removed optional dummy crtc mode_fixup function. drm/msm/mdp: removed optional dummy crtc mode_fixup function. drm/shmobile: removed optional dummy crtc mode_fixup function. drm/sti: removed optional dummy crtc mode_fixup function. drm/atmel-hlcdc: remove optional dummy crtc mode_fixup function. drm/nouveau/dispnv04: removed optional dummy crtc mode_fixup function. drm/virtio: removed optional dummy crtc mode_fixup function. drm/fsl-dcu: removed optional dummy crtc mode_fixup function. drm/bochs: removed optional dummy crtc mode_fixup function. drm/ast: removed optional dummy crtc mode_fixup function. Lionel Landwerlin (3): drm: introduce pipe color correction properties drm: fix blob pointer check drm: atomic helper: do not unreference error pointer Liu Ying (1): drm/crtc: Use drm_mode_object_put() in __drm_framebuffer_unregister() Maarten Lankhorst (7): drm/atomic: Clean up update_output_state. drm/atomic: Pass connector and state to update_connector_routing. drm/atomic: Always call steal_encoder, v2. drm/atomic: Handle encoder stealing from set_config better. drm/atomic: Handle encoder assignment conflicts in a separate check, v3. drm/atomic: Clean up steal_encoder, v2. drm/atomic: Clean up update_connector_routing. Ville Syrjälä (1): drm/edid: Extract SADs properly from multiple audio data blocks Documentation/DocBook/gpu.tmpl | 59 +++- drivers/gpu/drm/ast/ast_mode.c | 8 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 - drivers/gpu/drm/bochs/bochs_kms.c | 8 - drivers/gpu/drm/cirrus/cirrus_mode.c | 13 - drivers/gpu/drm/drm_atomic.c | 88 +- drivers/gpu/drm/drm_atomic_helper.c| 362 - drivers/gpu/drm/drm_crtc.c | 39 ++- drivers/gpu/drm/drm_crtc_helper.c | 33 +++ drivers/gpu/drm/drm_edid.c | 17 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8 - drivers/gpu/drm/gma500/cdv_intel_display.c | 13 +- drivers/gpu/drm/gma500/gma_display.c | 7 - drivers/gpu/drm/gma500/gma_display.h | 3 - drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 - drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 - drivers/gpu/drm/gma500/psb_intel_display.c | 1 - drivers/gpu/drm/mgag200/mgag200_mode.c | 13 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 8 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 8 - drivers/gpu/drm/nouveau/dispnv04/crtc.c| 8 - drivers/gpu/drm/omapdrm/omap_crtc.c| 8 - drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 - drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 8 - drivers/gpu/drm/sti/sti_crtc.c | 9 - drivers/gpu/drm/udl/udl_modeset.c | 9 - drivers/gpu/drm/virtio/virtgpu_display.c | 8 - include/drm/drm_atomic_helper.h| 3 + include/drm/drm_crtc.h | 48 +++- include/drm/drm_crtc_helper.h | 3 + include/uapi/drm/drm_mode.h| 15 + 31 files changed, 536 insertions(+), 292 deletions(-) -- Daniel Vetter Software Engineer, Intel Corp
[PATCH 1/4 v3] drm: Add support of ARC PGU display controller
On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> ARC PGU could be found on some development boards from Synopsys.
> This is a simple byte streamer that reads data from a framebuffer
> and sends data to the single encoder.
>
> Signed-off-by: Alexey Brodkin
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-snps-arc at lists.infradead.org
> Cc: Jose Abreu
> ---
>
> Changes v2 -> v3:
> * Improved failure path if arcpgu_connector wasn't allocated (thanks Jose).
> * Fixed driver building as module (reported by 0-DAY kernel test
> infrastruct.)
> * Implemented uncached mapping of user-space FB pages.
>
> No changes v1 -> v2.
>
Bunch of comments below to update your driver to latest styles and best
practices.
Cheers, Daniel
> drivers/gpu/drm/Kconfig| 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/arc/Kconfig| 10 ++
> drivers/gpu/drm/arc/Makefile | 2 +
> drivers/gpu/drm/arc/arcpgu.h | 50 +++
> drivers/gpu/drm/arc/arcpgu_crtc.c | 274
> +
> drivers/gpu/drm/arc/arcpgu_drv.c | 252 ++
> drivers/gpu/drm/arc/arcpgu_fbdev.c | 245 +
> drivers/gpu/drm/arc/arcpgu_hdmi.c | 207
> drivers/gpu/drm/arc/arcpgu_regs.h | 36 +
> 10 files changed, 1079 insertions(+)
> create mode 100644 drivers/gpu/drm/arc/Kconfig
> create mode 100644 drivers/gpu/drm/arc/Makefile
> create mode 100644 drivers/gpu/drm/arc/arcpgu.h
> create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
> create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
> create mode 100644 drivers/gpu/drm/arc/arcpgu_fbdev.c
> create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
> create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f2a74d0..9e4f2f1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -281,3 +281,5 @@ source "drivers/gpu/drm/imx/Kconfig"
> source "drivers/gpu/drm/vc4/Kconfig"
>
> source "drivers/gpu/drm/etnaviv/Kconfig"
> +
> +source "drivers/gpu/drm/arc/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6eb94fc..c338d04 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -78,3 +78,4 @@ obj-y += panel/
> obj-y+= bridge/
> obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> +obj-$(CONFIG_DRM_ARCPGU)+= arc/
> diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
> new file mode 100644
> index 000..f9a13b6
> --- /dev/null
> +++ b/drivers/gpu/drm/arc/Kconfig
> @@ -0,0 +1,10 @@
> +config DRM_ARCPGU
> + tristate "ARC PGU"
> + depends on DRM && OF
> + select DRM_KMS_CMA_HELPER
> + select DRM_KMS_FB_HELPER
> + select DRM_KMS_HELPER
> + help
> + Choose this option if you have an ARC PGU controller.
> +
> + If M is selected the module will be called arcpgu.
> diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
> new file mode 100644
> index 000..736ee6f
> --- /dev/null
> +++ b/drivers/gpu/drm/arc/Makefile
> @@ -0,0 +1,2 @@
> +arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_fbdev.o arcpgu_drv.o
> +obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
> diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
> new file mode 100644
> index 000..86574b6
> --- /dev/null
> +++ b/drivers/gpu/drm/arc/arcpgu.h
> @@ -0,0 +1,50 @@
> +/*
> + * ARC PGU DRM driver.
> + *
> + * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef _ARCPGU_H_
> +#define _ARCPGU_H_
> +
> +struct arcpgu_drm_private {
> + void __iomem*regs;
> + struct clk *clk;
> + struct drm_fbdev_cma*fbdev;
> + struct drm_framebuffer *fb;
> + struct list_headevent_list;
> + struct drm_crtc crtc;
> + struct drm_plane*plane;
> +};
> +
> +#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private,
> crtc)
> +
> +static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
> + unsigned int reg, u32 value)
> +{
> + iowrite32(value, arcpgu->regs + reg);
> +}
> +
> +static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
> +unsigned int reg)
> +{
> + return ioread32(arcpgu->regs + reg);
> +}
[PATCH 1/4] gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex
To avoid race condition issue, we should protect the function ipu_dmfc_init_channel() with the mutex dmfc->priv->mutex, since it configures the register DMFC_GENERAL1 at runtime which contains several control bits for various display channels. This matches better with fine grained locking logic in upper layer. Signed-off-by: Liu Ying --- drivers/gpu/ipu-v3/ipu-dmfc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c index 042c395..129ccfa 100644 --- a/drivers/gpu/ipu-v3/ipu-dmfc.c +++ b/drivers/gpu/ipu-v3/ipu-dmfc.c @@ -355,6 +355,8 @@ int ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width) struct ipu_dmfc_priv *priv = dmfc->priv; u32 dmfc_gen1; + mutex_lock(&priv->mutex); + dmfc_gen1 = readl(priv->base + DMFC_GENERAL1); if ((dmfc->slots * 64 * 4) / width > dmfc->data->max_fifo_lines) @@ -364,6 +366,8 @@ int ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width) writel(dmfc_gen1, priv->base + DMFC_GENERAL1); + mutex_unlock(&priv->mutex); + return 0; } EXPORT_SYMBOL_GPL(ipu_dmfc_init_channel); -- 2.5.0
[PATCH 3/4] gpu: ipu-v3: ipu-dmfc: Rename ipu_dmfc_init_channel to ipu_dmfc_config_wait4eot
The function name 'ipu_dmfc_config_wait4eot' matches the implementation of
the function better than 'ipu_dmfc_init_channel', since it only touches the
wait4eot bits.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 ++--
include/video/imx-ipu-v3.h| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 0faf84a..cab8a45 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -200,7 +200,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
}
}
- ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
+ ipu_dmfc_config_wait4eot(ipu_plane->dmfc, crtc_w);
ret = ipu_dmfc_alloc_bandwidth(ipu_plane->dmfc,
calc_bandwidth(crtc_w, crtc_h,
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index 3aa9878..837b1ec2 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -350,7 +350,7 @@ out:
}
EXPORT_SYMBOL_GPL(ipu_dmfc_alloc_bandwidth);
-void ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width)
+void ipu_dmfc_config_wait4eot(struct dmfc_channel *dmfc, int width)
{
struct ipu_dmfc_priv *priv = dmfc->priv;
u32 dmfc_gen1;
@@ -368,7 +368,7 @@ void ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int
width)
mutex_unlock(&priv->mutex);
}
-EXPORT_SYMBOL_GPL(ipu_dmfc_init_channel);
+EXPORT_SYMBOL_GPL(ipu_dmfc_config_wait4eot);
struct dmfc_channel *ipu_dmfc_get(struct ipu_soc *ipu, int ipu_channel)
{
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 07dfc41..8abf16b 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -236,7 +236,7 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc);
int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
unsigned long bandwidth_mbs, int burstsize);
void ipu_dmfc_free_bandwidth(struct dmfc_channel *dmfc);
-void ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width);
+void ipu_dmfc_config_wait4eot(struct dmfc_channel *dmfc, int width);
struct dmfc_channel *ipu_dmfc_get(struct ipu_soc *ipu, int ipuv3_channel);
void ipu_dmfc_put(struct dmfc_channel *dmfc);
--
2.5.0
[PATCH 2/4] gpu: ipu-v3: ipu-dmfc: Make function ipu_dmfc_init_channel() return void
Since the function ipu_dmfc_init_channel() always returns zero, we may
change the return type to void to simplify the code.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/ipuv3-plane.c | 6 +-
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +---
include/video/imx-ipu-v3.h| 2 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d078373..0faf84a 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -200,11 +200,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
}
}
- ret = ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
- if (ret) {
- dev_err(dev, "initializing dmfc channel failed with %d\n", ret);
- return ret;
- }
+ ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
ret = ipu_dmfc_alloc_bandwidth(ipu_plane->dmfc,
calc_bandwidth(crtc_w, crtc_h,
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index 129ccfa..3aa9878 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -350,7 +350,7 @@ out:
}
EXPORT_SYMBOL_GPL(ipu_dmfc_alloc_bandwidth);
-int ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width)
+void ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width)
{
struct ipu_dmfc_priv *priv = dmfc->priv;
u32 dmfc_gen1;
@@ -367,8 +367,6 @@ int ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int
width)
writel(dmfc_gen1, priv->base + DMFC_GENERAL1);
mutex_unlock(&priv->mutex);
-
- return 0;
}
EXPORT_SYMBOL_GPL(ipu_dmfc_init_channel);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index eeba753..07dfc41 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -236,7 +236,7 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc);
int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
unsigned long bandwidth_mbs, int burstsize);
void ipu_dmfc_free_bandwidth(struct dmfc_channel *dmfc);
-int ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width);
+void ipu_dmfc_init_channel(struct dmfc_channel *dmfc, int width);
struct dmfc_channel *ipu_dmfc_get(struct ipu_soc *ipu, int ipuv3_channel);
void ipu_dmfc_put(struct dmfc_channel *dmfc);
--
2.5.0
[PATCH 4/4] drm/imx: ipuv3-plane: Configure DMFC wait4eot bit after slots are determined
Just as the function ipu_dmfc_config_wait4eot() tells, the DMFC wait4eot bit depends on the number of DMFC slots to be used, so it should be called after the slots are determined in the function ipu_dmfc_alloc_bandwidth(). Based on tests, this patch may eliminate display distortion issue on overlay plane with small resolutions. To reproduce the issue, we may run this drm modetest case - 'modetest -P 19:64x64'. Signed-off-by: Liu Ying --- drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index cab8a45..afec9f6 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -200,8 +200,6 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct drm_crtc *crtc, } } - ipu_dmfc_config_wait4eot(ipu_plane->dmfc, crtc_w); - ret = ipu_dmfc_alloc_bandwidth(ipu_plane->dmfc, calc_bandwidth(crtc_w, crtc_h, calc_vref(mode)), 64); @@ -210,6 +208,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct drm_crtc *crtc, return ret; } + ipu_dmfc_config_wait4eot(ipu_plane->dmfc, crtc_w); + ipu_cpmem_zero(ipu_plane->ipu_ch); ipu_cpmem_set_resolution(ipu_plane->ipu_ch, src_w, src_h); ret = ipu_cpmem_set_fmt(ipu_plane->ipu_ch, fb->pixel_format); -- 2.5.0
drm: fix blob pointer check
On Fri, Mar 11, 2016 at 11:52:44AM +, Lionel Landwerlin wrote: > Hi Dan, > > Thanks a lot for pointing this out. I saw you previous comment but > didn't realize the issue. > I'll set the pointer to NULL. > > I don't if there is an agreement on this, but do you think the > unref/free functions should check for error pointers? I'm with the netdev people on this and think we shouldn't add sanity checks to free functions. For example, free_netdev(). If you always keep track of what is allocated and what is not then the code is easier to follow than if you start mixing them up and passing invalid pointers to other functions. If you handle errors right away that's simpler. regards, dan carpenter
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
>
>> - if (pcie_port_runtime_suspend_allowed(dev))
>> + if (pcie_port_runtime_suspend_allowed(dev)) {
>> + pm_runtime_allow(&dev->dev);
>
> PCI drivers typically have left this decision up to the userspace. I'm
> wondering whether it is good idea to deviate from that here? Of course
> this allows immediate power savings but could potentially cause problems
> as well.
>
No distro has ever shipped userspace to do this, I really think this
is a bad design.
We have wasted countless watts of power on this stupid idea that people will
run powertop, only a few people in the world run powertop, lots of
people use Linux.
The kernel should power stuff down not wait for the user to run powertop,
At least for the GPU it's in the area of 8W of power, and I've got the
GPU drivers doing this themselves,
I could have the GPU driver call runtime allow for it's host bridge I suppose,
if we insist on the userspace cares, but I'd prefer not doing so.
> I think we need to add corresponding call to pm_runtime_forbid() in
> pcie_portdrv_remove().
Yes most likely.
Dave.
>
>> pm_runtime_put_noidle(&dev->dev);
>> + }
>>
>> return 0;
>> }
>> @@ -436,6 +438,8 @@ static void pcie_portdrv_err_resume(struct pci_dev *dev)
>> * LINUX Device Driver Model
>> */
>> static const struct pci_device_id port_pci_ids[] = {
>> + /* Intel Skylake PCIE graphics port */
>> + { PCI_VDEVICE(INTEL, 0x0c01), .driver_data = PCIE_PORT_SPT },
>> /* Intel Broxton */
>> { PCI_VDEVICE(INTEL, 0x1ad6), .driver_data = PCIE_PORT_SPT },
>> { PCI_VDEVICE(INTEL, 0x1ad7), .driver_data = PCIE_PORT_SPT },
>> --
>> 2.5.0
>>
>
[Bug 94530] AMD R9 Nano reset problem
https://bugs.freedesktop.org/show_bug.cgi?id=94530 Bug ID: 94530 Summary: AMD R9 Nano reset problem Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: creakbeat at gmail.com I am trying to passthrough R9 Nano to a VM, and facing some problems. After Windows 7 has been installed, the latest AMD Crimson edition driver is installed. At first time, the driver works properly. There appears to have the problem when I power off the vm and restart it. The driver was not working until I reboot the host. Here is my system. Manufacturer: Supermicro Product Name: X10DAi CPU: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz memory: 8GB linux kernel: 3.19.0 $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.19.0 root=UUID=fc28306a-e168-406a-805d-cadf70de53ec ro quiet splash intel-iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 vt.handoff=7 I tried to use qemu version 2.3.1, 2.4.1, and 2.5.1. I also added the device id number into the function vfio_setup_resetfn(), but the problem remains. I start my virtual machine with the following code. qemu-system-x86_64 -enable-kvm \ -M pc -m 4096 -cpu host \ -smp 4,sockets=1,cores=4,threads=1 \ -rtc base=localtime \ -vnc :0 \ -vga none \ -device lsi,id=scsi0,bus=pci.0 \ -device vfio-pci,host=03:00.0,x-vga=on \ -device vfio-pci,host=03:00.1 \ -hda $1 \ -monitor stdio -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/8a9f9de8/attachment.html>
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >
> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
> >> + pm_runtime_allow(&dev->dev);
> >
> > PCI drivers typically have left this decision up to the userspace. I'm
> > wondering whether it is good idea to deviate from that here? Of course
> > this allows immediate power savings but could potentially cause problems
> > as well.
> >
>
> No distro has ever shipped userspace to do this, I really think this
> is a bad design.
> We have wasted countless watts of power on this stupid idea that people will
> run powertop, only a few people in the world run powertop, lots of
> people use Linux.
>
> The kernel should power stuff down not wait for the user to run powertop,
> At least for the GPU it's in the area of 8W of power, and I've got the
> GPU drivers doing this themselves,
>
> I could have the GPU driver call runtime allow for it's host bridge I suppose,
> if we insist on the userspace cares, but I'd prefer not doing so.
Yes, fully agreed. Runtime PM that's not enabled by default is useless,
since no one runs powertop, which also means it's buggy because no one
tests it. Not enabling power saving features by default is imo just a lame
excuse. Shit better just work, and tuneables should only exposed if
there's a real reason why autotuning is infeasible. E.g. we auto-ramp the
gpu clock down/up in i915 in software to compensate for some of the
silliness in how the hw does it alone. And the sysfs tunables are mostly
just to make benchmarking (where slower, but without any thermal
throttling) is sometimes preferred.
And yes i915 hasn't enabled rpm yet by default because there's bugs left
:(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init()
On Mon, Mar 14, 2016 at 3:59 AM, Kieran Bingham wrote: > On 14/03/16 01:07, Rob Clark wrote: >> On Sun, Mar 13, 2016 at 5:12 PM, Kieran Bingham >> wrote: >>> On 04/02/16 05:09, Archit Taneja wrote: On 02/03/2016 07:55 PM, Luis Henriques wrote: > This fixes the following build failure: > > drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function > `msm_dsi_pll_28nm_8960_init': > dsi_pll_28nm.c:(.text+0x1198): multiple definition of > `msm_dsi_pll_28nm_8960_init' > drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first > defined here Thanks for the fix. Acked-by: Archit Taneja Dave, Could you please queue this for the next -rc cycle since it causes a build break? >>> >>> I've just hit this build break on v4.5-rc7 ... was there any progress >>> getting this fix in ? I can't see any further reference to this thread >>> on LKML. >>> >>> Just to note, changing to a static generates a build-warning for me: >>> >>> CC drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o >>> In file included from >>> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c:17:0: >>> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h:100:28: warning: >>> âmsm_dsi_pll_28nm_8960_initâ defined but not used [-Wunused-function] >>> static struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct >>> platform_device *pdev, >>> ^ >> >> oh, the patch to change it to static inline was in my pull req for >> 4.6, but perhaps this should have been sent as a -fixes pull for 4.5? >> Dave, if you are sending another -fixes pull for 4.5 could you include >> this? > > I see a shiny new v4.5 tag this morning, so I guess we don't need to > worry about getting in there. Is it worth sending to -stable? > yeah, I think -stable material BR, -R
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
Hi Bastien, sorry for the delay. On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote: > We could, on boot, force using the integrated GPU, turning off the > discrete GPU that we're not interested in. Yes, many people "solve" this by having grub write the requisite commands to gmux' I/O ports, however this approach won't work with gummiboot. Also, the commands that need to be sent to gmux differ between retinas and pre-retinas. > So I'd push DIGD to the switch sysfs entry on boot. But I'm guessing > that won't turn off the other output we're not interested in. IGD and DIGD switch to the integrated GPU and also turn off the discrete GPU. However if the machine is already switched to the integrated GPU, the commands are no-ops and the discrete GPU is not turned off. In other words you need to check (by reading the switch file) which GPU the machine is switched to. If it's the integrated GPU, write OFF to the switch file. If it's the discrete GPU, write DIGD to the switch file. Once runtime pm works, writing DIGD is sufficient. > DIGD and DDIS should help (you need to log out/log in again), and if > the current GPU is the integrated one, you could force running, say, a > game on the discrete GPU using DRI_PRIME=1, correct? If runtime pm works, then yes. Otherwise you'd have to manually power up the GPU before using DRI_PRIME=1 and power it down afterwards. > FWIW, using OFF at runtime made my machine hang, and without any ways > for me to get debug output. Which GPU were you switched to? Did you issue the command while X11 was running? Since the machine is switched to the AMD on boot, I guess you were powering down the Intel GPU. This works on my machine, I get a log entry "i915: switched off". If this doesn't work on your machine it might be an i915 bug on your Sandy Bridge GPU or it might be because X11 is running. Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets you log output. If it doesn't, netconsole might help if the hang occurs while the console is locked. > Ok, so using GIGD or DDIS would just switch the output, but not turn > off the unused GPU without runtime PM management. No. They do switch off the other GPU if runtime pm is disabled. > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz       => gpu switching > > for 4.5 > That's the same patch that's already applied to the kernel above (the > ones from this patchset thread), right? I'm not sure, the patches in the copr repository might be an earlier test version. > My concerns here would be: > - Do we know how to turn off the integrated GPU automatically, if the > user only used the internal screen and wanted to use the discrete GPU? Runtime pm is currently disabled by default for i915. The Intel folks are on it. Until that works, the integrated GPU will be powered down when the user manually switches to the discrete GPU with DIS / DDIS and powered up when switching back with IGD / DIGD. > - If only the discrete GPU is powered on, do we know how to power on > the integrated GPU so it can drive the external screen when plugged in? On the MBP5 2008/09 and MBP6 2010, the external DP port can be switched between GPUs and we switch it together with the panel. So if you switch to the discrete GPU, you can also drive the external DP port on these models and the integrated GPU can be turned off. On the MBP8 2011 and newer, external ports are combined DP/Thunderbolt ports which can only be driven by the discrete GPU. For some reason the HPD/AUX pins of the ports can still be switched but not the other pins. We should nail these ports to the discrete GPU and not switch those pins together with the panel as we currently do. There's a patch in mbp_switcheroo_v5-4.5-runpm.tar.gz which fixes that. The patch also wakes up the discrete GPU on hotplug, which obviously needs runtime pm. > - While plymouth is short-lived at boot, Wayland and X11 GNOME sessions > use the GPU. The first user session will run on a VT that's separate > from the greeter to implement fast-user switching. So, if we wanted to > force using the other GPU for future sessions, we'd need to tell gdm to > kill its graphical session and to respawn it so it doesn't hog the GPU > and avoid the switch happening. Correct? I think so, yes. > On the 8,2, still, and with the kernel from the COPR repo[1]. > > I tried running: > echo DIGD > switch > > to (later) switch to the integrated GPU. Log out, get to gdm, log back > in to a black screen with the cursor visible and nothing else. > > I'm wondering if it's the gdm X11 session running in the background > that makes this fail. That's possible, I have no idea. I have zero issues with GPU switching on my Nvidia-based MacBook Pro, though I only switch on the console with no X11 running. On the AMD-based MBP8 that you're using, the patches have only been tested by William Brown, a colleague of yours at Red Hat Australia. If you send me dmesg output with "drm.debug=0xf log_buf_len=10M
[Bug 93591] [TONGA] ARK Survival Evolved: corruption of main menu textures
https://bugs.freedesktop.org/show_bug.cgi?id=93591 --- Comment #5 from Nicolai H�hnle --- So, I've looked into this again out of curiosity, because I do have an LLVM patch that can be used to work around this. However, the patch introduces some inefficiencies, and this is a game bug: it is clear from playing with the provided apitrace that a derivative is taken after a non-uniform discard/kill, which is undefined behaviour in GLSL. Does anybody paying attention to this bug report know of a way to contact the game developer about this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/0cf366f3/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #119 from Nicolai H�hnle --- For what it's worth, I'd encourage people to update their graphics stack to latest everything (including kernel + X.Org server) and see if they still get lockups. I haven't been able to reproduce this anymore in my last two attempts - I don't know if I've just been lucky, but it might have been fixed randomly. Unfortunately, too much has changed on my system between reproduction attempts to be able to say exactly what might have fixed it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/22679dcd/attachment.html>
[Bug 94405] radeon GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=94405 --- Comment #2 from Nicolai H�hnle --- Why did you mark this as NOTABUG? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/6ab9bb03/attachment.html>
[Bug 94405] radeon GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=94405 --- Comment #3 from Lorenzo Bona --- (In reply to Nicolai H�hnle from comment #2) > Why did you mark this as NOTABUG? Hi Nicolai, I mark this as not a bug because I reset my git and find out there are 2 changes in hw/xfree86/common/xf86Module.h lines 83-84 #define ABI_VIDEODRV_VERSIONSET_ABI_VERSION(21, 0) #define ABI_XINPUT_VERSIONSET_ABI_VERSION(22, 1) something I've modified in the past. I've reverted my local changes and now it's working correctly. Cheers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/1318a37a/attachment.html>
[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1
https://bugs.freedesktop.org/show_bug.cgi?id=93652 --- Comment #5 from Nicolai H�hnle --- Thanks for the reports. Those backtraces are typical consequences of a GPU hang and are unfortunately not helpful for isolating the root cause. One thing you could try is starting Steam with R600_DEBUG=nodcc from a terminal window. Also, if it doesn't take too long for the hang to occur (Wolfgang mentions a few minutes), you could try recording an apitrace, and see whether you also get a lockup when you replay the trace. Such a trace would be very helpful. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/5351c988/attachment.html>
[patch] drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()
On Fri, Mar 11, 2016 at 9:51 AM, Dan Carpenter
wrote:
> At the end of the function we expect "status" to be zero, but it's
> either -EINVAL or unitialized.
>
> Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
> index c34c393..d5e19b5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
> @@ -513,7 +513,7 @@ static int dbgdev_wave_control_set_registers(
> union SQ_CMD_BITS *in_reg_sq_cmd,
> union GRBM_GFX_INDEX_BITS *in_reg_gfx_index)
> {
> - int status;
> + int status = 0;
> union SQ_CMD_BITS reg_sq_cmd;
> union GRBM_GFX_INDEX_BITS reg_gfx_index;
> struct HsaDbgWaveMsgAMDGen2 *pMsg;
Thanks,
applied to my fixes tree.
Oded
[PATCH] drm/exynos: fix error handling in exynos_drm_subdrv_open
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:
drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always
evaluates to false [-Werror=tautological-compare]
list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.
If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the &exynos_drm_subdrv_list anchor,
which would be even worse.
Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.
Signed-off-by: Arnd Bergmann
Fixes: 9084f7b8a577 ("drm/exynos: add subdrv open/close functions")
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 7f55ba6771c6..011211e4167d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -101,7 +101,7 @@ int exynos_drm_subdrv_open(struct drm_device *dev, struct
drm_file *file)
return 0;
err:
- list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
+ list_for_each_entry_continue_reverse(subdrv, &exynos_drm_subdrv_list,
list) {
if (subdrv->close)
subdrv->close(dev, subdrv->dev, file);
}
--
2.7.0
[PATCH] nouveau: fix nv40_perfctr_next() cleanup regression
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison
always evaluats to false [-Wtautological-compare]
if (pm->sequence != pm->sequence) {
The behavior was accidentally introduced in a patch described as "This is
purely preparation for upcoming commits, there should be no code changes here.".
As far as I can tell, that was true for the rest of that patch except for
this one function, which has been changed to a NOP.
This patch restores the original behavior.
Signed-off-by: Arnd Bergmann
Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")
---
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
index 4bef72a9d106..3fda594700e0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
@@ -59,9 +59,11 @@ static void
nv40_perfctr_next(struct nvkm_pm *pm, struct nvkm_perfdom *dom)
{
struct nvkm_device *device = pm->engine.subdev.device;
- if (pm->sequence != pm->sequence) {
+ struct nv40_pm *nv40pm = container_of(pm, struct nv40_pm, base);
+
+ if (nv40pm->sequence != pm->sequence) {
nvkm_wr32(device, 0x400084, 0x0020);
- pm->sequence = pm->sequence;
+ nv40pm->sequence = pm->sequence;
}
}
--
2.7.0
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Sun, Mar 13, 2016 at 10:19 PM, Dave Airlie wrote: > On 11 March 2016 at 23:45, Rafael J. Wysocki wrote: >> On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote: >>> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote: >>> > > It doesn't seem to do any runtime PM, >>> > > I do wonder if pcieport should be doing it's own runtime PM handling, >>> > > but that is a >>> > > larger task than I'm thinking to tackle here. >>> > >>> > PCIe ports don't do PM - yet. Mika has posted a series of patches to >>> > implement >>> > that, however, that are waiting for comments now: >>> > >>> > https://patchwork.kernel.org/patch/8453311/ >>> > https://patchwork.kernel.org/patch/8453381/ >>> > https://patchwork.kernel.org/patch/8453391/ >>> > https://patchwork.kernel.org/patch/8453411/ >>> > https://patchwork.kernel.org/patch/8453371/ >>> > https://patchwork.kernel.org/patch/8453351/ >>> > >>> > > Maybe I should be doing >>> > > >>> > > pci_set_power_state(pdev->bus->self, PCI_D3cold) ? I'm not really sure. >>> > >>> > Using pci_set_power_state() would be more appropriate IMO, but you can get >>> > to the bridge via dev->parent too, can't you? >>> > >>> > In any case, it looks like you and Mika need to talk. :-) >>> >>> When the vga_switcheroo device gets runtime suspended (with the above >>> runtime PM patchs for PCIe root ports) the root port should also be >>> runtime suspended by the PM core. >> >> Right, after your patches have been applied, the additional handling >> won't be needed. >> >> So Dave, maybe you can check if the Mika's patches help? > > Hi Mika, > > I tested your patches with a couple of changes on the Lenovo W541. > > The attached patch contains the two things I needed to get the same > functionality > as my patches. > > I'm really not in love with the per-chipset enablement for this, > really any chipsets > after a certain year should probably be better, as we'll constantly be > adding PCI Ids > for every chipset ever made, and I expect we'll forget some. Yeah, I don't care of that either. There are always going to be chipsets falling through the cracks. Alex > > Dave. > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
[RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Passing overlapping source and destination buffers to snprintf > formally has undefined behaviour and is rather fragile. While the > rather special case of passing the output buffer as the argument > corresponding to a leading "%s" in the format string currently works > with the kernel's printf implementation, that won't necessarily always > be the case (it's also needlessly inefficient, though that doesn't > matter much for sysfs files). Moreover, it might give the false > impression that other ways of overlapping source and destination > buffers would be ok. > > The standard way of appending to a buffer with snprintf is to keep > track of the current string length (and thus also the remaining > available space). Using scnprintf ensures that the 'ret' variable will > always be strictly less than PAGE_SIZE, so we'll never pass a negative > buffer size to scnprintf, and we'll return the proper length to the > upper sysfs layer, whether truncation has happened or not. > > Signed-off-by: Rasmus Villemoes I saw there were some different opinions on this. Have the fixes to the other drivers been taken ? Oded
[Bug 112781] radeon: f95429e "only init fbdev if we have connectors" breaks suspend on Clevo P170EM laptop
https://bugzilla.kernel.org/show_bug.cgi?id=112781 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- Created attachment 209091 --> https://bugzilla.kernel.org/attachment.cgi?id=209091&action=edit fix The attached patch should fix it. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/etnaviv: move GPU linear window to end of DMA window
Am Mittwoch, den 09.03.2016, 12:25 + schrieb Russell King - ARM Linux: > On Mon, Feb 29, 2016 at 05:20:16PM +0100, Lucas Stach wrote: > > If the end of the system DMA window is farther away from the start of > > physical RAM than the size of the GPU linear window, move the linear > > window so that it ends at the same address than the system DMA window. > > > > This allows to map command buffer from CMA, which is likely to reside > > at the end of the system DMA window, while also overlapping as much > > RAM as possible, in order to optimize regular buffer mappings through > > the linear window. > > I've been pondering this for a while now, and I think we should not > do this unconditionally - it should be predicated on the MC20 feature - > both for the original code and the new code. If we don't have the MC20 > feature, we end up with more memory spaces than we can cope with. > > If we don't have MC20, but we need to offset, that's an error which > can lead to memory corruption. > This makes sense. I guess not using the offset on MC10 will also allow you to enable TS on those parts? In that case we might advertise this with a patchlevel change of the API. Regards, Lucas
[PATCH] drm/etnaviv: move GPU linear window to end of DMA window
On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote: > I guess not using the offset on MC10 will also allow you to enable TS on > those parts? In that case we might advertise this with a patchlevel > change of the API. I don't think we need that - it isn't an API change as such. What we could do is to clear the fast clear capability for GPUs where the base is non-zero but has MC10, which basically means we don't use tile status. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] drm/etnaviv: move GPU linear window to end of DMA window
Am Montag, den 14.03.2016, 15:09 + schrieb Russell King - ARM Linux: > On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote: > > I guess not using the offset on MC10 will also allow you to enable TS on > > those parts? In that case we might advertise this with a patchlevel > > change of the API. > > I don't think we need that - it isn't an API change as such. What > we could do is to clear the fast clear capability for GPUs where the > base is non-zero but has MC10, which basically means we don't use > tile status. > With kernel 4.5 being released now, we already have a kernel version that may change the offset, while not clearing the fast clear capability bit. So I think we need another way for userspace to know if the kernel is doing the right thing for MC10.
[Bug 112781] radeon: f95429e "only init fbdev if we have connectors" breaks suspend on Clevo P170EM laptop
https://bugzilla.kernel.org/show_bug.cgi?id=112781 --- Comment #3 from Christoph Haag --- 4.5 with the patch seems to suspend without problems, thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
[GIT PULL] drm-vc4-next for 4.6
Merge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-next (2016-03-14 09:48:04 +1000) are available in the git repository at: git at github.com:anholt/linux.git tags/drm-vc4-next-2016-03-14 for you to fetch changes up to 90d7116061f86c1f8ea460806a0414addea7b58b: drm/vc4: Recognize a more specific compatible string for V3D. (2016-03-13 18:54:24 -0700) This pull request covers what's left for 4.6. Notably, it includes a significant 3D performance improvement and a fix to HDMI hotplug detection for the Pi2/3. Dan Carpenter (1): drm/vc4: Return -EFAULT on copy_from_user() failure Eric Anholt (4): drm/vc4: Let gpiolib know that we're OK with sleeping for HPD. drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree. dt-bindings: Add binding docs for V3D. drm/vc4: Recognize a more specific compatible string for V3D. Varad Gautam (1): drm/vc4: improve throughput by pipelining binning and rendering jobs .../devicetree/bindings/display/brcm,bcm-vc4.txt | 12 ++ drivers/gpu/drm/vc4/vc4_bo.c | 7 +- drivers/gpu/drm/vc4/vc4_drv.h | 37 +-- drivers/gpu/drm/vc4/vc4_gem.c | 123 +++-- drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +- drivers/gpu/drm/vc4/vc4_irq.c | 58 -- drivers/gpu/drm/vc4/vc4_v3d.c | 1 + 7 files changed, 193 insertions(+), 57 deletions(-)
[PATCH v9] dma-buf: Add ioctls to allow userspace to flush
On 03/05/2016 06:34 AM, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 03:02:09PM +, Chris Wilson wrote:
>> On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
>>> On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> +static long dma_buf_ioctl(struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct dma_buf *dmabuf;
> + struct dma_buf_sync sync;
> + enum dma_data_direction direction;
> +
> + dmabuf = file->private_data;
> +
> + switch (cmd) {
> + case DMA_BUF_IOCTL_SYNC:
> + if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
> + return -EFAULT;
> +
> + if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> + return -EINVAL;
> +
> + switch (sync.flags & DMA_BUF_SYNC_RW) {
> + case DMA_BUF_SYNC_READ:
> + direction = DMA_FROM_DEVICE;
> + break;
> + case DMA_BUF_SYNC_WRITE:
> + direction = DMA_TO_DEVICE;
> + break;
> + case DMA_BUF_SYNC_RW:
> + direction = DMA_BIDIRECTIONAL;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (sync.flags & DMA_BUF_SYNC_END)
> + dma_buf_end_cpu_access(dmabuf, direction);
> + else
> + dma_buf_begin_cpu_access(dmabuf, direction);
We forgot to report the error back to userspace. Might as well fixup the
callchain to propagate error from end-cpu-access as well. Found after
updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.
>>>
>>> EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
>>> patches? See drmIoctl() in libdrm for what's needed on the userspace side
>>> if my guess is right.
>>
>> EINTR is the easiest, but conceivably we could also get EIO and
>> currently EAGAIN.
>>
>> I am also seeing some strange timing dependent (i.e. valgrind doesn't
>> show up anything client side and the tests then pass) failures (SIGSEGV,
>> SIGBUS) with !llc.
>
> Tiago, ping. Also probably a gap in igt coverage besides the kernel side.
> -Daniel
Hey guys! I'm back from vacation now. I'll take a look on it in the next
days and then come back to you.
Tiago
[PATCH v8 1/2] staging/android: remove redundant comments on sync_merge_data
From: Gustavo Padovan
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
* @fence: returns the fd of the new fence to userspace
*/
struct sync_merge_data {
- __s32 fd2; /* fd of second fence */
- charname[32]; /* name of new fence */
- __s32 fence; /* fd on newly created fence */
+ __s32 fd2;
+ charname[32];
+ __s32 fence;
};
/**
--
2.5.0
[PATCH v8 2/2] staging/android: refactor SYNC IOCTLs
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
Acked-by: Greg Hackmann
Acked-by: Rob Clark
Acked-by: Daniel Vetter
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
v5: merge all commits that were changing the ABI
---
drivers/staging/android/sync.c | 76 -
drivers/staging/android/uapi/sync.h | 36 +-
2 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..ae81c95 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
+ if (info.flags || info.pad)
return -EINVAL;
- if (size > 4096)
- size = 4096;
-
- info = kzalloc(size, GFP_KERNEL);
-
[PATCH] drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init()
On 14/03/16 01:07, Rob Clark wrote:
> On Sun, Mar 13, 2016 at 5:12 PM, Kieran Bingham
> wrote:
>> On 04/02/16 05:09, Archit Taneja wrote:
>>>
>>>
>>> On 02/03/2016 07:55 PM, Luis Henriques wrote:
This fixes the following build failure:
drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function
`msm_dsi_pll_28nm_8960_init':
dsi_pll_28nm.c:(.text+0x1198): multiple definition of
`msm_dsi_pll_28nm_8960_init'
drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first
defined here
>>>
>>> Thanks for the fix.
>>>
>>> Acked-by: Archit Taneja
>>>
>>> Dave,
>>>
>>> Could you please queue this for the next -rc cycle since it causes a
>>> build break?
>>>
>>
>> I've just hit this build break on v4.5-rc7 ... was there any progress
>> getting this fix in ? I can't see any further reference to this thread
>> on LKML.
>>
>> Just to note, changing to a static generates a build-warning for me:
>>
>> CC drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o
>> In file included from
>> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c:17:0:
>> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h:100:28: warning:
>> âmsm_dsi_pll_28nm_8960_initâ defined but not used [-Wunused-function]
>> static struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
>> platform_device *pdev,
>> ^
>
> oh, the patch to change it to static inline was in my pull req for
> 4.6, but perhaps this should have been sent as a -fixes pull for 4.5?
> Dave, if you are sending another -fixes pull for 4.5 could you include
> this?
I see a shiny new v4.5 tag this morning, so I guess we don't need to
worry about getting in there. Is it worth sending to -stable?
> Not sure about the warning (I don't see that, but I have static-inline
> vs static)
Ah yes of course ... Just double checked here, and I had dropped the
inline in my sleep deprived state. So no worries about the warning.
Regards
Kieran
>
> BR,
> -R
>
>
>> --
>> Kieran
>>
>>> Thanks,
>>> Archit
>>>
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
index 80b6038334a6..2cf1664723e8 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
@@ -97,8 +97,8 @@ static inline struct msm_dsi_pll
*msm_dsi_pll_28nm_init(
struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
int id);
#else
-struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device
*pdev,
- int id)
+static inline struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(
+struct platform_device *pdev, int id)
{
return ERR_PTR(-ENODEV);
}
>>>
>>
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> On 11 March 2016 at 23:45, Rafael J. Wysocki wrote:
> > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> >> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> >> > > It doesn't seem to do any runtime PM,
> >> > > I do wonder if pcieport should be doing it's own runtime PM handling,
> >> > > but that is a
> >> > > larger task than I'm thinking to tackle here.
> >> >
> >> > PCIe ports don't do PM - yet. Mika has posted a series of patches to
> >> > implement
> >> > that, however, that are waiting for comments now:
> >> >
> >> > https://patchwork.kernel.org/patch/8453311/
> >> > https://patchwork.kernel.org/patch/8453381/
> >> > https://patchwork.kernel.org/patch/8453391/
> >> > https://patchwork.kernel.org/patch/8453411/
> >> > https://patchwork.kernel.org/patch/8453371/
> >> > https://patchwork.kernel.org/patch/8453351/
> >> >
> >> > > Maybe I should be doing
> >> > >
> >> > > pci_set_power_state(pdev->bus->self, PCI_D3cold) ? I'm not really sure.
> >> >
> >> > Using pci_set_power_state() would be more appropriate IMO, but you can
> >> > get
> >> > to the bridge via dev->parent too, can't you?
> >> >
> >> > In any case, it looks like you and Mika need to talk. :-)
> >>
> >> When the vga_switcheroo device gets runtime suspended (with the above
> >> runtime PM patchs for PCIe root ports) the root port should also be
> >> runtime suspended by the PM core.
> >
> > Right, after your patches have been applied, the additional handling
> > won't be needed.
> >
> > So Dave, maybe you can check if the Mika's patches help?
>
> Hi Mika,
>
> I tested your patches with a couple of changes on the Lenovo W541.
Thanks for testing.
> The attached patch contains the two things I needed to get the same
> functionality
> as my patches.
>
> I'm really not in love with the per-chipset enablement for this,
> really any chipsets
> after a certain year should probably be better, as we'll constantly be
> adding PCI Ids
> for every chipset ever made, and I expect we'll forget some.
Bjorn also had the same comment. I think I'll change it to use cut-off
date instead of list of PCI IDs of nobody objects.
> Dave.
> From eea412076c9d24262ebd4811f766d5379b728045 Mon Sep 17 00:00:00 2001
> From: Dave Airlie
> Date: Mon, 14 Mar 2016 23:37:43 +1000
> Subject: [PATCH] [RFC] PCI: enable runtime PM on pcieports to let secondary
> GPUs powerdown.
>
> With secondary GPUs in Windows 10 laptops we need to use runtime PM
> to power down the PCIe ports after the devices goes to D3Cold.
>
> This patch adds the PCI ID for the Haswell 16x PCIE slot found
> in the W541 laptops. I should probably try and gather the PCI IDs,
> for broadwell/skylake variants as well if we can't find them.
>
> This fixes a regression on W541 laptops on top of Mika's PCIE patches
> since we started advertising Windows 2013 ACPI.
>
> [probably should be two patches - hence RFC]
>
> Signed-off-by: Dave Airlie
> ---
> drivers/pci/pcie/portdrv_pci.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
> index 43dd23e..1405de8 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -278,8 +278,10 @@ static int pcie_portdrv_probe(struct pci_dev *dev,
>
> pci_save_state(dev);
>
> - if (pcie_port_runtime_suspend_allowed(dev))
> + if (pcie_port_runtime_suspend_allowed(dev)) {
> + pm_runtime_allow(&dev->dev);
PCI drivers typically have left this decision up to the userspace. I'm
wondering whether it is good idea to deviate from that here? Of course
this allows immediate power savings but could potentially cause problems
as well.
I think we need to add corresponding call to pm_runtime_forbid() in
pcie_portdrv_remove().
> pm_runtime_put_noidle(&dev->dev);
> + }
>
> return 0;
> }
> @@ -436,6 +438,8 @@ static void pcie_portdrv_err_resume(struct pci_dev *dev)
> * LINUX Device Driver Model
> */
> static const struct pci_device_id port_pci_ids[] = {
> + /* Intel Skylake PCIE graphics port */
> + { PCI_VDEVICE(INTEL, 0x0c01), .driver_data = PCIE_PORT_SPT },
> /* Intel Broxton */
> { PCI_VDEVICE(INTEL, 0x1ad6), .driver_data = PCIE_PORT_SPT },
> { PCI_VDEVICE(INTEL, 0x1ad7), .driver_data = PCIE_PORT_SPT },
> --
> 2.5.0
>
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >
> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
> >> + pm_runtime_allow(&dev->dev);
> >
> > PCI drivers typically have left this decision up to the userspace. I'm
> > wondering whether it is good idea to deviate from that here? Of course
> > this allows immediate power savings but could potentially cause problems
> > as well.
> >
>
> No distro has ever shipped userspace to do this, I really think this
> is a bad design.
> We have wasted countless watts of power on this stupid idea that people will
> run powertop, only a few people in the world run powertop, lots of
> people use Linux.
That is a fair point.
I do not have anything against calling pm_runtime_allow() here. In fact
we already do the same in Intel LPSS drivers. I just wanted to bring
that up.
Rafael, what do you think?
If we anyway are going to add cut-off date to enable runtime PM we
should expect that the hardware is also capable of doing so (and if not
we can always blacklist the exceptions).
> The kernel should power stuff down not wait for the user to run powertop,
> At least for the GPU it's in the area of 8W of power, and I've got the
> GPU drivers doing this themselves,
>
> I could have the GPU driver call runtime allow for it's host bridge I suppose,
> if we insist on the userspace cares, but I'd prefer not doing so.
>
> > I think we need to add corresponding call to pm_runtime_forbid() in
> > pcie_portdrv_remove().
>
> Yes most likely.
BTW, I can add both calls to the next version of PCIe runtime PM patches
if you are OK with that, and all agree this is a good idea.
[PATCH 1/4 v3] drm: Add support of ARC PGU display controller
Hi Daniel,
On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> >
> > ARC PGU could be found on some development boards from Synopsys.
> > This is a simple byte streamer that reads data from a framebuffer
> > and sends data to the single encoder.
> >
> > Signed-off-by: Alexey Brodkin
> > Cc: David Airlie
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: linux-snps-arc at lists.infradead.org
> > Cc: Jose Abreu
> > ---
> >
> > Changes v2 -> v3:
> > Â * Improved failure path if arcpgu_connector wasn't allocated (thanks
> > Jose).
> > Â * Fixed driver building as module (reported by 0-DAY kernel test
> > infrastruct.)
> > Â * Implemented uncached mapping of user-space FB pages.
> >
> > No changes v1 -> v2.
> >
> Bunch of comments below to update your driver to latest styles and best
> practices.
>
> Cheers, Daniel
Thanks for doing that review!
> > +
> > +static void arc_pgu_crtc_atomic_flush(struct drm_crtc *crtc,
> > + Â Â Â Â Â Â struct drm_crtc_state *state)
> > +{
> > +}
> > +
> > +static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
> > + Â Â Â Â const struct drm_display_mode *mode,
> > + Â Â Â Â struct drm_display_mode *adjusted_mode)
> > +{
> > + return true;
> > +}
> You can drop the above 2 dummy functions.
Ok will do.
> >
> > +
> > +static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
> > + .mode_fixup = arc_pgu_crtc_mode_fixup,
> > + .mode_set = drm_helper_crtc_mode_set,
> > + .mode_set_base = drm_helper_crtc_mode_set_base,
> > + .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
> > + .enable = arc_pgu_crtc_enable,
> > + .disable= arc_pgu_crtc_disable,
> > + .prepare= arc_pgu_crtc_disable,
> > + .commit = arc_pgu_crtc_enable,
> > + .atomic_check = arc_pgu_crtc_atomic_check,
> > + .atomic_begin = arc_pgu_crtc_atomic_begin,
> > + .atomic_flush = arc_pgu_crtc_atomic_flush,
> > +};
> > +
> > +static int arc_pgu_plane_atomic_check(struct drm_plane *plane,
> > + Â Â Â Â Â Â struct drm_plane_state *state)
> > +{
> > + return 0;
> > +}
> You don't need dummy functions for this.
Ditto.
> > +
> > +void arc_pgu_crtc_suspend(struct drm_crtc *crtc)
> > +{
> > + arc_pgu_crtc_disable(crtc);
> > +}
> > +
> > +void arc_pgu_crtc_resume(struct drm_crtc *crtc)
> > +{
> > + arc_pgu_crtc_enable(crtc);
> > +}
> Please use the atomic suspend/resume helper that Thierry recently merged.
> See the kerneldoc of drm_atomic_helper_suspend as a starting point for how
> it works and how it's supposed to be used.
Well looks like this is a reminder if dummy copy-paste.
We don't support PM in that driver yet, so I'll remove both functions
for now.
> > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > + Â Â Â Â struct drm_atomic_state *state, bool
> > async)
> > +{
> > + return drm_atomic_helper_commit(dev, state, false);
> Note that this isn't really async if you ever get around to implement
> fence support or vblank support. Just fyi.
Ok but for now should I leave it as it is?
> > +static struct drm_driver arcpgu_drm_driver = {
> > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> > + Â Â Â DRIVER_ATOMIC,
> > + .preclose = arcpgu_preclose,
> > + .lastclose = arcpgu_lastclose,
> > + .name = "drm-arcpgu",
> > + .desc = "ARC PGU Controller",
> > + .date = "20160219",
> > + .major = 1,
> > + .minor = 0,
> > + .patchlevel = 0,
> > + .fops = &arcpgu_drm_ops,
> > + .load = arcpgu_load,
> > + .unload = arcpgu_unload,
> Load and unload hooks are deprecated (it's a classic midlayer mistake).
> Please use drm_dev_alloc/register pairs directly instead, and put your
> device setup code in-between. Similar for unloading. There's a bunch of
> example drivers converted already.
Ok I took "atmel-hlcdc" as example.
And that's interesting.
If I put my arcpgu_load() in between drm_dev_alloc() and
drm_dev_register() then I'm getting this on the driver probe:
-->8---
[drm] Initialized drm 1.1.0 20060810
arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
[ cut here ]
WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 kobject_add_internal+0x17c/0x498()
kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17
Stack Trace:
 arc_unwind_core.constprop.1+0xa4/0x110
 warn_slowpath_fmt+0x6e/0xfc
 kobject_add_internal+0x17c/0x498
 kobject_add+0x98/0xe4
 device_add+0xc6/0x734
 device_create_with_groups+0x12a/0x144
 drm_sysfs_connector_add+0x54/0xe8
 arcpgu_drm_hdmi_init+0xd4/0x17c
 arcpgu_probe+0x138/0x24c
 platform_drv_probe+0x2e/0x6c
 really_probe+0x212/0x35c
 __driv
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Mon, Mar 14, 2016 at 11:23 AM, Mika Westerberg
wrote:
> On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
>> >
>> >> - if (pcie_port_runtime_suspend_allowed(dev))
>> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
>> >> + pm_runtime_allow(&dev->dev);
>> >
>> > PCI drivers typically have left this decision up to the userspace. I'm
>> > wondering whether it is good idea to deviate from that here? Of course
>> > this allows immediate power savings but could potentially cause problems
>> > as well.
>> >
>>
>> No distro has ever shipped userspace to do this, I really think this
>> is a bad design.
>> We have wasted countless watts of power on this stupid idea that people will
>> run powertop, only a few people in the world run powertop, lots of
>> people use Linux.
>
> That is a fair point.
>
> I do not have anything against calling pm_runtime_allow() here. In fact
> we already do the same in Intel LPSS drivers. I just wanted to bring
> that up.
>
> Rafael, what do you think?
We can do that to start with. If there are no problems in the field
with it, I don't see any problems in principle.
> If we anyway are going to add cut-off date to enable runtime PM we
> should expect that the hardware is also capable of doing so (and if not
> we can always blacklist the exceptions).
Sounds reasonable.
>> The kernel should power stuff down not wait for the user to run powertop,
>> At least for the GPU it's in the area of 8W of power, and I've got the
>> GPU drivers doing this themselves,
>>
>> I could have the GPU driver call runtime allow for it's host bridge I
>> suppose,
>> if we insist on the userspace cares, but I'd prefer not doing so.
>>
>> > I think we need to add corresponding call to pm_runtime_forbid() in
>> > pcie_portdrv_remove().
>>
>> Yes most likely.
>
> BTW, I can add both calls to the next version of PCIe runtime PM patches
> if you are OK with that, and all agree this is a good idea.
That would be fine by me.
Thanks,
Rafael
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote: > Hi Bastien, > > sorry for the delay. > > On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote: > > > > We could, on boot, force using the integrated GPU, turning off the > > discrete GPU that we're not interested in. > Yes, many people "solve" this by having grub write the requisite > commands > to gmux' I/O ports, however this approach won't work with gummiboot. > Also, the commands that need to be sent to gmux differ between > retinas > and pre-retinas. Which is why I'd be fine with having user-space doing it later on. I don't think users should have to poke at the boot parameters under normal circumstances. > > So I'd push DIGD to the switch sysfs entry on boot. But I'm > > guessing > > that won't turn off the other output we're not interested in. > IGD and DIGD switch to the integrated GPU and also turn off the > discrete > GPU. However if the machine is already switched to the integrated > GPU, > the commands are no-ops and the discrete GPU is not turned off. > > In other words you need to check (by reading the switch file) which > GPU > the machine is switched to. If it's the integrated GPU, write OFF to > the > switch file. If it's the discrete GPU, write DIGD to the switch file. > > Once runtime pm works, writing DIGD is sufficient. This isn't the greatest API, but let me make a note of that: https://github.com/hadess/switcheroo-control/issues/1 I guess that's only useful until we get runtime PM support. > > DIGD and DDIS should help (you need to log out/log in again), and > > if > > the current GPU is the integrated one, you could force running, > > say, a > > game on the discrete GPU using DRI_PRIME=1, correct? > If runtime pm works, then yes. Otherwise you'd have to manually power > up > the GPU before using DRI_PRIME=1 and power it down afterwards. Another need for run-time PM. > > FWIW, using OFF at runtime made my machine hang, and without any > > ways > > for me to get debug output. > Which GPU were you switched to? Did you issue the command while X11 > was > running? Since the machine is switched to the AMD on boot, I guess > you > were powering down the Intel GPU. This works on my machine, I get a > log > entry "i915: switched off". If this doesn't work on your machine it > might > be an i915 bug on your Sandy Bridge GPU or it might be because X11 is > running. > > Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets > you > log output. If it doesn't, netconsole might help if the hang occurs > while > the console is locked. I'll try it out with your runtime PM patches on top of the latest upstream one. > > Ok, so using GIGD or DDIS would just switch the output, but not > > turn > > off the unused GPU without runtime PM management. > No. They do switch off the other GPU if runtime pm is disabled. > > > > > > > > > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz       => gpu > > > switching > > > for 4.5 > > That's the same patch that's already applied to the kernel above > > (the > > ones from this patchset thread), right? > I'm not sure, the patches in the copr repository might be an earlier > test version. Might explain the problems I had. > > My concerns here would be: > > - Do we know how to turn off the integrated GPU automatically, if > > the > > user only used the internal screen and wanted to use the discrete > > GPU? > Runtime pm is currently disabled by default for i915. The Intel folks > are on it. Until that works, the integrated GPU will be powered down > when the user manually switches to the discrete GPU with DIS / DDIS > and powered up when switching back with IGD / DIGD. Do we have a way to know whether runtime PM is available for one/both GPUs in the machine? Otherwise this really explodes the testing grid, and it really makes everything harder. > > - If only the discrete GPU is powered on, do we know how to power > > on > > the integrated GPU so it can drive the external screen when plugged > > in? > On the MBP5 2008/09 and MBP6 2010, the external DP port can be > switched > between GPUs and we switch it together with the panel. So if you > switch > to the discrete GPU, you can also drive the external DP port on these > models and the integrated GPU can be turned off. > > On the MBP8 2011 and newer, external ports are combined > DP/Thunderbolt > ports which can only be driven by the discrete GPU. For some reason > the > HPD/AUX pins of the ports can still be switched but not the other > pins. > We should nail these ports to the discrete GPU and not switch those > pins > together with the panel as we currently do. There's a patch in > mbp_switcheroo_v5-4.5-runpm.tar.gz which fixes that. The patch also > wakes > up the discrete GPU on hotplug, which obviously needs runtime pm. So that's something else that we can't handle properly without runtime PM support. > > - While plymouth is short-lived at boot, Wayland and X11 GNOME > > sessions > > use the GPU. The f
[PATCH v15 1/3] drm: rockchip: Add basic drm driver
On 2 December 2014 at 10:15, Mark Yao wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> new file mode 100644
> index 000..e7ca25b
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -0,0 +1,1455 @@
...
> +static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
> + return false;
Hi Mark,
what's the rationale for this?
Disabling a CRTC as in [0] will cause mode_fixup() to be called with
an empty mode, failing that test.
Removing the check seems to get things working fine for a short while,
but a later modeset invariably gets the VOP to hang (as reported by
[1]).
Do you know why that check was put in place and what exactly could be
causing the hw to hang?
[0]
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
[1]
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
Thanks,
Tomeu
> +
> + return true;
> +}
linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c: 5 * uninit data ?
Hello there, [linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized struct member: clock.dot [linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized struct member: clock.m1 [linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized struct member: clock.m2 [linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized struct member: clock.p2 [linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized struct member: clock.vco Source code is                    *best_clock = clock; Suggest init all fields of local variable clock shortly after declaration, that way the function mrst_sdvo_find_best_pll can only ever return init'ed data. Regards David Binderman
DISTRIBUTE A NECESSARY SAFETY PRODUCT
26 YEAR OLD U.S. COMPANY NEEDS DISTRIBUTORS IN MANY COUNTRIES for our amazing slip-resistant floor product. One 30 minute application with our Amazing Anti-Slip Floor Treatment will make floors slip-resistant and safe for 4 years - Guaranteed! Indoors or Outdoors No Change in Appearance Typical Applications: Restaurant Kitchen Floors, Hotels, Hospitals, Office Buildings, etc. For use on: Ceramic, Porcelain and Quarry Tiles, Marble, Granite, Concrete, etc. Some of our satisfied customers: McDonald's, Kroger, Holiday Inn, Miami Children's Hospital Pfizer, etc. Please contact us for details and to see if there is a distributorship available in your country. $2,000-$4,000 INVENTORY INVESTMENT REQUIRED PLEASE INCLUDE YOUR NAME, COUNTRY & E-MAIL ADDRESS Jason Williams Email: carerynt at sina.com
[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.
On Mon, Mar 14, 2016 at 01:50:41PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 14, 2016 at 11:23 AM, Mika Westerberg
> wrote:
> > On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >> >
> >> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
> >> >> + pm_runtime_allow(&dev->dev);
> >> >
> >> > PCI drivers typically have left this decision up to the userspace. I'm
> >> > wondering whether it is good idea to deviate from that here? Of course
> >> > this allows immediate power savings but could potentially cause problems
> >> > as well.
> >> >
> >>
> >> No distro has ever shipped userspace to do this, I really think this
> >> is a bad design.
> >> We have wasted countless watts of power on this stupid idea that people
> >> will
> >> run powertop, only a few people in the world run powertop, lots of
> >> people use Linux.
> >
> > That is a fair point.
> >
> > I do not have anything against calling pm_runtime_allow() here. In fact
> > we already do the same in Intel LPSS drivers. I just wanted to bring
> > that up.
> >
> > Rafael, what do you think?
>
> We can do that to start with. If there are no problems in the field
> with it, I don't see any problems in principle.
>
> > If we anyway are going to add cut-off date to enable runtime PM we
> > should expect that the hardware is also capable of doing so (and if not
> > we can always blacklist the exceptions).
>
> Sounds reasonable.
>
> >> The kernel should power stuff down not wait for the user to run powertop,
> >> At least for the GPU it's in the area of 8W of power, and I've got the
> >> GPU drivers doing this themselves,
> >>
> >> I could have the GPU driver call runtime allow for it's host bridge I
> >> suppose,
> >> if we insist on the userspace cares, but I'd prefer not doing so.
> >>
> >> > I think we need to add corresponding call to pm_runtime_forbid() in
> >> > pcie_portdrv_remove().
> >>
> >> Yes most likely.
> >
> > BTW, I can add both calls to the next version of PCIe runtime PM patches
> > if you are OK with that, and all agree this is a good idea.
>
> That would be fine by me.
OK thanks.
I'll do these changes to the next version of the patch series then.
[RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use
On Mon, Mar 14 2016, Oded Gabbay wrote: > On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes > wrote: >> Passing overlapping source and destination buffers to snprintf >> formally has undefined behaviour and is rather fragile. While the > > I saw there were some different opinions on this. > Have the fixes to the other drivers been taken ? > I rewrote this (as well as the joystick/analog.c and wlcore/boot.c patches) to use seq_buf, and this patch in particular became much simpler. But since akpm and Alan don't think there's anything to fix I'm going to drop the series; if anyone wants to pursue this I'll be happy to send them my v2. Rasmus
