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(>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(>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(>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(>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 <regressi...@leemhuis.info>: >Lo! On 22.03.2017 11:36, Jani Nikula wrote: >> On Wed, 22 Mar 2017, Martin Kepplinger <mart...@posteo.de> 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=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:
[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(_priv->av_mutex);
>>>>> intel_dig_port->audio_connector = connector;
>>>>> + /* referred in audio callbacks */
>>>>> + dev_priv->dig_port_map[port] = intel_encoder;
>>>>> mutex_unlock(_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(_priv->av_mutex);
>>>>> intel_dig_port->audio_connector = NULL;
>>>>> + dev_priv->dig_port_map[port] = NULL;
>>>>> mutex_unlock(_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.
[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(_priv->av_mutex);
>> intel_dig_port->audio_connector = connector;
>> +/* referred in audio callbacks */
>> +dev_priv->dig_port_map[port] = intel_encoder;
>> mutex_unlock(_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(_priv->av_mutex);
>> intel_dig_port->audio_connector = NULL;
>> +dev_priv->dig_port_map[port] = NULL;
>> mutex_unlock(_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 *intel_dig_port,
>> void 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(>lru_lock);
- ret = __ttm_bo_reserve(bo, false, true, false, 0);
+ ret = __ttm_bo_reserve(bo, false, true, false, NULL);
spin_lock(>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(>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(>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(>lru_lock);
ret = __ttm_bo_reserve(entry, false, false,
- false, 0);
+ false, NULL);
spin_lock(>lru_lock);
}
@@ -726,7 +726,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(>lru_lock);
list_for_each_entry(bo, >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(>fence_lock);
@@ -1630,7 +1630,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
spin_lock(>lru_lock);
list_for_each_entry(bo, >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
