[PATCH] backlight: pwm_bl: print errno for probe errors
This makes debugging often easier. Signed-off-by: Martin Kepplinger-Novaković --- drivers/video/backlight/pwm_bl.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index f1005bd0c41e3..cc7e7af71891f 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -502,7 +502,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) GPIOD_ASIS); if (IS_ERR(pb->enable_gpio)) { ret = dev_err_probe(&pdev->dev, PTR_ERR(pb->enable_gpio), - "failed to acquire enable GPIO\n"); + "failed to acquire enable GPIO: %ld\n", + PTR_ERR(pb->enable_gpio)); goto err_alloc; } @@ -513,7 +514,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->power_supply = NULL; } else { dev_err_probe(&pdev->dev, ret, - "failed to acquire power regulator\n"); + "failed to acquire power regulator: %d\n", + ret); goto err_alloc; } } @@ -521,7 +523,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->pwm = devm_pwm_get(&pdev->dev, NULL); if (IS_ERR(pb->pwm)) { ret = dev_err_probe(&pdev->dev, PTR_ERR(pb->pwm), - "unable to request PWM\n"); + "unable to request PWM: %ld\n", + PTR_ERR(pb->pwm)); goto err_alloc; } -- 2.39.2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v1] drm/mipi-dsi: Set the fwnode for mipi_dsi_device
Am Donnerstag, dem 09.03.2023 um 22:39 -0800 schrieb Saravana Kannan: > After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle > detection more robust"), fw_devlink prints an error when consumer > devices don't have their fwnode set. This used to be ignored > silently. > > Set the fwnode mipi_dsi_device so fw_devlink can find them and > properly > track their dependencies. > > This fixes errors like this: > [ 0.334054] nwl-dsi 30a0.mipi-dsi: Failed to create device > link with regulator-lcd-1v8 > [ 0.346964] nwl-dsi 30a0.mipi-dsi: Failed to create device > link with backlight-dsi > > Reported-by: Martin Kepplinger Reported-and-tested-by: Martin Kepplinger thanks, martin > Link: > https://lore.kernel.org/lkml/2a8e407f4f18c9350f8629a2b5fa18673355b2ae.ca...@puri.sm/ > Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") > Signed-off-by: Saravana Kannan > --- > drivers/gpu/drm/drm_mipi_dsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c > b/drivers/gpu/drm/drm_mipi_dsi.c > index b41aaf2bb9f1..7923cc21b78e 100644 > --- a/drivers/gpu/drm/drm_mipi_dsi.c > +++ b/drivers/gpu/drm/drm_mipi_dsi.c > @@ -221,7 +221,7 @@ mipi_dsi_device_register_full(struct > mipi_dsi_host *host, > return dsi; > } > > - dsi->dev.of_node = info->node; > + device_set_node(&dsi->dev, of_fwnode_handle(info->node)); > dsi->channel = info->channel; > strlcpy(dsi->name, info->type, sizeof(dsi->name)); >
[PATCH] dt-bindings: mxsfb: Add interconnect bindings for LCDIF path
Add optional interconnect properties for the dram path requests. Signed-off-by: Martin Kepplinger --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index a4c3064c778c..44d744800a7c 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -50,6 +50,14 @@ properties: interrupts: maxItems: 1 + interconnects: +items: + - description: Interconnect path between LCDIF and main memory + + interconnect-names: +items: + - const: dram + port: $ref: /schemas/graph.yaml#/properties/port description: The LCDIF output port -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] dt-bindings: display: mxsfb: Convert binding to YAML
Am 15. Jänner 2021 23:25:14 MEZ schrieb Laurent Pinchart : >Hi Martin, > >On Fri, Jan 15, 2021 at 08:59:18AM +0100, Martin Kepplinger wrote: >> hi Laurent, >> >> Do you mind me adding a DT property in the old format now? If so, I'd >> appreciated an ack in this thread: >> >https://lore.kernel.org/linux-arm-kernel/20201201134638.ga305...@bogon.m.sigxcpu.org/ >> >> If it causes extra work for you and want to resend your series soon, >I'll >> gladly delay them for later. > >I think the conversion ot YAML is ready. I've split it from the rest of >my series, and posted a v3, asking Rob to merge it. Would you mind >rebasing the addition of the new properties on top ? Hi Laurent, thanks for the timely answer. sounds good; I'll rebase. martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] dt-bindings: display: mxsfb: Convert binding to YAML
hi Laurent, Do you mind me adding a DT property in the old format now? If so, I'd appreciated an ack in this thread: https://lore.kernel.org/linux-arm-kernel/20201201134638.ga305...@bogon.m.sigxcpu.org/ If it causes extra work for you and want to resend your series soon, I'll gladly delay them for later. thanks, martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: Add interconnect path request
Add interconnect support to mxsfb so that it is able to request enough bandwidth to DDR for display output to work. Signed-off-by: Martin Kepplinger --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 33 +++ drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++ drivers/gpu/drm/mxsfb/mxsfb_kms.c | 13 3 files changed, 48 insertions(+) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 6faf17b6408d..b05e8e5f1e38 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -311,6 +312,34 @@ static const struct of_device_id mxsfb_dt_ids[] = { }; MODULE_DEVICE_TABLE(of, mxsfb_dt_ids); + +static int mxsfb_init_icc(struct platform_device *pdev) +{ + struct drm_device *drm = platform_get_drvdata(pdev); + struct mxsfb_drm_private *mxsfb = drm->dev_private; + int ret; + + /* Optional interconnect request */ + mxsfb->icc_path = devm_of_icc_get(&pdev->dev, "lcdif-dram"); + if (IS_ERR(mxsfb->icc_path)) { + ret = PTR_ERR(mxsfb->icc_path); + if (ret == -EPROBE_DEFER) + return ret; + + mxsfb->icc_path = NULL; + dev_dbg(drm->dev, + "No interconnect may cause display underflows!\n"); + } + + ret = icc_set_bw(mxsfb->icc_path, 0, MBps_to_icc(700)); + if (ret) { + dev_err(drm->dev, "%s: icc_set_bw failed: %d\n", __func__, ret); + return ret; + } + + return 0; +} + static int mxsfb_probe(struct platform_device *pdev) { struct drm_device *drm; @@ -329,6 +358,10 @@ static int mxsfb_probe(struct platform_device *pdev) if (ret) goto err_free; + ret = mxsfb_init_icc(pdev); + if (ret) + goto err_free; + ret = drm_dev_register(drm, 0); if (ret) goto err_unload; diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h index 399d23e91ed1..d74ff4818e62 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h @@ -41,6 +41,8 @@ struct mxsfb_drm_private { struct drm_encoder encoder; struct drm_connector*connector; struct drm_bridge *bridge; + + struct icc_path *icc_path; }; static inline struct mxsfb_drm_private * diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 3e1bb0aefb87..8925ee7deeaa 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include @@ -310,6 +311,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); struct drm_device *drm = mxsfb->drm; dma_addr_t paddr; + int ret; + + ret = icc_enable(mxsfb->icc_path); + if (ret) + dev_err_ratelimited(drm->dev, "%s: icc_enable failed: %d\n", + __func__, ret); pm_runtime_get_sync(drm->dev); mxsfb_enable_axi_clk(mxsfb); @@ -334,6 +341,7 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc, struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); struct drm_device *drm = mxsfb->drm; struct drm_pending_vblank_event *event; + int ret; mxsfb_disable_controller(mxsfb); @@ -349,6 +357,11 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc *crtc, mxsfb_disable_axi_clk(mxsfb); pm_runtime_put_sync(drm->dev); + + ret = icc_disable(mxsfb->icc_path); + if (ret) + dev_err_ratelimited(drm->dev, "%s: icc_disable failed: %d\n", + __func__, ret); } static int mxsfb_crtc_enable_vblank(struct drm_crtc *crtc) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] drm/bridge: Add NWL MIPI DSI host controller support
On 02.12.19 20:35, Guido Günther wrote: > This adds initial support for the NWL MIPI DSI Host controller found on > i.MX8 SoCs. > > It adds support for the i.MX8MQ but the same IP can be found on > e.g. the i.MX8QXP. > > It has been tested on the Librem 5 devkit using mxsfb. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Tested-by: Robert Chiras > --- Running on the librem5-devkit with some of these msxfb fixes on top: https://lore.kernel.org/linux-arm-kernel/1567078215-31601-1-git-send-email-robert.chi...@nxp.com/ the tree I'm running, starting with this patch: https://source.puri.sm/martin.kepplinger/linux-next/commits/next-20191210/librem5_nwl_mipi_dsi_testing so: Tested-by: Martin Kepplinger thanks, martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: mxsfb: implement FB_PRE_INIT_FB option
From: Melchior Franz The FB_PRE_INIT_FB option keeps the kernel from reinitializing the display and prevents flickering during the transition from a bootloader splash screen to the kernel logo screen. Make this option available for the mxsfb driver. Signed-off-by: Melchior Franz Signed-off-by: Martin Kepplinger Signed-off-by: Manfred Schlaegl --- drivers/video/fbdev/Kconfig | 2 +- drivers/video/fbdev/mxsfb.c | 12 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 58a9590c9db6..0e7ab29c9c70 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2183,7 +2183,7 @@ config FB_EP93XX config FB_PRE_INIT_FB bool "Don't reinitialize, use bootloader's GDC/Display configuration" - depends on FB && FB_MB862XX_LIME + depends on FB && (FB_MB862XX_LIME || FB_MXS) ---help--- Select this option if display contents should be inherited as set by the bootloader. diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c index 12c8bd1d24d5..a017200a16b3 100644 --- a/drivers/video/fbdev/mxsfb.c +++ b/drivers/video/fbdev/mxsfb.c @@ -181,6 +181,7 @@ struct mxsfb_info { const struct mxsfb_devdata *devdata; u32 sync; struct regulator *reg_lcd; + int pre_init; }; #define mxsfb_is_v3(host) (host->devdata->ipversion == 3) @@ -419,6 +420,12 @@ static int mxsfb_set_par(struct fb_info *fb_info) fb_info->fix.line_length = line_size; + if (host->pre_init) { + mxsfb_enable_controller(fb_info); + host->pre_init = 0; + return 0; + } + /* * It seems, you can't re-program the controller if it is still running. * This may lead into shifted pictures (FIFO issue?). @@ -931,6 +938,10 @@ static int mxsfb_probe(struct platform_device *pdev) if (IS_ERR(host->reg_lcd)) host->reg_lcd = NULL; +#if defined(CONFIG_FB_PRE_INIT_FB) + host->pre_init = 1; +#endif + fb_info->pseudo_palette = devm_kcalloc(&pdev->dev, 16, sizeof(u32), GFP_KERNEL); if (!fb_info->pseudo_palette) { @@ -963,6 +974,7 @@ static int mxsfb_probe(struct platform_device *pdev) mxsfb_enable_controller(fb_info); } + host->pre_init = 0; dev_info(&pdev->dev, "initialized\n"); return 0; -- 2.20.1 smime.p7s Description: S/MIME cryptographic signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: fbmem: fix memory access if logo is bigger than the screen
From: Manfred Schlaegl There is no clipping on the x or y axis for logos larger that the framebuffer size. Therefore: a logo bigger than screen size leads to invalid memory access: [1.254664] Backtrace: [1.254728] [] (cfb_imageblit) from [] (fb_show_logo+0x620/0x684) [1.254763] r10:0003 r9:00027fd8 r8:c6a4 r7:c6a36e50 r6: r5:c06b81e4 [1.254774] r4:c6a3e800 [1.254810] [] (fb_show_logo) from [] (fbcon_switch+0x3fc/0x46c) [1.254842] r10:c6a3e824 r9:c6a3e800 r8: r7:c6a0c000 r6:c070b014 r5:c6a3e800 [1.254852] r4:c6808c00 [1.254889] [] (fbcon_switch) from [] (redraw_screen+0xf0/0x1e8) [1.254918] r10: r9: r8: r7: r6:c070d5a0 r5:0080 [1.254928] r4:c6808c00 [1.254961] [] (redraw_screen) from [] (do_bind_con_driver+0x194/0x2e4) [1.254991] r9: r8: r7:0014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0 So prevent displaying a logo bigger than screen size and avoid invalid memory access. Signed-off-by: Manfred Schlaegl Signed-off-by: Martin Kepplinger --- drivers/video/fbdev/core/fbmem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index cb43a2258c51..4721491e6c8c 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -431,6 +431,9 @@ static void fb_do_show_logo(struct fb_info *info, struct fb_image *image, { unsigned int x; + if (image->width > info->var.xres || image->height > info->var.yres) + return; + if (rotate == FB_ROTATE_UR) { for (x = 0; x < num && image->dx + image->width <= info->var.xres; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load
Am 07.04.2017 01:23 schrieb Andrea Arcangeli: I'm also getting kernel hangs every couple of days. For me it's still not fixed here in 4.11-rc5. It's hard to reproduce, the best reproducer is to build lineageos 14.1 on host while running LTP in a guest to stress the guest VM. Initially I thought it was related to the fact I upgraded the xf86 intel driver just a few weeks ago (I deferred any upgrade of the userland intel driver since last July because of a regression that never got fixed and broke xterm for me). After I found a workaround for the userland regression (appended at the end for reference) I started getting kernel hangs but they are separate issues as far as I can tell. It's not well tested so beware... (it survived a couple of builds and some VM reclaim but that's it). The first patch 1/5 is the potential fix for the i915 kernel hang. The rest are incremental improvements. And I've no great solution for when the shrinker was invoked with the struct_mutex held and and recurse on the lock. I don't think we can possibly wait in such case (other than flush work that the second patch does) but then practically it shouldn't be a big deal, the big RAM eater is unlikely to be i915 when the system is low on memory. FWIW without having insight here, -rc6 seems to be good. No disturbing gpu hangs under load so far. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load
Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis : >Lo! On 22.03.2017 11:36, Jani Nikula wrote: >> On Wed, 22 Mar 2017, Martin Kepplinger wrote: >>> I know something similar is here: >>> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too. >>> But this is rc3 and my machine is totally *not usable*. Let me be >>> annoying :) I hope I can help: >> Please file a bug over at [1]. >> […] >> [1] >https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel > >@Martin: did you file that bug? I could not find one :-/ I did. Got marked as duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=100181 and there's a fix out there. I don't know if it's in rc5 though. > >@Jani: In similar situations could you do me a favour and ask people to >send one more reply to the public list which contains the link to the >bug filed? Regression tracking is quite hard already; searching various >bug tracker for follow up bug entries makes it even harder :-( > >Ciao, Thorsten -- Martin Kepplinger http://martinkepplinger.com sent from mobile ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG][REGRESSION] i915 gpu hangs under load
Hi I know something similar is here: https://bugs.freedesktop.org/show_bug.cgi?id=100110 too. But this is rc3 and my machine is totally *not usable*. Let me be annoying :) I hope I can help: Since rc1 I get gpu hangs and resets under load: This is almost certainly a kernel issue. 4.10 is fine. I keep a debian stable userspace. nouveau is running on this machine too. Mar 22 09:17:01 martin-laptop kernel: [ 2409.538706] [drm] GPU HANG: ecode 7:0:0xf3ce, in gnome-shell [1869], reason: Hang on render ring, action: reset Mar 22 09:17:01 martin-laptop kernel: [ 2409.538711] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Mar 22 09:17:01 martin-laptop kernel: [ 2409.538713] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Mar 22 09:17:01 martin-laptop kernel: [ 2409.538714] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Mar 22 09:17:01 martin-laptop kernel: [ 2409.538715] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Mar 22 09:17:01 martin-laptop kernel: [ 2409.538716] [drm] GPU crash dump saved to /sys/class/drm/card0/error Mar 22 09:17:01 martin-laptop kernel: [ 2409.538768] drm/i915: Resetting chip after gpu hang Mar 22 09:17:09 martin-laptop kernel: [ 2417.537886] drm/i915: Resetting chip after gpu hang Mar 22 09:17:17 martin-laptop kernel: [ 2425.537152] drm/i915: Resetting chip after gpu hang Mar 22 09:17:25 martin-laptop kernel: [ 2433.536407] drm/i915: Resetting chip after gpu hang Mar 22 09:17:33 martin-laptop kernel: [ 2441.539674] drm/i915: Resetting chip after gpu hang Furthermore, there are weird, small display distortions occuring. I don't get any log about them and don't have a screenshot. Well. Nevermind. Please fix 4.11 and CC anyone I forgot. thanks martin GPU HANG: ecode 7:0:0xf3ce, in gnome-shell [1869], reason: Hang on render ring, action: reset Kernel: 4.11.0-rc3-3-gbc61cd2 Time: 1490170621 s 524489 us Boottime: 2409 s 756155 us Uptime: 2395 s 323536 us is_mobile: no is_lp: no is_alpha_support: no has_64bit_reloc: no has_aliasing_ppgtt: yes has_csr: no has_ddi: yes has_decoupled_mmio: no has_dp_mst: yes has_fbc: yes has_fpga_dbg: yes has_full_ppgtt: yes has_full_48bit_ppgtt: no has_gmbus_irq: yes has_gmch_display: no has_guc: no has_hotplug: yes has_hw_contexts: yes has_l3_dpf: yes has_llc: yes has_logical_ring_contexts: no has_overlay: no has_pipe_cxsr: no has_pooled_eu: no has_psr: yes has_rc6: yes has_rc6p: no has_resource_streamer: yes has_runtime_pm: yes has_snoop: no cursor_needs_physical: no hws_needs_physical: no overlay_needs_physical: no supports_tv: no Active process (on ring render): gnome-shell [1869], context bans 0 Reset count: 0 Suspend count: 0 Platform: HASWELL PCI ID: 0x0416 PCI Revision: 0x06 PCI Subsystem: 10cf:17ac IOMMU enabled?: 0 EIR: 0x IER: 0xfc002529 GTIER: 0x00401821 PGTBL_ER: 0x FORCEWAKE: 0x0001 DERRMR: 0x CCID: 0x00ef410d Missed interrupts: 0x fence[0] = fence[1] = fence[2] = fence[3] = fence[4] = fence[5] = fence[6] = fence[7] = fence[8] = fence[9] = fence[10] = fence[11] = fence[12] = fence[13] = fence[14] = fence[15] = fence[16] = fence[17] = fence[18] = 4b530770374a001 fence[19] = fence[20] = fence[21] = fence[22] = fence[23] = fence[24] = fence[25] = fence[26] = fence[27] = fence[28] = fence[29] = fence[30] = fence[31] = ERROR: 0x0109 DONE_REG: 0x ERR_INT: 0x render command stream: START: 0x007ea000 HEAD: 0x07a1f6dc [0x0001f648] TAIL: 0x0001f8f8 [0x0001f728, 0x0001f760] CTL: 0x0001f001 MODE: 0x4000 HWS: 0x7fff ACTHD: 0x 07a1f6dc IPEIR: 0x IPEHR: 0x0c00 INSTDONE: 0xffce SC_INSTDONE: 0x SAMPLER_INSTDONE[0][0]: 0x ROW_INSTDONE[0][0]: 0x BBADDR: 0x_7fa48330 BB_STATE: 0x INSTPS: 0x0500 INSTPM: 0x6080 FADDR: 0x 008096d8 RC PSMI: 0x0010 FAULT_REG: 0x00c5 SYNC_0: 0x SYNC_1: 0x0001c2a1 SYNC_2: 0x GFX_MODE: 0x2a00 PP_DIR_BASE: 0x7fdf seqno: 0x0001c29a last_seqno: 0x0001c2a2 waiting: yes ring->head: 0x00016e60 ring->tail: 0x0001f8f8 hangcheck stall: yes hangcheck action: dead hangcheck action timestamp: 4295493232, 204600 ms ago blt command stream: START: 0x0080a000 HEAD: 0x07e0e8d0 [0x] TAIL: 0xe8d0 [0x, 0x] CTL: 0x0001f001 MODE: 0x0200 HWS: 0x7fff1000 ACTHD: 0x 07e0e8d0 IPEIR: 0x IPEHR: 0
[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
Am 2016-03-03 um 16:05 schrieb Takashi Iwai: > On Mon, 29 Feb 2016 15:39:53 +0100, > Jani Nikula wrote: >> >> On Mon, 29 Feb 2016, Martin Kepplinger wrote: >>> Am 2016-02-26 um 20:59 schrieb Takashi Iwai: >>>> Sorry, Cc to Jani was missing mistakenly. >>>> >>>> Please check this. It's a regression in 4.5-rc. >>>> >>>> >>>> thanks, >>>> >>>> Takashi >>>> >>> >>> I can confirm that with -rc6 nothing changed and this fixes audio over >>> HDMI for me. I added David Airlie and dri-devel to CC aswell and hope >>> that this can go in for 4.5 in the last minute. >> >> I'll pick this up when we get the CI results. (This had fallen between >> the cracks...) > > As far as looking at linux-next, this one still seems remaining in the > crevasse... > This still isn't merged but still fixes a serious regression in v4.5. What's going on? thanks martin > > thanks, > > Takashi > >> >> BR, >> Jani. >> >> >> >>> >>> thanks >>> martin >>> >>> >>>> On Wed, 24 Feb 2016 15:35:22 +0100, >>>> Takashi Iwai wrote: >>>>> >>>>> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between >>>>> port and intel_encoder] introduced a reverse mapping to retrieve >>>>> intel_dig_port object from the port number. The code assumed that the >>>>> port vs intel_dig_port are 1:1 mapping. But in reality, this was a >>>>> too naive assumption. >>>>> >>>>> As Martin reported about the missing HDMI audio on his SNB machine, >>>>> pre-HSW chips may have multiple intel_dig_port objects corresponding >>>>> to the same port. Since we assign the mapping statically at the init >>>>> time and the multiple objects override the map, it may not match with >>>>> the actually enabled output. >>>>> >>>>> This patch tries to address the regression above. The reverse mapping >>>>> is provided basically only for the audio callbacks, so now we set / >>>>> clear the mapping dynamically at enabling and disabling HDMI/DP audio, >>>>> so that we can always track the latest and correct object >>>>> corresponding to the given port. >>>>> >>>>> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and >>>>> intel_encoder') >>>>> Reported-and-tested-by: Martin Kepplinger >>>>> Signed-off-by: Takashi Iwai >>>>> --- >>>>> drivers/gpu/drm/i915/intel_audio.c | 3 +++ >>>>> drivers/gpu/drm/i915/intel_ddi.c | 1 - >>>>> drivers/gpu/drm/i915/intel_dp.c| 1 - >>>>> drivers/gpu/drm/i915/intel_hdmi.c | 2 -- >>>>> 4 files changed, 3 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c >>>>> b/drivers/gpu/drm/i915/intel_audio.c >>>>> index 31f6d212fb1b..30f921421b0c 100644 >>>>> --- a/drivers/gpu/drm/i915/intel_audio.c >>>>> +++ b/drivers/gpu/drm/i915/intel_audio.c >>>>> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder >>>>> *intel_encoder) >>>>> >>>>> mutex_lock(&dev_priv->av_mutex); >>>>> intel_dig_port->audio_connector = connector; >>>>> + /* referred in audio callbacks */ >>>>> + dev_priv->dig_port_map[port] = intel_encoder; >>>>> mutex_unlock(&dev_priv->av_mutex); >>>>> >>>>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) >>>>> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder >>>>> *intel_encoder) >>>>> >>>>> mutex_lock(&dev_priv->av_mutex); >>>>> intel_dig_port->audio_connector = NULL; >>>>> + dev_priv->dig_port_map[port] = NULL; >>>>> mutex_unlock(&dev_priv->av_mutex); >>>>> >>>>> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) >>>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c >>>>> b/drivers/gpu/drm/i915/intel_ddi.c >>>>> index 54a165b9c92d..a50fc452d5f1 10
[Intel-gfx] [PATCH] drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
Am 2016-02-26 um 20:59 schrieb Takashi Iwai: > Sorry, Cc to Jani was missing mistakenly. > > Please check this. It's a regression in 4.5-rc. > > > thanks, > > Takashi > I can confirm that with -rc6 nothing changed and this fixes audio over HDMI for me. I added David Airlie and dri-devel to CC aswell and hope that this can go in for 4.5 in the last minute. thanks martin > On Wed, 24 Feb 2016 15:35:22 +0100, > Takashi Iwai wrote: >> >> The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between >> port and intel_encoder] introduced a reverse mapping to retrieve >> intel_dig_port object from the port number. The code assumed that the >> port vs intel_dig_port are 1:1 mapping. But in reality, this was a >> too naive assumption. >> >> As Martin reported about the missing HDMI audio on his SNB machine, >> pre-HSW chips may have multiple intel_dig_port objects corresponding >> to the same port. Since we assign the mapping statically at the init >> time and the multiple objects override the map, it may not match with >> the actually enabled output. >> >> This patch tries to address the regression above. The reverse mapping >> is provided basically only for the audio callbacks, so now we set / >> clear the mapping dynamically at enabling and disabling HDMI/DP audio, >> so that we can always track the latest and correct object >> corresponding to the given port. >> >> Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and >> intel_encoder') >> Reported-and-tested-by: Martin Kepplinger >> Signed-off-by: Takashi Iwai >> --- >> drivers/gpu/drm/i915/intel_audio.c | 3 +++ >> drivers/gpu/drm/i915/intel_ddi.c | 1 - >> drivers/gpu/drm/i915/intel_dp.c| 1 - >> drivers/gpu/drm/i915/intel_hdmi.c | 2 -- >> 4 files changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> index 31f6d212fb1b..30f921421b0c 100644 >> --- a/drivers/gpu/drm/i915/intel_audio.c >> +++ b/drivers/gpu/drm/i915/intel_audio.c >> @@ -527,6 +527,8 @@ void intel_audio_codec_enable(struct intel_encoder >> *intel_encoder) >> >> mutex_lock(&dev_priv->av_mutex); >> intel_dig_port->audio_connector = connector; >> +/* referred in audio callbacks */ >> +dev_priv->dig_port_map[port] = intel_encoder; >> mutex_unlock(&dev_priv->av_mutex); >> >> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) >> @@ -554,6 +556,7 @@ void intel_audio_codec_disable(struct intel_encoder >> *intel_encoder) >> >> mutex_lock(&dev_priv->av_mutex); >> intel_dig_port->audio_connector = NULL; >> +dev_priv->dig_port_map[port] = NULL; >> mutex_unlock(&dev_priv->av_mutex); >> >> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c >> b/drivers/gpu/drm/i915/intel_ddi.c >> index 54a165b9c92d..a50fc452d5f1 100644 >> --- a/drivers/gpu/drm/i915/intel_ddi.c >> +++ b/drivers/gpu/drm/i915/intel_ddi.c >> @@ -3312,7 +3312,6 @@ void intel_ddi_init(struct drm_device *dev, enum port >> port) >> intel_encoder->get_config = intel_ddi_get_config; >> >> intel_dig_port->port = port; >> -dev_priv->dig_port_map[port] = intel_encoder; >> intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) & >>(DDI_BUF_PORT_REVERSAL | >> DDI_A_4_LANES); >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index 1bbd67b046da..acf918728492 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -6035,7 +6035,6 @@ intel_dp_init(struct drm_device *dev, >> } >> >> intel_dig_port->port = port; >> -dev_priv->dig_port_map[port] = intel_encoder; >> intel_dig_port->dp.output_reg = output_reg; >> >> intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT; >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c >> b/drivers/gpu/drm/i915/intel_hdmi.c >> index 4a77639a489d..23ee48dc765f 100644 >> --- a/drivers/gpu/drm/i915/intel_hdmi.c >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c >> @@ -2146,7 +2146,6 @@ void intel_hdmi_init_connector(struct >> intel_digital_port *inte
[BUG] i915: suspend by closing Laptop lid broken
Am 2015-05-04 um 13:24 schrieb Jani Nikula: > On Mon, 04 May 2015, Martin Kepplinger wrote: >> So. -rc1 broke suspending by closing my laptop lid and it's not fixed in >> -rc2. It works exactly *one* first time and every subsequent lid-closing >> is ignored. >> >> Biscted and tested first bad commit: >> 14aa02449064541217836b9f3d3295e241d5ae9c >> >> This pulls in i915 changes as well as ACPI changes. I don't know the >> driver but I'm sure you can find the mistake. I'm happy to test changes. >> >> There are no log differences. > > Any chance you could bisect into the merge? It would be helpful. > > BR, > Jani. > > My attempt to go into the merge was too much effort as the checkouts in between break random other stuff. We should be between 09d51602cf84a1264946711dd4ea0dddbac599a1 (good) and c0f404284192f2d4a0159a714372a8c8610c1f6d. Could you have a look and maybe you have guesses for me, what I should test? It's not sooo much anymore, maybe you even have a guess about the bug? thanks martin
[BUG] i915: suspend by closing Laptop lid broken
So. -rc1 broke suspending by closing my laptop lid and it's not fixed in -rc2. It works exactly *one* first time and every subsequent lid-closing is ignored. Biscted and tested first bad commit: 14aa02449064541217836b9f3d3295e241d5ae9c This pulls in i915 changes as well as ACPI changes. I don't know the driver but I'm sure you can find the mistake. I'm happy to test changes. There are no log differences.
[PATCH] ttm: use NULL instead of 0 for ttm_bo_reserve()'s pointer arg.
Fix a sparse warning: ttm_bo_reserve()'s last argument is a pointer to a struct, so use NULL as nullpointer. Signed-off-by: Martin Kepplinger --- this applies to next-20140613. Please ignore if annoyingly irrelevant. drivers/gpu/drm/ttm/ttm_bo.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 4ab9f71..cd0e15e 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -412,7 +412,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo) int ret; spin_lock(&glob->lru_lock); - ret = __ttm_bo_reserve(bo, false, true, false, 0); + ret = __ttm_bo_reserve(bo, false, true, false, NULL); spin_lock(&bdev->fence_lock); (void) ttm_bo_wait(bo, false, false, true); @@ -514,7 +514,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo, return ret; spin_lock(&glob->lru_lock); - ret = __ttm_bo_reserve(bo, false, true, false, 0); + ret = __ttm_bo_reserve(bo, false, true, false, NULL); /* * We raced, and lost, someone else holds the reservation now, @@ -577,11 +577,11 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all) kref_get(&nentry->list_kref); } - ret = __ttm_bo_reserve(entry, false, true, false, 0); + ret = __ttm_bo_reserve(entry, false, true, false, NULL); if (remove_all && ret) { spin_unlock(&glob->lru_lock); ret = __ttm_bo_reserve(entry, false, false, - false, 0); + false, NULL); spin_lock(&glob->lru_lock); } @@ -726,7 +726,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev, spin_lock(&glob->lru_lock); list_for_each_entry(bo, &man->lru, lru) { - ret = __ttm_bo_reserve(bo, false, true, false, 0); + ret = __ttm_bo_reserve(bo, false, true, false, NULL); if (!ret) break; } @@ -1595,7 +1595,7 @@ int ttm_bo_synccpu_write_grab(struct ttm_buffer_object *bo, bool no_wait) * Using ttm_bo_reserve makes sure the lru lists are updated. */ - ret = ttm_bo_reserve(bo, true, no_wait, false, 0); + ret = ttm_bo_reserve(bo, true, no_wait, false, NULL); if (unlikely(ret != 0)) return ret; spin_lock(&bdev->fence_lock); @@ -1630,7 +1630,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink) spin_lock(&glob->lru_lock); list_for_each_entry(bo, &glob->swap_lru, swap) { - ret = __ttm_bo_reserve(bo, false, true, false, 0); + ret = __ttm_bo_reserve(bo, false, true, false, NULL); if (!ret) break; } -- 1.7.10.4