Re: [PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic
Sent from Yahoo Mail on Android ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
Am 27.08.2018 um 10:43 schrieb Jani Nikula:
> On Sat, 25 Aug 2018, Lyude Paul wrote:
>> From: Jan-Marek Glogowski
>>
>> This re-applies the workaround for "some DP sinks, [which] are a
>> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
>> quality check unconditionally during long pulse").
>> It makes the secondary AOC E2460P monitor connected via DP to an
>> acer Veriton N4640G usable again.
>>
>> This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
>> DP link retraining into the ->post_hotplug() hook")
>>
>> Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
>> ->post_hotplug() hook")
>> [Cleaned up commit message, added stable cc]
>> Signed-off-by: Lyude Paul
>> Signed-off-by: Jan-Marek Glogowski
>> Cc: sta...@vger.kernel.org
>> ---
>> Resending this to update patchwork; will push in a little bit
>
> Is there a bugzilla? Reference to a list discussion? Something with a
> dmesg where someone can actually verify this is the right fix?
The bug is at https://bugs.freedesktop.org/show_bug.cgi?id=107446
The original thread starts here:
https://lists.freedesktop.org/archives/intel-gfx/2018-August/172940.html
Jan-Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 4/8] backlight: qcom-wled: Rename PM8941* to WLED3
On Mon 27 Aug 03:04 PDT 2018, Pavel Machek wrote:
> On Fri 2018-08-24 15:57:43, Kiran Gunda wrote:
> > Rename the PM8941* references as WLED3 to make the driver
> > generic and have WLED support for other PMICs. Also rename
> > "i_boost_limit" and "i_limit" variables to "boost_i_limit"
> > and "string_i_limit" respectively to resemble the corresponding
> > register names.
>
> Acked-by: Pavel Machek
>
> > -MODULE_DESCRIPTION("pm8941 wled driver");
> > +MODULE_DESCRIPTION("Qualcomm WLED driver");
>
> "... supporting pm8941, xxx devices" ?
>
I would suggest not doing this. There's quite a long list of different
PMICs containing some version of this hardware block.
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drivers/video/fbdev: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)
_PAGE_WRITETHRU is a target specific flag. Prefer generic functions.
Signed-off-by: Christophe Leroy
---
v2: removed unnecessary includes headers
drivers/video/fbdev/controlfb.c | 5 +
drivers/video/fbdev/platinumfb.c | 5 +
drivers/video/fbdev/valkyriefb.c | 12 ++--
3 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 8d14b29aafea..9cb0ef7ac29e 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -48,9 +48,7 @@
#include
#include
#include
-#include
#include
-#include
#include
#include "macmodes.h"
@@ -715,8 +713,7 @@ static int __init control_of_init(struct device_node *dp)
goto error_out;
}
/* map at most 8MB for the frame buffer */
- p->frame_buffer = __ioremap(p->frame_buffer_phys, 0x80,
- _PAGE_WRITETHRU);
+ p->frame_buffer = ioremap_wt(p->frame_buffer_phys, 0x80);
if (!p->control_regs_phys ||
!request_mem_region(p->control_regs_phys, p->control_regs_size,
diff --git a/drivers/video/fbdev/platinumfb.c b/drivers/video/fbdev/platinumfb.c
index 377d3399a3ad..bf6b7fb83cf4 100644
--- a/drivers/video/fbdev/platinumfb.c
+++ b/drivers/video/fbdev/platinumfb.c
@@ -32,9 +32,7 @@
#include
#include
#include
-#include
#include
-#include
#include "macmodes.h"
#include "platinumfb.h"
@@ -577,8 +575,7 @@ static int platinumfb_probe(struct platform_device* odev)
/* frame buffer - map only 4MB */
pinfo->frame_buffer_phys = pinfo->rsrc_fb.start;
- pinfo->frame_buffer = __ioremap(pinfo->rsrc_fb.start, 0x40,
- _PAGE_WRITETHRU);
+ pinfo->frame_buffer = ioremap_wt(pinfo->rsrc_fb.start, 0x40);
pinfo->base_frame_buffer = pinfo->frame_buffer;
/* registers */
diff --git a/drivers/video/fbdev/valkyriefb.c b/drivers/video/fbdev/valkyriefb.c
index 275fb98236d3..d51c3a8009cb 100644
--- a/drivers/video/fbdev/valkyriefb.c
+++ b/drivers/video/fbdev/valkyriefb.c
@@ -54,13 +54,11 @@
#include
#include
#include
-#include
#ifdef CONFIG_MAC
#include
#else
#include
#endif
-#include
#include "macmodes.h"
#include "valkyriefb.h"
@@ -318,7 +316,7 @@ static void __init valkyrie_choose_mode(struct
fb_info_valkyrie *p)
int __init valkyriefb_init(void)
{
struct fb_info_valkyrie *p;
- unsigned long frame_buffer_phys, cmap_regs_phys, flags;
+ unsigned long frame_buffer_phys, cmap_regs_phys;
int err;
char *option = NULL;
@@ -337,7 +335,6 @@ int __init valkyriefb_init(void)
/* Hardcoded addresses... welcome to 68k Macintosh country :-) */
frame_buffer_phys = 0xf900;
cmap_regs_phys = 0x50f24000;
- flags = IOMAP_NOCACHE_SER; /* IOMAP_WRITETHROUGH?? */
#else /* ppc (!CONFIG_MAC) */
{
struct device_node *dp;
@@ -354,7 +351,6 @@ int __init valkyriefb_init(void)
frame_buffer_phys = r.start;
cmap_regs_phys = r.start + 0x304000;
- flags = _PAGE_WRITETHRU;
}
#endif /* ppc (!CONFIG_MAC) */
@@ -369,7 +365,11 @@ int __init valkyriefb_init(void)
}
p->total_vram = 0x10;
p->frame_buffer_phys = frame_buffer_phys;
- p->frame_buffer = __ioremap(frame_buffer_phys, p->total_vram, flags);
+#ifdef CONFIG_MAC
+ p->frame_buffer = ioremap_nocache(frame_buffer_phys, p->total_vram);
+#else
+ p->frame_buffer = ioremap_wt(frame_buffer_phys, p->total_vram);
+#endif
p->cmap_regs_phys = cmap_regs_phys;
p->cmap_regs = ioremap(p->cmap_regs_phys, 0x1000);
p->valkyrie_regs_phys = cmap_regs_phys+0x6000;
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
Adding lcdif nodes to a power domain currently doesn't work, it results in black/corrupted screens or hangs. While the driver does enable runtime pm it does not deal correctly with the block being unpowered. All patches in this series have review tags from a few weeks ago. I'm resending this today because 4.19 rc1 was released. I'm not sure if this matters for DRM but in some areas unrelated series get lost during the merge window. Marek/Phillip: Is one of you going to pick up these patches? Link to v4: https://lkml.org/lkml/2018/8/8/573 Leonard Crestez (5): drm/mxsfb: Move axi clk enable/disable to crtc enable/disable drm/mxsfb: Fix initial corrupt frame when activating display drm/mxsfb: Add pm_runtime calls to pipe_enable/disable drm/mxsfb: Add PM_SLEEP support drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ 2 files changed, 74 insertions(+), 19 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.19-rc1 on droid 4: screen not updating
* Pavel Machek [180827 10:55]: > Hi! > > With Sebastian's patches, display works on Droid 4 in v4.18. Hmm care to post your v4.18 patches somewhere too for people? I'd have to look around for them since I've been using Linux next for past few months. Also, do you have v4.19-rc1 versions of your pending audio patches somewhere? I'd like to play with voice calls again now with my WIP pending n_gsm serdev patches.. > I had to do some manual merging, and I see kernel messages in > v4.19-rc1, but they are frozen -- no updates. > > a) does someone have it working? I have had it working for few weeks since I'm following Linux next. I just pushed Sebastian's patches I rebased earlier today against v4.19-rc1 to [0][1]. > b) is there some way I can help to get it working in mainline? Droid 4 > is not exactly new, and this is painful point that makes it hard to > use. Well since Sebastian is busy according to [2], maybe try to update Sebastian's mfd-ti-lmu backlight patches so they can get merged? Please check with Sebastian, but that would cut down the pending pile by quite a few patches. Regards, Tony [0] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap droid4-pending-v4.19 [1] https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19 [2] https://lists.freedesktop.org/archives/dri-devel/2018-August/186226.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support
On 2018-08-27 22:40, Boris Brezillon wrote: > On Mon, 27 Aug 2018 22:35:05 +0200 > Boris Brezillon wrote: > >> On Mon, 27 Aug 2018 22:31:22 +0200 >> Peter Rosin wrote: >> >>> On 2018-08-27 21:24, Boris Brezillon wrote: On Sat, 25 Aug 2018 10:56:16 +0200 Peter Rosin wrote: > Hi! > > The background for these patches is that our PCB interface between > the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and > this has to be described somewhere, or the atmel-hlcdc driver have no > chance of selecting the correct output mode. Since we have similar > problems with a tda19988 HDMI encoder I added patches to override > the atmel-hlcdc output format via DT properties compatible with the > media video-interface binding and things start to play together. Queued to drm-misc-next. >>> >>> Thanks! >>> >>> Minute issue, you seem to have some spell-check going on or something, >>> because the subject of patch 1/4 has been "corrected" from >>> "...add ti,ds90c185" to "...add ti, ds90c185" >>> >>> You might want to evaluate if that auto-correction "feature" should be >>> disabled/tweaked/whatever... >> >> Hm, weird. I just downloaded the mbox from dri-devel's patchwork and >> passed it to dim apply. dim tends to do a lot of things behind the >> scene, so maybe it's also trying to fix typos :-). > > Nope, looks like it was already wrong on patchwork [1], don't know what > happened, because the version I have in my mailbox is correct. > > [1]https://patchwork.freedesktop.org/patch/246039/ Apparently a known issue: https://github.com/getpatchwork/patchwork/issues/197 Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 2/5] drm/mxsfb: Fix initial corrupt frame when activating display
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez
Tested-by: Philipp Zabel
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 45 +-
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e4fcbb65b969..24b1f0c1432e 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -191,10 +191,25 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
return ret;
return clear_poll_bit(reset_addr, MODULE_CLKGATE);
}
+static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
+ struct drm_gem_cma_object *gem;
+
+ if (!fb)
+ return 0;
+
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ if (!gem)
+ return 0;
+
+ return gem->paddr;
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
@@ -267,12 +282,22 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
mxsfb->base + LCDC_VDCTRL4);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ dma_addr_t paddr;
+
mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
+
+ /* Write cur_buf as well to avoid an initial corrupt frame */
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ }
+
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
@@ -283,16 +308,12 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
struct drm_crtc *crtc = &pipe->crtc;
- struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_pending_vblank_event *event;
- struct drm_gem_cma_object *gem;
-
- if (!crtc)
- return;
+ dma_addr_t paddr;
spin_lock_irq(&crtc->dev->event_lock);
event = crtc->state->event;
if (event) {
crtc->state->event = NULL;
@@ -303,14 +324,12 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
drm_crtc_send_vblank_event(crtc, event);
}
}
spin_unlock_irq(&crtc->dev->event_lock);
- if (!fb)
- return;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
-
- mxsfb_enable_axi_clk(mxsfb);
- writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ mxsfb_enable_axi_clk(mxsfb);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ mxsfb_disable_axi_clk(mxsfb);
+ }
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 1/5] drm/mxsfb: Move axi clk enable/disable to crtc enable/disable
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for symmetry.
This shouldn't have any functional effect.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 0abe77675b76..e4fcbb65b969 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -127,11 +127,10 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
u32 reg;
if (mxsfb->clk_disp_axi)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
- mxsfb_enable_axi_clk(mxsfb);
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
/* Enable the SYNC signals first, then the DMA engine */
@@ -157,12 +156,10 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
reg = readl(mxsfb->base + LCDC_VDCTRL4);
reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
writel(reg, mxsfb->base + LCDC_VDCTRL4);
- mxsfb_disable_axi_clk(mxsfb);
-
clk_disable_unprepare(mxsfb->clk);
if (mxsfb->clk_disp_axi)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
@@ -206,11 +203,10 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/*
* It seems, you can't re-program the controller if it is still
* running. This may lead to shifted pictures (FIFO issue?), so
* first stop the controller and drain its FIFOs.
*/
- mxsfb_enable_axi_clk(mxsfb);
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb->base);
if (err)
return;
@@ -267,23 +263,23 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
mxsfb->base + LCDC_VDCTRL3);
writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
mxsfb->base + LCDC_VDCTRL4);
-
- mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
mxsfb_disable_controller(mxsfb);
+ mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 5/5] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core ensure atomic_plane_update is only called while
the crtc is active. This avoids having to keep track of "enabled" bits
inside the mxsfb driver.
This also requires handling the vblank event for disable from
mxsfb_pipe_disable.
Signed-off-by: Leonard Crestez
Suggested-by: Stefan Agner
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d797dfd40d98..5777e730085b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -96,10 +96,14 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
+static const struct drm_mode_config_helper_funcs mxsfb_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
@@ -113,15 +117,25 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
struct drm_device *drm = pipe->plane.dev;
+ struct drm_crtc *crtc = &pipe->crtc;
+ struct drm_pending_vblank_event *event;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
pm_runtime_put_sync(drm->dev);
+
+ spin_lock_irq(&drm->event_lock);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+ drm_crtc_send_vblank_event(crtc, event);
+ }
+ spin_unlock_irq(&drm->event_lock);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
@@ -232,10 +246,11 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.min_width = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
drm->mode_config.max_width = MXSFB_MAX_XRES;
drm->mode_config.max_height = MXSFB_MAX_YRES;
drm->mode_config.funcs = &mxsfb_mode_config_funcs;
+ drm->mode_config.helper_private = &mxsfb_mode_config_helpers;
drm_mode_config_reset(drm);
pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drivers/video/fbdev: use ioremap_wc() instead of __ioremap(_PAGE_NO_CACHE)
_PAGE_NO_CACHE is a target specific flag. In addition, this flag is misleading because one would think it requests a noncached page whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED _PAGE_NO_CACHE alone means write combined noncached page, so lets use ioremap_wc() instead. Signed-off-by: Christophe Leroy --- v2: removed unnecessary include and enhanced commit log follow Segher's comment drivers/video/fbdev/chipsfb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c index f103665cad43..40182ed85648 100644 --- a/drivers/video/fbdev/chipsfb.c +++ b/drivers/video/fbdev/chipsfb.c @@ -27,7 +27,6 @@ #include #include #include -#include #ifdef CONFIG_PMAC_BACKLIGHT #include @@ -401,7 +400,7 @@ static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id *ent) #endif /* CONFIG_PMAC_BACKLIGHT */ #ifdef CONFIG_PPC - p->screen_base = __ioremap(addr, 0x20, _PAGE_NO_CACHE); + p->screen_base = ioremap_wc(addr, 0x20); #else p->screen_base = ioremap(addr, 0x20); #endif -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 4/5] drm/mxsfb: Add PM_SLEEP support
Since power to the lcdif block can be lost on suspend implement
PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
the current mode.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 68d79f5dc0d3..d797dfd40d98 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_dev_unref(drm);
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mxsfb_suspend(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_suspend(drm);
+}
+
+static int mxsfb_resume(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_resume(drm);
+}
+#endif
+
+static const struct dev_pm_ops mxsfb_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mxsfb_suspend, mxsfb_resume)
+};
+
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
.name = "mxsfb",
.of_match_table = mxsfb_dt_ids,
+ .pm = &mxsfb_pm_ops,
},
};
module_platform_driver(mxsfb_platform_driver);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm: Fix trivial typo
Fix a typo in the drm_dev init and alloc docs: advertice -> advertise Signed-off-by: Nikolas Nyby --- drivers/gpu/drm/drm_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index ea4941da9b27..282b43c44aab 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -468,7 +468,7 @@ static void drm_fs_inode_free(struct inode *inode) * @parent: Parent device object * * Initialize a new DRM device. No device registration is done. - * Call drm_dev_register() to advertice the device to user space and register it + * Call drm_dev_register() to advertise the device to user space and register it * with other core subsystems. This should be done last in the device * initialization sequence to make sure userspace can't access an inconsistent * state. @@ -622,7 +622,7 @@ EXPORT_SYMBOL(drm_dev_fini); * @parent: Parent device object * * Allocate and initialize a new DRM device. No device registration is done. - * Call drm_dev_register() to advertice the device to user space and register it + * Call drm_dev_register() to advertise the device to user space and register it * with other core subsystems. This should be done last in the device * initialization sequence to make sure userspace can't access an inconsistent * state. -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 8/8] backlight: qcom-wled: Add auto string detection logic
On Fri 24 Aug 03:27 PDT 2018, Kiran Gunda wrote:
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
[..]
> struct wled {
> @@ -135,16 +146,22 @@ struct wled {
> struct regmap *regmap;
> struct mutex lock; /* Lock to avoid race from thread irq handler */
> ktime_t last_short_event;
> + ktime_t start_ovp_fault_time;
> u16 ctrl_addr;
> u16 sink_addr;
> u16 max_string_count;
> + u16 auto_detection_ovp_count;
> u32 brightness;
> u32 max_brightness;
> u32 short_count;
> + u32 auto_detect_count;
> bool disabled_by_short;
> bool has_short_detect;
> + int ovp_irq;
> + bool ovp_irq_disabled;
ovp_irq_disabled is now only assigned, never read. So you should be able
to drop it.
[..]
> @@ -200,7 +226,18 @@ static int wled_module_enable(struct wled *wled, int val)
> WLED_CTRL_REG_MOD_EN,
> WLED_CTRL_REG_MOD_EN_MASK,
> val << WLED_CTRL_REG_MOD_EN_SHIFT);
> - return rc;
> + if (rc < 0)
> + return rc;
> +
> + if (val) {
> + schedule_delayed_work(&wled->ovp_work, HZ / 100);
wled_ovp_work() is a nop when ovp_irq == 0, so wrap the entire if/else
in a check for ovp_irq > 0 (rather than include it in the else) and drop
it from the worker.
> + } else {
> + if (!cancel_delayed_work_sync(&wled->ovp_work) &&
> + wled->ovp_irq > 0)
> + disable_irq(wled->ovp_irq);
> + }
> +
> + return 0;
Also, if a user calls rmmod within 10ms of enabling module we will
schedule work of code that's no longer available in the kernel. So you
need to also cancel_delayed_work_sync() in the remove function of the
driver.
Apart from this I think this patch looks good now!
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)
_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- v2: no change drivers/block/z2ram.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index d0c5bc4e0703..cfbd70520eeb 100644 --- a/drivers/block/z2ram.c +++ b/drivers/block/z2ram.c @@ -190,8 +190,7 @@ static int z2_open(struct block_device *bdev, fmode_t mode) vfree(vmalloc (size)); } - vaddr = (unsigned long) __ioremap (paddr, size, - _PAGE_WRITETHRU); + vaddr = (unsigned long)ioremap_wt(paddr, size); #else vaddr = (unsigned long)z_remap_nocache_nonser(paddr, size); -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support
On 2018-08-27 21:24, Boris Brezillon wrote: > On Sat, 25 Aug 2018 10:56:16 +0200 > Peter Rosin wrote: > >> Hi! >> >> The background for these patches is that our PCB interface between >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and >> this has to be described somewhere, or the atmel-hlcdc driver have no >> chance of selecting the correct output mode. Since we have similar >> problems with a tda19988 HDMI encoder I added patches to override >> the atmel-hlcdc output format via DT properties compatible with the >> media video-interface binding and things start to play together. > > Queued to drm-misc-next. Thanks! Minute issue, you seem to have some spell-check going on or something, because the subject of patch 1/4 has been "corrected" from "...add ti,ds90c185" to "...add ti, ds90c185" You might want to evaluate if that auto-correction "feature" should be disabled/tweaked/whatever... Cheers, Peter > Thanks, > > Boris > >> >> Cheers, >> Peter >> >> Changes since v8 https://lkml.org/lkml/2018/8/10/309 >> - go back to the solution in v7 (but the ep device_node leak fixed) >> for patch 4/4 >> - redo (part of) 3/4 w/o using the disliked of_graph_parse_endpoint >> >> Changes since v7 https://lkml.org/lkml/2018/8/4/288 >> - The ep device_node was leaked in v7 patch 3/3, so add patch 3/4 >> which simplifies fixing this in patch 4/4 (and adds flexibility) >> and adjust patch 4/4 to the changes done in the new 3/4. >> - return -ENOMEM on allocation failure in patch 4/4 >> >> Changes since v6 https://lkml.org/lkml/2018/8/3/333 >> - zap bus-type from the binding in patch 2/3 >> >> Changes since (the shortened) v5 https://lkml.org/lkml/2018/8/3/182 >> - add reg properties (and #*-cells) to the example in patch 2/3 >> - prohibit bus-width 0 in the device-tree in patch 3/3 >> - added reviewed-by from Jacopo to patch 2/3 and 3/3 >> >> Peter Rosin (4): >> dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 >> dt-bindings: display: atmel: optional video-interface of endpoints >> drm/atmel-hlcdc: always iterate over the first 4 output endpoints >> drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes >> >> .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++ >> .../bindings/display/bridge/lvds-transmitter.txt | 8 +- >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +++- >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 + >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 92 >> +++--- >> 5 files changed, 163 insertions(+), 31 deletions(-) >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] powerpc/32: Add ioremap_wt()
Other arches have ioremap_wt() to map IO areas write-through.
Implement it on PPC as well in order to avoid drivers using
__ioremap(_PAGE_WRITETHRU)
Signed-off-by: Christophe Leroy
---
v2: no change
arch/powerpc/include/asm/io.h | 6 ++
arch/powerpc/mm/pgtable_32.c | 8
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index e0331e754568..3380b5b22450 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -3,6 +3,9 @@
#ifdef __KERNEL__
#define ARCH_HAS_IOREMAP_WC
+#ifdef CONFIG_PPC32
+#define ARCH_HAS_IOREMAP_WT
+#endif
/*
* This program is free software; you can redistribute it and/or
@@ -746,6 +749,8 @@ static inline void iosync(void)
*
* * ioremap_wc enables write combining
*
+ * * ioremap_wt enables write through
+ *
* * iounmap undoes such a mapping and can be hooked
*
* * __ioremap_at (and the pending __iounmap_at) are low level functions to
@@ -767,6 +772,7 @@ extern void __iomem *ioremap(phys_addr_t address, unsigned
long size);
extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
unsigned long flags);
extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
+void __iomem *ioremap_wt(phys_addr_t address, unsigned long size);
#define ioremap_nocache(addr, size)ioremap((addr), (size))
#define ioremap_uc(addr, size) ioremap((addr), (size))
#define ioremap_cache(addr, size) \
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 120a49bfb9c6..528999738645 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -90,6 +90,14 @@ ioremap_wc(phys_addr_t addr, unsigned long size)
EXPORT_SYMBOL(ioremap_wc);
void __iomem *
+ioremap_wt(phys_addr_t addr, unsigned long size)
+{
+ return __ioremap_caller(addr, size, _PAGE_WRITETHRU,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(ioremap_wt);
+
+void __iomem *
ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long flags)
{
/* writeable implies dirty for kernel addresses */
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 3/5] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..68d79f5dc0d3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -101,23 +101,27 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
+ pm_runtime_get_sync(drm->dev);
drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
+ pm_runtime_put_sync(drm->dev);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
On 27.08.2018 19:59, Russell King - ARM Linux wrote:
> Hi Andrzej,
>
> On Mon, Aug 27, 2018 at 06:15:59PM +0200, Andrzej Hajda wrote:
>> On 30.07.2018 18:42, Russell King wrote:
>>> static void tda998x_destroy(struct tda998x_priv *priv)
>>> {
>>> + drm_bridge_remove(&priv->bridge);
>>> +
>>> /* disable all IRQs and free the IRQ handler */
>>> cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
>>> reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
>>> @@ -1650,6 +1663,7 @@ static int tda998x_create(struct i2c_client *client,
>>> struct tda998x_priv *priv)
>>> mutex_init(&priv->mutex); /* protect the page access */
>>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */
>>> mutex_init(&priv->edid_mutex);
>>> + INIT_LIST_HEAD(&priv->bridge.list);
>> This line can be probably removed, unless there is a reason I am not
>> aware of.
> The addition above of drm_bridge_remove() to tda998x_destroy() means
> that we end up calling this function in the error cleanup path. This
> avoids unnecessary complexity with lots of different gotos - tda998x
> has had a long history of not cleaning up stuff properly.
1. bridge.list is/should be a private field of drm_bridge framework, so
it's direct usage in driver looks like layer violation.
2. Calling drm_bridge_remove() without drm_bridge_add() is not strictly
forbidden, but at least looks very suspicious. Even if current
implementation tolerates it, it can change in the future.
Neither argument is a blocker IMO so if you prefer to stay with current
solution please add a comment in the code explaining why do you
initializes list field, the code at first sight looks suspicious.
> devm interfaces for bridge do not help avoid that - devm stuff only
> works if everything that is registered previously is cleaned up via
> devm mechanisms to ensure that a device's interface becomes unavailable
> before stuff (eg, edid timers, detect work) is started to be cleaned up.
> Otherwise, there's a chance of this stuff being triggered during
> tear-down.
>
>>> +static int tda998x_bind(struct device *dev, struct device *master, void
>>> *data)
>>> +{
>>> + struct i2c_client *client = to_i2c_client(dev);
>>> + struct drm_device *drm = data;
>>> + struct tda998x_priv *priv;
>>> + int ret;
>>> +
>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + dev_set_drvdata(dev, priv);
>>> +
>>> + ret = tda998x_create(client, priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = tda998x_encoder_init(dev, drm);
>>> + if (ret) {
>>> + tda998x_destroy(priv);
>>> + return ret;
>>> + }
>>> + return 0;
>> It could be replaced by:
>> ret = tda998x_encoder_init(dev, drm);
>> if (ret)
>> tda998x_destroy(priv);
>> return ret;
>>
>> but this is probably matter of taste.
> It's not clear to me what "It" is - I think you're suggesting combining
> tda998x_create() and tda998x_encoder_init() ?
No, just simplifying error path.
>
> The code is structured this way to make the following patches easier -
> there is no point of combining things only to have to then break them
> apart again in a later patch. Please see patch 7, where tda998x_create()
> moves out of this function, where exactly this happens.
OK. As I said: up to you.
>
>> Moreover I guess priv->is_on could be removed if enable/disable
>> callbacks are called only by drm_core, but this is for another patch.
> Is it guaranteed that a bridge ->enable or ->disable callback won't be
> called twice, even for legacy drivers? I think atomic guarantees this
> but I don't think it's guaranteed for legacy drivers.
>
> I'm guessing Rob had a reason why he added the check when he originally
> created the driver (encoder ->dpms can be called for the same dpms
> state multiple times?)
>
OK, my guess was incorrect.
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/rockchip: fix coding style and incorrect description
Align with other drivers, tab + 2 space key for description. and edp/hdmi/dsi can be used on both rk3288 and rk3399. Signed-off-by: Sandy Huang --- drivers/gpu/drm/rockchip/Kconfig | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..0534dc1 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -23,7 +23,7 @@ config ROCKCHIP_ANALOGIX_DP help This selects support for Rockchip SoC specific extensions for the Analogix Core DP driver. If you want to enable DP - on RK3288 based SoC, you should selet this option. + on RK3288 or RK3399 based SoC, you should select this option. config ROCKCHIP_CDN_DP bool "Rockchip cdn DP" @@ -39,16 +39,16 @@ config ROCKCHIP_DW_HDMI help This selects support for Rockchip SoC specific extensions for the Synopsys DesignWare HDMI driver. If you want to - enable HDMI on RK3288 based SoC, you should selet this - option. + enable HDMI on RK3288 or RK3399 based SoC, you should select + this option. config ROCKCHIP_DW_MIPI_DSI bool "Rockchip specific extensions for Synopsys DW MIPI DSI" help -This selects support for Rockchip SoC specific extensions -for the Synopsys DesignWare HDMI driver. If you want to -enable MIPI DSI on RK3288 based SoC, you should selet this -option. + This selects support for Rockchip SoC specific extensions + for the Synopsys DesignWare HDMI driver. If you want to + enable MIPI DSI on RK3288 or RK3399 based SoC, you should + select this option. config ROCKCHIP_INNO_HDMI bool "Rockchip specific extensions for Innosilicon HDMI" -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: fix coding style and incorrect description
Hi enric, thanks, this will be upated at v2 patch. 在 2018/8/27 15:02, Enric Balletbo Serra 写道: Hi Sandy, Just noticed a typo that I think will be good fix also Missatge de Sandy Huang del dia dl., 27 d’ag. 2018 a les 8:31: > > Align with other drivers, tab + 2 space key for description. > and this option should be enabled on both rk3288 and rk3399. > > Signed-off-by: Sandy Huang > --- > drivers/gpu/drm/rockchip/Kconfig | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig > index 0ccc762..601234b 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -45,10 +45,10 @@ config ROCKCHIP_DW_HDMI > config ROCKCHIP_DW_MIPI_DSI > bool "Rockchip specific extensions for Synopsys DW MIPI DSI" > help > - This selects support for Rockchip SoC specific extensions > - for the Synopsys DesignWare HDMI driver. If you want to > - enable MIPI DSI on RK3288 based SoC, you should selet this > - option. > + This selects support for Rockchip SoC specific extensions > + for the Synopsys DesignWare HDMI driver. If you want to > + enable MIPI DSI on RK3288 or RK3399 based SoC, you should > + selet this option. s/selet/select/ Cheers, Enric > > config ROCKCHIP_INNO_HDMI > bool "Rockchip specific extensions for Innosilicon HDMI" > -- > 2.7.4 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm/rockchip: Add support for Rockchip Soc RGB output interface
Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel and serial RGB data to panel or conversion chip, so we add this driver to probe encoder and connector. Signed-off-by: Sandy Huang Reviewed-by: Sean Paul Reviewed-by: Mark Yao Link: https://patchwork.freedesktop.org/patch/msgid/1509522851-128181-1-git-send-email-...@rock-chips.com --- Changes in v5: 1. add SPDX-License-Identifier tag Changes in v4: 1. add support px30; Changes in v3: 1. update for rgb-mode move to panel node. Changes in v2: 1. add error log when probe failed; 2. update name_to_output_mode() according to sean's suggest; 3. Fix uninitialized use of ret. drivers/gpu/drm/rockchip/Kconfig| 11 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 + drivers/gpu/drm/rockchip/rockchip_rgb.c | 314 5 files changed, 329 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..e88eb71 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -8,6 +8,7 @@ config DRM_ROCKCHIP select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_RGB if ROCKCHIP_RGB select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. @@ -66,4 +67,14 @@ config ROCKCHIP_LVDS Rockchip rk3288 SoC has LVDS TX Controller can be used, and it support LVDS, rgb, dual LVDS output mode. say Y to enable its driver. + +config ROCKCHIP_RGB + bool "Rockchip RGB support" + depends on DRM_ROCKCHIP + depends on PINCTRL + help + Choose this option to enable support for Rockchip RGB output. + Some Rockchip CRTCs, like rv1108, can directly output parallel + and serial RGB format to panel or connect to a conversion chip. + say Y to enable its driver. endif diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e21..868263f 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -14,5 +14,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o +rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 1d9c4a9..a9f35a7 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -432,6 +432,8 @@ static int __init rockchip_drm_init(void) CONFIG_ROCKCHIP_LVDS); ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver, CONFIG_ROCKCHIP_ANALOGIX_DP); + ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver, + CONFIG_ROCKCHIP_RGB); ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP); ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver, CONFIG_ROCKCHIP_DW_HDMI); diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index d67ad0a..009cd34 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h @@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver; extern struct platform_driver inno_hdmi_driver; extern struct platform_driver rockchip_dp_driver; extern struct platform_driver rockchip_lvds_driver; +extern struct platform_driver rockchip_rgb_driver; extern struct platform_driver vop_platform_driver; #endif /* _ROCKCHIP_DRM_DRV_H_ */ diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c b/drivers/gpu/drm/rockchip/rockchip_rgb.c new file mode 100644 index 000..b7e226b --- /dev/null +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c @@ -0,0 +1,314 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: + * Sandy Huang + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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. + */ + +#include +#include +#include +#inclu
[PATCH v5 1/2] devicetree/bindings: display: Add document for rockchip RGB output
This path add support rv1108 and px30 rgb output interface driver.
Signed-off-by: Sandy Huang
Link:
https://patchwork.freedesktop.org/patch/msgid/1509522765-118759-1-git-send-email-...@rock-chips.com
---
.../bindings/display/rockchip/rockchip-rgb.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..1f4909c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,70 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+ - "rockchip,px30-rgb";
+ - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: should be a "lcdc" entry or a "default" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+The rgb has two video ports described by:
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+ Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+ Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+ compatible = "auo,b101ean01";
+ enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <&rgb_out_panel>;
+ };
+ };
+};
+
+For Rockchip RV1108:
+
+ rgb: rgb {
+ compatible = "rockchip,rv1108-rgb";
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_in_vop: endpoint {
+ remote-endpoint = <&vop_out_rgb>;
+ };
+ };
+
+ rgb_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_out_panel: endpoint {
+ remote-endpoint = <&panel_in_rgb>;
+ };
+ };
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] devicetree/bindings: display: Add document for rockchip RGB output
在 2018/8/27 15:11, Heiko Stuebner 写道: Hi Sandy, trying to move this forward a bit :-) Hi heiko, update at version5 and add SPDX-License-Identifier tag. Am Mittwoch, 4. Juli 2018, 14:09:56 CEST schrieb Sandy Huang: > Hi Rob Herring, > Thanks for your review. > > 在 2018/7/4 2:25, Rob Herring 写道: >> On Tue, Jun 26, 2018 at 03:15:39PM +0800, Sandy Huang wrote: >>> This path add support rv1108 and px30 rgb output interface driver. >> >> Bindings are for h/w, not drivers. >> > I will update at next version as following: > This patch add support rv1108 and px30 rgb output interface >>> >>> Signed-off-by: Sandy Huang >>> Link: https://patchwork.freedesktop.org/patch/msgid/1509522765-118759-1-git-send-email-...@rock-chips.com >>> --- >>> >>> Changes in v4: Add support px30 >>> Changes in v3: None >>> Changes in v2: None >>> >>> .../bindings/display/rockchip/rockchip-rgb.txt | 73 ++ >>> 1 file changed, 73 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt >>> >>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt >>> new file mode 100644 >>> index 000..077b9ad >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt >>> @@ -0,0 +1,73 @@ >>> +Rockchip RV1108 RGB interface >>> + >>> + >>> +Required properties: >>> +- compatible: matching the soc type: >>> + - "rockchip,px30-rgb"; >>> + - "rockchip,rv1108-rgb"; >> >> This doesn't look right? What (and how) is getting programmed here >> because you don't have any register interface. >> > This is register for DRM encoder and connecter or bridge for some RGB > convert chips driver. > so far we don't have any register for rgb interface, but it's most > probable need to config some register for rgb interface in feauture for > rockchip platform. I think the basic-issue Rob was pointing out is that the devicetree describes hardware blocks and not the software representation. And the rgb output is not a separate block, but instead just a property of the vop itself, hence should possibly not have a separate "device". As I'm currently tinkering with rk3188 display support [0] - which only has rgb output at all - I modified your patch a bit to to showcase how that could look [1], where the soc vop struct simply has a feature flag indicating indicating a raw rgb output and the rgb driver then looks for bridges in the vop endpoints to distinguish them from soc-internals output encoders. Let me know what you think :-) Heiko [0] https://github.com/mmind/linux-rockchip/commits/wip/rk3188-lcdc [1] https://github.com/mmind/linux-rockchip/commit/fe74d2c4d76bcb6035b7207753e6afb85335b6cd needs also https://github.com/mmind/linux-rockchip/commit/c5a48c772f3564211dcd1ec71004de1d6dbb0307 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/rockchip: fix coding style and incorrect description
Missatge de Sandy Huang del dia dt., 28 d’ag. 2018 a les 9:45: > > Align with other drivers, tab + 2 space key for description. > and edp/hdmi/dsi can be used on both rk3288 and rk3399. > > Signed-off-by: Sandy Huang > --- > drivers/gpu/drm/rockchip/Kconfig | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig > index 0ccc762..0534dc1 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -23,7 +23,7 @@ config ROCKCHIP_ANALOGIX_DP > help > This selects support for Rockchip SoC specific extensions > for the Analogix Core DP driver. If you want to enable DP > - on RK3288 based SoC, you should selet this option. > + on RK3288 or RK3399 based SoC, you should select this option. > > config ROCKCHIP_CDN_DP > bool "Rockchip cdn DP" > @@ -39,16 +39,16 @@ config ROCKCHIP_DW_HDMI > help > This selects support for Rockchip SoC specific extensions > for the Synopsys DesignWare HDMI driver. If you want to > - enable HDMI on RK3288 based SoC, you should selet this > - option. > + enable HDMI on RK3288 or RK3399 based SoC, you should select > + this option. > > config ROCKCHIP_DW_MIPI_DSI > bool "Rockchip specific extensions for Synopsys DW MIPI DSI" > help > -This selects support for Rockchip SoC specific extensions > -for the Synopsys DesignWare HDMI driver. If you want to > -enable MIPI DSI on RK3288 based SoC, you should selet this > -option. > + This selects support for Rockchip SoC specific extensions > + for the Synopsys DesignWare HDMI driver. If you want to > + enable MIPI DSI on RK3288 or RK3399 based SoC, you should > + select this option. > > config ROCKCHIP_INNO_HDMI > bool "Rockchip specific extensions for Innosilicon HDMI" > -- > 2.7.4 If it helps... Reviewed-by: Enric Balletbo i Serra > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/rockchip: Add support for Rockchip Soc RGB output interface
Hi Sandy,
Am Dienstag, 28. August 2018, 10:12:34 CEST schrieb Sandy Huang:
> Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel
> and serial RGB data to panel or conversion chip, so we add this driver
> to probe encoder and connector.
>
> Signed-off-by: Sandy Huang
> Reviewed-by: Sean Paul
> Reviewed-by: Mark Yao
> Link:
> https://patchwork.freedesktop.org/patch/msgid/1509522851-128181-1-git-send-email-...@rock-chips.com
This does not really address, Rob's concern about not being an actual
hardware block related to the devicetree node you are using.
I see your reply to my mail, but I guess you didn't see the alternative
approach I described a bit below in that mail?
Actual (unfinished) code included below. (2 patches)
Heiko
8< -
From: Heiko Stuebner
Date: Sat, 25 Aug 2018 19:05:21 +0200
Subject: [PATCH 1/2] drm/tockchip: add function to check if endpoint is a
subdriver
To be able to have both internal subdrivers and external bridge
drivers as output endpoints of vops, add a function to be able
to distinguish these.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 27 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 1d9c4a9201c8..d18f7f85aa23 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -267,6 +268,32 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
static struct platform_driver *rockchip_sub_drivers[MAX_ROCKCHIP_SUB_DRIVERS];
static int num_rockchip_sub_drivers;
+/*
+ * check if a vop output-endpoint is a subdriver or bridge.
+ */
+bool rockchip_drm_endpoint_is_subdriver(struct device_node *ep)
+{
+ struct device_node *node = of_graph_get_remote_port_parent(ep);
+ struct platform_device *pdev;
+ int i;
+
+ if (!node)
+ return false;
+
+ pdev = of_find_device_by_node(node);
+ if (!pdev)
+ return false;
+
+ for (i = 0; i < num_rockchip_sub_drivers; i++) {
+ struct device_driver *drv = pdev->dev.driver;
+
+ if (rockchip_sub_drivers[i] == to_platform_driver(drv))
+ return true;
+ }
+
+ return false;
+}
+
static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index d67ad0a3cf36..305b4858c522 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -64,6 +64,7 @@ void rockchip_drm_dma_detach_device(struct drm_device
*drm_dev,
struct device *dev);
int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
+bool rockchip_drm_endpoint_is_subdriver(struct device_node *ep);
extern struct platform_driver cdn_dp_driver;
extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
extern struct platform_driver dw_mipi_dsi_driver;
--
2.17.0
8< -
From: Sandy Huang
Date: Tue, 26 Jun 2018 15:15:40 +0800
Subject: [PATCH 2/2] drm/rockchip: Add support for RGB output interface
Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel
and serial RGB data to panel or conversion chip.
So add a feature-bit for vops to mark the ability for these direct outputs
and add an internal encoder in that case, that can attach to bridge chips
or panels.
Signed-off-by: Sandy Huang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/Kconfig| 11 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_rgb.c | 212
drivers/gpu/drm/rockchip/rockchip_rgb.h | 19 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
7 files changed, 261 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ccc76217ee4..e88eb715ae6b 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+ select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
Choose this option if you have a Rockchip soc chipset.
@@ -66,4 +67,14 @@ config ROCKCHIP_LVDS
Rockchip rk3288 SoC has LVDS TX Controller ca
[PATCH] drm/rockchip: vop: fix some register define error for px30
1. interrupt register define error lead to enable interrupt failed;
2. px30 unsupport hdmi output;
3. there are some hardware designed bug, we must swap win2 gate and
enable offset, otherwise will appear vop iommu pagefault.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index d824ca6..7f29913 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -190,10 +190,10 @@ static const int px30_vop_intrs[] = {
static const struct vop_intr px30_intr = {
.intrs = px30_vop_intrs,
.nintrs = ARRAY_SIZE(px30_vop_intrs),
- .line_flag_num[0] = VOP_REG(PX30_LINE_FLAG, 0xfff, 12),
- .status = VOP_REG_SYNC(PX30_INTR_STATUS, 0xf, 0),
- .enable = VOP_REG_SYNC(PX30_INTR_EN, 0xf, 4),
- .clear = VOP_REG_SYNC(PX30_INTR_CLEAR, 0xf, 8),
+ .line_flag_num[0] = VOP_REG(PX30_LINE_FLAG, 0xfff, 0),
+ .status = VOP_REG_MASK_SYNC(PX30_INTR_STATUS, 0x, 0),
+ .enable = VOP_REG_MASK_SYNC(PX30_INTR_EN, 0x, 0),
+ .clear = VOP_REG_MASK_SYNC(PX30_INTR_CLEAR, 0x, 0),
};
static const struct vop_common px30_common = {
@@ -212,10 +212,8 @@ static const struct vop_modeset px30_modeset = {
static const struct vop_output px30_output = {
.rgb_pin_pol = VOP_REG(PX30_DSP_CTRL0, 0xf, 1),
- .hdmi_pin_pol = VOP_REG(PX30_DSP_CTRL0, 0xf, 9),
.mipi_pin_pol = VOP_REG(PX30_DSP_CTRL0, 0xf, 25),
.rgb_en = VOP_REG(PX30_DSP_CTRL0, 0x1, 0),
- .hdmi_en = VOP_REG(PX30_DSP_CTRL0, 0x1, 8),
.mipi_en = VOP_REG(PX30_DSP_CTRL0, 0x1, 24),
};
@@ -257,8 +255,8 @@ static const struct vop_win_phy px30_win1_data = {
static const struct vop_win_phy px30_win2_data = {
.data_formats = formats_win_lite,
.nformats = ARRAY_SIZE(formats_win_lite),
- .gate = VOP_REG(PX30_WIN2_CTRL0, 0x1, 0),
- .enable = VOP_REG(PX30_WIN2_CTRL0, 0x1, 4),
+ .gate = VOP_REG(PX30_WIN2_CTRL0, 0x1, 4),
+ .enable = VOP_REG(PX30_WIN2_CTRL0, 0x1, 0),
.format = VOP_REG(PX30_WIN2_CTRL0, 0x3, 5),
.rb_swap = VOP_REG(PX30_WIN2_CTRL0, 0x1, 20),
.dsp_info = VOP_REG(PX30_WIN2_DSP_INFO0, 0x0fff0fff, 0),
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
Quoting Lucas De Marchi (2018-08-28 02:00:27)
> On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > > index 4a34b7be..8a0e3e76 100644
> > > --- a/intel/intel_chipset.h
> > > +++ b/intel/intel_chipset.h
> > > @@ -568,6 +568,26 @@
> > >
> > > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> > >
> > > +/* New platforms use kernel pci ids */
> > > +#include "i915_pciids.h"
> > > +
> > > +struct pci_device_id {
> >
> > Don't call it pci_device_id, depending on caller that name may already
> > be taken by libpciaccess.
> >
> > > + uint32_t unused0, device;
> > > + uint32_t unused1, unused2;
> > > + uint32_t unused3, unused4;
> > These are all uint16_t.
>
> more on this:
>
> I can make the first 2 uint16_t, but not the rest due to the way they
> are declared in INTEL_VGA_DEVICE: (~0 has int type by default), unused3
> and unused4 are clearly not uint16_t
I had it in my mind that we did have one extra level of macro in there
that would allow us to drop unused fields. We could redef
INTEL_VGA_DEVICE() and INTEL_QUANTA_VGA_DEVICE() but one extra level of
macro would be easier for future.
And then while you are there, add the missing 'u' to ~0u
-Chris.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] of/platform: Initialise AMBA default DMA masks
commit a5516219b102 ("of/platform: Initialise default DMA masks")
sets up the coherent_dma_mask of platform devices created
from the device tree, but fails to do the same for AMBA
(PrimeCell) devices.
This leads to a regression in kernel v4.19-rc1 triggering the
WARN_ONCE() in kernel/dma/coherent.c, dma_alloc_attrs()
WARN_ON_ONCE(dev && !dev->coherent_dma_mask):
[ cut here ]
WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:522
drm_gem_cma_create+0x1dc/0x21c
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc1+ #15
Hardware name: ARM-Versatile (Device Tree Support)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (__warn+0xcc/0xf4)
[] (__warn) from [] (warn_slowpath_null+0x3c/0x48)
[] (warn_slowpath_null) from []
(drm_gem_cma_create+0x1dc/0x21c)
[] (drm_gem_cma_create) from []
(drm_gem_cma_dumb_create+0x44/0x98)
[] (drm_gem_cma_dumb_create) from []
(drm_client_framebuffer_create+0x80/0x204)
[] (drm_client_framebuffer_create) from []
(drm_fb_helper_generic_probe+0x4c/0x200)
[] (drm_fb_helper_generic_probe) from []
(__drm_fb_helper_initial_config_and_unlock+0x1cc/0x454)
[] (__drm_fb_helper_initial_config_and_unlock) from []
(drm_fb_helper_fbdev_setup+0x104/0x218)
[] (drm_fb_helper_fbdev_setup) from []
(drm_fbdev_cma_init+0x7c/0xac)
[] (drm_fbdev_cma_init) from []
(drm_fb_cma_fbdev_init+0x8/0x14)
[] (drm_fb_cma_fbdev_init) from []
(pl111_amba_probe+0x3c8/0x4a4)
[] (pl111_amba_probe) from [] (amba_probe+0xd8/0x154)
[] (amba_probe) from [] (really_probe+0x200/0x2ac)
[] (really_probe) from [] (driver_probe_device+0x5c/0x168)
[] (driver_probe_device) from [] (__driver_attach+0xd0/0xd4)
[] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4)
[] (bus_for_each_dev) from [] (bus_add_driver+0x170/0x204)
[] (bus_add_driver) from [] (driver_register+0x74/0x108)
[] (driver_register) from [] (do_one_initcall+0x48/0x1a0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x104/0x1c4)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0)
[] (kernel_init) from [] (ret_from_fork+0x14/0x34)
Exception stack(0xc781ffb0 to 0xc781fff8)
ffa0:
ffc0:
ffe0: 0013
---[ end trace 2dc47eb796bde006 ]---
This regresses the PL111 DRM driver in drivers/gpu/drm/pl111
that uses the AMBA PrimeCell to instantiate the frame buffer
device, as it cannot allocate a chunk of coherent memory
anymore due to the missing mask.
Fixes: a5516219b102 ("of/platform: Initialise default DMA masks")
Cc: Robin Murphy
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Eric Anholt
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
I don't know which tree Robins patch came in from, but I assume
Christoph's, so can you carry this patch as well?
---
drivers/of/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..7435c79ca56d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -242,6 +242,9 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
goto err_clear_flag;
/* setup generic device info */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dev.dma_mask)
+ dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = &node->fwnode;
dev->dev.parent = parent ? : &platform_bus;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/platform: Initialise AMBA default DMA masks
> /* setup generic device info */
> + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!dev->dev.dma_mask)
> + dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
We should never set dma_mask to point to the coherent_dma_mask,
as that will cause problems with devices that have different
mask for the two.
How about something like this?
---
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..c04ed124305c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -242,6 +242,9 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
goto err_clear_flag;
/* setup generic device info */
+ dev->dma_mask = DMA_BIT_MASK(32);
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.dma_mask = &dev->dma_mask;
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = &node->fwnode;
dev->dev.parent = parent ? : &platform_bus;
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index d143c13bed26..fbc7adf3ca54 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -34,6 +34,7 @@ struct amba_device {
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
char*driver_override;
+ u64 dma_mask;
};
struct amba_driver {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105317] The GPU Vega 56 was hang while try to pass #GraphicsFuzz shader15 test
https://bugs.freedesktop.org/show_bug.cgi?id=105317 Mauro Gaspari changed: What|Removed |Added CC||ilvip...@gmx.com --- Comment #10 from Mauro Gaspari --- I am also affected by this bug. I filed a bug with openSUSE tumbleweed and bug was closed earlier this year. However, with latest mesa updates, the issue resurfaced, therefore I reopened the bug. This is the link https://bugzilla.opensuse.org/show_bug.cgi?id=1090456 System Info: OS: OpenSUSE tumbleweed x86_64 updated (2018 08 27) Kernel: 4.18.0-1-default Desktop Environment: KDE Plasma (x11) OpenGL version string: 3.1 Mesa 18.1.6 GPU: AMD Radeon RX Vega 64 8GB Relevant log lines I found during freeze: 2018-08-09T23:16:53.103775+08:00 MGDT-Tumbleweed kernel: [ 6305.852703] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=1745163, last emitted seq= 1745165 2018-08-09T23:16:53.103795+08:00 MGDT-Tumbleweed kernel: [ 6305.852704] [drm] No hardware hang detected. Did some blocks stall? Dmesg lines relative to amdgpu: [3.130759] [drm] amdgpu kernel modesetting enabled. [3.135770] fb: switching to amdgpudrmfb from EFI VGA [3.136106] amdgpu :03:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x [3.136171] amdgpu :03:00.0: VRAM: 8176M 0x00F4 - 0x00F5FEFF (8176M used) [3.136173] amdgpu :03:00.0: GTT: 512M 0x00F6 - 0x00F61FFF [3.136494] [drm] amdgpu: 8176M of VRAM memory ready [3.136495] [drm] amdgpu: 8176M of GTT memory ready. [4.114469] fbcon: amdgpudrmfb (fb0) is primary device [4.141179] amdgpu :03:00.0: fb0: amdgpudrmfb frame buffer device [4.164072] amdgpu :03:00.0: ring 0(gfx) uses VM inv eng 4 on hub 0 [4.164074] amdgpu :03:00.0: ring 1(comp_1.0.0) uses VM inv eng 5 on hub 0 [4.164075] amdgpu :03:00.0: ring 2(comp_1.1.0) uses VM inv eng 6 on hub 0 [4.164075] amdgpu :03:00.0: ring 3(comp_1.2.0) uses VM inv eng 7 on hub 0 [4.164076] amdgpu :03:00.0: ring 4(comp_1.3.0) uses VM inv eng 8 on hub 0 [4.164077] amdgpu :03:00.0: ring 5(comp_1.0.1) uses VM inv eng 9 on hub 0 [4.164078] amdgpu :03:00.0: ring 6(comp_1.1.1) uses VM inv eng 10 on hub 0 [4.164079] amdgpu :03:00.0: ring 7(comp_1.2.1) uses VM inv eng 11 on hub 0 [4.164079] amdgpu :03:00.0: ring 8(comp_1.3.1) uses VM inv eng 12 on hub 0 [4.164080] amdgpu :03:00.0: ring 9(kiq_2.1.0) uses VM inv eng 13 on hub 0 [4.164081] amdgpu :03:00.0: ring 10(sdma0) uses VM inv eng 4 on hub 1 [4.164082] amdgpu :03:00.0: ring 11(sdma1) uses VM inv eng 5 on hub 1 [4.164083] amdgpu :03:00.0: ring 12(uvd) uses VM inv eng 6 on hub 1 [4.164084] amdgpu :03:00.0: ring 13(uvd_enc0) uses VM inv eng 7 on hub 1 [4.164085] amdgpu :03:00.0: ring 14(uvd_enc1) uses VM inv eng 8 on hub 1 [4.164085] amdgpu :03:00.0: ring 15(vce0) uses VM inv eng 9 on hub 1 [4.164086] amdgpu :03:00.0: ring 16(vce1) uses VM inv eng 10 on hub 1 [4.164087] amdgpu :03:00.0: ring 17(vce2) uses VM inv eng 11 on hub 1 [4.164553] [drm] Initialized amdgpu 3.25.0 20150101 for :03:00.0 on minor 0 as a side note, the freeze does not happen on my Kubuntu system. Same hardware, same games. OS: Kubuntu 18.04 x86_64 updated (2018 08 27) Kernel: 4.15.0-33-generic Desktop Environment: KDE Plasma (x11) OpenGL version string: 3.0 Mesa 18.0.5 GPU: AMD Radeon RX Vega 64 8GB -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
Hi Swati,
On Mon, Aug 27, 2018 at 12:17:45PM +0530, Swati Sharma wrote:
> From: Vidya Srinivas
>
> The following pixel formats are packed format that follows 4:2:2
> chroma sampling. For memory represenation each component is
> allocated 16 bits each. Thus each pixel occupies a DWORD.
>
> Y210: Valid data occupies MSB 10 bits.
> LSB 6 bits are filled with zeroes.
> Y212: Valid data occupies MSB 12 bits.
> LSB 4 bits are filled with zeroes.
> Y216: Valid data occupies 16 bits,
> doesn't require any padding bits.
>
> First 16 bits stores the Y value and the next 16 bits stores one
> of the chroma samples alternatively. The first luma sample will
> be accompanied by first U sample and second luma sample is
> accompanied by the first V sample.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 35c1e27..4bf04a5 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 2ed46e9..6a03e6d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -149,6 +149,10 @@
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>
> +#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
> Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
> +#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
> Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
I don't think this comments reflect very well the actual layout of the
color planes, I think you need to describe the padding as well.
Just looking at the comments without reading the commit message you
could easily assume that the padding happens is in the [63:40] bits.
> +
> /*
> * 2 plane RGB + A
> * index 0 = RGB plane, same format as the corresponding non _A8 format has
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][drm-next] drm/vkms: remove unused pointer vkms_obj
From: Colin Ian King
Pointer vkms_obj is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
variable ‘vkms_obj’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vkms/vkms_plane.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index c91661631c76..322d8170e769 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -128,14 +128,12 @@ static int vkms_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
struct drm_gem_object *gem_obj;
- struct vkms_gem_object *vkms_obj;
int ret;
if (!state->fb)
return 0;
gem_obj = drm_gem_fb_get_obj(state->fb, 0);
- vkms_obj = drm_gem_to_vkms_gem(gem_obj);
ret = vkms_gem_vmap(gem_obj);
if (ret)
DRM_ERROR("vmap failed: %d\n", ret);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [igt-dev] [PATCH v2 2/3] lib/kms: Remove special enum handling and replace with call to igt_plane_set_prop_enum, v2.
On Wed, 2018-08-15 at 12:08 +0200, Maarten Lankhorst wrote:
> We now have infrastructure for generic enum handling. This will make
> it easier
> to write new tests without defining all enum constants beforehand.
>
> Changes since v1:
> - Fix compile error, sent old version by accident.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Maarten Lankhorst
> ---
> lib/igt_color_encoding.c | 20 +++
> lib/igt_color_encoding.h | 3 ++
> lib/igt_kms.c| 77 +-
> --
> 3 files changed, 32 insertions(+), 68 deletions(-)
>
> diff --git a/lib/igt_color_encoding.c b/lib/igt_color_encoding.c
> index f445dbbc0250..03e16e0c9658 100644
> --- a/lib/igt_color_encoding.c
> +++ b/lib/igt_color_encoding.c
> @@ -23,6 +23,7 @@
>
> #include "igt_color_encoding.h"
> #include "igt_matrix.h"
> +#include "igt_core.h"
>
> struct color_encoding {
> float kr, kb;
> @@ -141,3 +142,22 @@ struct igt_mat4 igt_rgb_to_ycbcr_matrix(enum
> igt_color_encoding color_encoding,
>
> return igt_matrix_multiply(&r, &c);
> }
> +
> +const char *igt_color_encoding_to_str(enum igt_color_encoding
> encoding)
> +{
> + switch (encoding) {
> + case IGT_COLOR_YCBCR_BT601: return "ITU-R BT.601 YCbCr";
> + case IGT_COLOR_YCBCR_BT709: return "ITU-R BT.709 YCbCr";
> + case IGT_COLOR_YCBCR_BT2020: return "ITU-R BT.2020 YCbCr";
> + default: igt_assert(0); return NULL;
> + }
> +}
> +
> +const char *igt_color_range_to_str(enum igt_color_range range)
> +{
> + switch (range) {
> + case IGT_COLOR_YCBCR_LIMITED_RANGE: return "YCbCr limited
> range";
> + case IGT_COLOR_YCBCR_FULL_RANGE: return "YCbCr full range";
> + default: igt_assert(0); return NULL;
> + }
> +}
> diff --git a/lib/igt_color_encoding.h b/lib/igt_color_encoding.h
> index 0d8c819322af..3884e4939f4c 100644
> --- a/lib/igt_color_encoding.h
> +++ b/lib/igt_color_encoding.h
> @@ -41,6 +41,9 @@ enum igt_color_range {
> IGT_NUM_COLOR_RANGES,
> };
>
> +const char *igt_color_encoding_to_str(enum igt_color_encoding
> encoding);
> +const char *igt_color_range_to_str(enum igt_color_range range);
> +
> struct igt_mat4 igt_ycbcr_to_rgb_matrix(enum igt_color_encoding
> color_encoding,
> enum igt_color_range
> color_range);
> struct igt_mat4 igt_rgb_to_ycbcr_matrix(enum igt_color_encoding
> color_encoding,
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index e5272103e243..62d8468415c6 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -196,61 +196,6 @@ const char * const
> igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> [IGT_CONNECTOR_BROADCAST_RGB] = "Broadcast RGB",
> };
>
> -static const char * const
> igt_color_encoding_names[IGT_NUM_COLOR_ENCODINGS] = {
> - [IGT_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> - [IGT_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> - [IGT_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> -};
> -
> -static const char * const
> igt_color_range_names[IGT_NUM_COLOR_RANGES] = {
> - [IGT_COLOR_YCBCR_FULL_RANGE] = "YCbCr full range",
> - [IGT_COLOR_YCBCR_LIMITED_RANGE] = "YCbCr limited range",
> -};
> -
> -static void parse_enum_prop(drmModePropertyPtr prop,
> - int num_enums,
> - uint64_t values[],
> - const char * const enum_names[])
> -{
> - igt_assert((prop->flags & ~(DRM_MODE_PROP_IMMUTABLE |
> - DRM_MODE_PROP_ATOMIC)) ==
> DRM_MODE_PROP_ENUM);
> - igt_assert(prop->count_enums == prop->count_values);
> - igt_assert(prop->count_enums >= 1);
> - igt_assert(!!(prop->flags & DRM_MODE_PROP_IMMUTABLE) ==
> (prop->count_enums == 1));
> -
> - for (int i = 0; i < prop->count_enums; i++) {
> - for (int j = 0; j < num_enums; j++) {
> - if (strcmp(prop->enums[i].name,
> enum_names[j]))
> - continue;
> -
> - values[j] = prop->enums[i].value;
> - }
> - }
> -}
> -
> -static void
> -parse_color_encoding_prop(igt_plane_t *plane, drmModePropertyPtr
> prop)
> -{
> - parse_enum_prop(prop, ARRAY_SIZE(igt_color_encoding_names),
> - plane->color_encoding.values,
> - igt_color_encoding_names);
> -}
> -
> -static void
> -parse_color_range_prop(igt_plane_t *plane, drmModePropertyPtr prop)
> -{
> - parse_enum_prop(prop, ARRAY_SIZE(igt_color_range_names),
> - plane->color_range.values,
> - igt_color_range_names);
> -}
> -
> -typedef void (*parse_plane_prop_t)(igt_plane_t *plane,
> drmModePropertyPtr prop);
> -
> -static const parse_plane_prop_t
> igt_parse_plane_prop[IGT_NUM_PLANE_PROPS] = {
> - [IGT_PLANE_COLOR_ENCODING] = parse_color_encoding_prop,
> - [IGT_PLANE_COLOR_RANGE] = parse_color_range_prop,
> -};
> -
> /*
> * Retrieve all the properies specified in props_name and store them
> into
> * pl
[PATCH v6 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to use XYUV instead of AYUV, as we don't use alpha.
v6: Removed unneeded initializer for new XYUV format.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
drivers/gpu/drm/i915/intel_sprite.c | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 30fdfd1a3037..b63739e46adc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+ DRM_FORMAT_XYUV,
};
static const uint32_t skl_pri_planar_formats[] = {
@@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+ DRM_FORMAT_XYUV,
};
static const uint64_t skl_format_modifiers_noccs[] = {
@@ -3501,6 +3503,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
+ case DRM_FORMAT_XYUV:
+ return PLANE_CTL_FORMAT_AYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -13399,6 +13403,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
}
switch (format) {
+
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
@@ -13414,6 +13419,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -14540,6 +14546,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
break;
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c286dda625e4..2ac9471974c2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1420,6 +1420,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] drm: Introduce new DRM_FORMAT_XYUV
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e2742c27..81eb97d108f3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2ed46e9ae16a..5ba5b1473342 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -148,6 +148,7 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
/*
* 2 plane RGB + A
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/2] Add XYUV format support
Introduced new XYUV scan-in format for framebuffer and added support for it to i915 driver. Stanislav Lisovskiy (2): drm: Introduce new DRM_FORMAT_XYUV drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support. drivers/gpu/drm/drm_fourcc.c | 1 + drivers/gpu/drm/i915/intel_display.c | 7 +++ drivers/gpu/drm/i915/intel_sprite.c | 1 + include/uapi/drm/drm_fourcc.h| 1 + 4 files changed, 10 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 1/2] drm: Introduce new DRM_FORMAT_XYUV
On 28.08.2018 13:53, Stanislav Lisovskiy wrote:
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e2742c27..81eb97d108f3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
I think you need to set is_yuv here to true
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2ed46e9ae16a..5ba5b1473342 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -148,6 +148,7 @@ extern "C" {
#define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
/*
* 2 plane RGB + A
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/rockchip: Add support for Rockchip Soc RGB output interface
Hi hieko,
在 2018/8/28 16:31, Heiko Stuebner 写道:
Hi Sandy,
Am Dienstag, 28. August 2018, 10:12:34 CEST schrieb Sandy Huang:
Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel
and serial RGB data to panel or conversion chip, so we add this driver
to probe encoder and connector.
Signed-off-by: Sandy Huang
Reviewed-by: Sean Paul
Reviewed-by: Mark Yao
Link:
https://patchwork.freedesktop.org/patch/msgid/1509522851-128181-1-git-send-email-...@rock-chips.com
This does not really address, Rob's concern about not being an actual
hardware block related to the devicetree node you are using.
I see your reply to my mail, but I guess you didn't see the alternative
approach I described a bit below in that mail?
Actual (unfinished) code included below. (2 patches)
Heiko
yes,i didn't see the behind described:(
As you said devicetree describes hardware blocks,
I think you implement driver for rgb output interface is more
reasonable, i will adjust this driver refer to your implementation,
thanks:)
8< -
From: Heiko Stuebner
Date: Sat, 25 Aug 2018 19:05:21 +0200
Subject: [PATCH 1/2] drm/tockchip: add function to check if endpoint is a
subdriver
To be able to have both internal subdrivers and external bridge
drivers as output endpoints of vops, add a function to be able
to distinguish these.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 27 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 1d9c4a9201c8..d18f7f85aa23 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -267,6 +268,32 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
static struct platform_driver *rockchip_sub_drivers[MAX_ROCKCHIP_SUB_DRIVERS];
static int num_rockchip_sub_drivers;
+/*
+ * check if a vop output-endpoint is a subdriver or bridge.
+ */
+bool rockchip_drm_endpoint_is_subdriver(struct device_node *ep)
+{
+ struct device_node *node = of_graph_get_remote_port_parent(ep);
+ struct platform_device *pdev;
+ int i;
+
+ if (!node)
+ return false;
+
+ pdev = of_find_device_by_node(node);
+ if (!pdev)
+ return false;
+
+ for (i = 0; i < num_rockchip_sub_drivers; i++) {
+ struct device_driver *drv = pdev->dev.driver;
+
+ if (rockchip_sub_drivers[i] == to_platform_driver(drv))
+ return true;
+ }
+
+ return false;
+}
+
static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index d67ad0a3cf36..305b4858c522 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -64,6 +64,7 @@ void rockchip_drm_dma_detach_device(struct drm_device
*drm_dev,
struct device *dev);
int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
+bool rockchip_drm_endpoint_is_subdriver(struct device_node *ep);
extern struct platform_driver cdn_dp_driver;
extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
extern struct platform_driver dw_mipi_dsi_driver;
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: Add shmem GEM library
This patchset adds a library for shmem backed GEM objects and makes use of it in tinydrm. When I made tinydrm I used the CMA helper because it was very easy to use. July last year I learned that this limits which drivers to PRIME import from, since CMA requires continuous memory. tinydrm drivers don't require that. So I set out to change that looking first at shmem, but that wasn't working since shmem didn't work with fbdev deferred I/O. Then I did a vmalloc buffer attempt which worked with deferred I/O, but maybe wouldn't be of so much use as a library for other drivers to use. As my work to split out stuff from the CMA helper for shared use came to an end, I had a generic fbdev emulation that uses a shadow buffer for deferred I/O. This means that I can now use shmem buffers after all. I have looked at the other drivers that use drm_gem_get_pages() and several supports different cache modes so I've done that even though tinydrm only uses the cached one. tinydrm can both use vmalloc and shmem buffers, it doesn't matter as far as I can see. So the question is what will benefit the rest of DRM the most. This is what a vmalloc helper might look like (minus the now unneeded fbdev stuff): https://patchwork.freedesktop.org/patch/182735/ Noralf. Noralf Trønnes (2): drm: Add library for shmem backed GEM objects drm/tinydrm: Switch from CMA to shmem buffers Documentation/gpu/drm-kms-helpers.rst | 12 + drivers/gpu/drm/Kconfig| 6 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem_shmem_helper.c | 673 + drivers/gpu/drm/tinydrm/Kconfig| 2 +- drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 90 +--- drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 5 + drivers/gpu/drm/tinydrm/ili9225.c | 14 +- drivers/gpu/drm/tinydrm/ili9341.c | 6 +- drivers/gpu/drm/tinydrm/mi0283qt.c | 6 +- drivers/gpu/drm/tinydrm/mipi-dbi.c | 38 +- drivers/gpu/drm/tinydrm/repaper.c | 24 +- drivers/gpu/drm/tinydrm/st7586.c | 15 +- drivers/gpu/drm/tinydrm/st7735r.c | 6 +- include/drm/drm_gem_shmem_helper.h | 198 include/drm/tinydrm/tinydrm.h | 36 +- 16 files changed, 978 insertions(+), 154 deletions(-) create mode 100644 drivers/gpu/drm/drm_gem_shmem_helper.c create mode 100644 include/drm/drm_gem_shmem_helper.h -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Add library for shmem backed GEM objects
This adds a library for shmem backed GEM objects with the necessary
drm_driver callbacks.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/drm-kms-helpers.rst | 12 +
drivers/gpu/drm/Kconfig| 6 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_gem_shmem_helper.c | 673 +
include/drm/drm_gem_shmem_helper.h | 198 ++
5 files changed, 890 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_shmem_helper.c
create mode 100644 include/drm/drm_gem_shmem_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index f9cfcdcdf024..bc24b1b5216a 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -326,3 +326,15 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+SHMEM GEM Helper Reference
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_shmem_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :export:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cb88528e7b10..db588ae44bcc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -157,6 +157,12 @@ config DRM_KMS_CMA_HELPER
help
Choose this if you need the KMS CMA helper functions
+config DRM_GEM_SHMEM_HELPER
+ bool
+ depends on DRM
+ help
+ Choose this if you need the GEM shmem helper functions
+
config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a6771cef85e2..c6798590799f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,6 +24,7 @@ drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
new file mode 100644
index ..71203dee2ad1
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -0,0 +1,673 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers for GEM objects backed by shmem buffers
+ * allocated using anonymous pageable memory.
+ */
+
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ *
+ * This function creates a shmem GEM object. The default cache mode is
+ * DRM_GEM_SHMEM_BO_CACHED. The &drm_driver->gem_create_object callback can be
+ * used override this.
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size)
+{
+ struct drm_gem_shmem_object *shmem;
+ struct drm_gem_object *obj;
+ int ret;
+
+ size = PAGE_ALIGN(size);
+
+ if (dev->driver->gem_create_object)
+ obj = dev->driver->gem_create_object(dev, size);
+ else
+ obj = kzalloc(sizeof(*shmem), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ shmem = to_drm_gem_shmem_obj(obj);
+
+ if (!dev->driver->gem_create_object)
+ shmem->cache_mode = DRM_GEM_SHMEM_BO_CACHED;
+
+ ret = drm_gem_object_init(dev, obj, size);
+ if (ret)
+ goto err_free;
+
+ ret = drm_gem_create_mmap_offset(obj);
+ if (ret)
+ goto err_release;
+
+ mutex_init(&shmem->pages_lock);
+ mutex_init(&shmem->vmap_lock);
+
+ return shmem;
+
+err_release:
+ drm_gem_object_release(obj);
+err_free:
+ kfree(shmem);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
+
+/**
+ * drm_gem_shmem_free_object - Free resources associated with a shmem GEM
object
+ * @obj: GEM object to free
+ *
+ * This function cleans up the GEM object state and frees the memory used to
+ * store the object itself. Drivers using the shmem helpers should set this as
+ * their &drm_driver.gem_free_object_unlocked callback.
+ */
+void drm_gem_shmem_free_object(struct drm_gem_object *obj)
+{
+ struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+
+ WARN_ON(shmem->vmap_use_count);
+
+ if (obj->import_attach) {
+ shmem->pages_use_count--;
+ drm_prime_gem_destroy(obj, shmem->sgt);
+ kvf
[PATCH 2/2] drm/tinydrm: Switch from CMA to shmem buffers
This move makes tinydrm useful for more drivers. tinydrm doesn't need
continuous memory, but at the time it was convenient to use the CMA
library. The spi core can do dma on is_vmalloc() addresses making this
possible.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/Kconfig| 2 +-
drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 90 +++---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 5 ++
drivers/gpu/drm/tinydrm/ili9225.c | 14 ++--
drivers/gpu/drm/tinydrm/ili9341.c | 6 +-
drivers/gpu/drm/tinydrm/mi0283qt.c | 6 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 38 ---
drivers/gpu/drm/tinydrm/repaper.c | 24 +++
drivers/gpu/drm/tinydrm/st7586.c | 15 +++--
drivers/gpu/drm/tinydrm/st7735r.c | 6 +-
include/drm/tinydrm/tinydrm.h | 36 +++
11 files changed, 88 insertions(+), 154 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 16f4b5c91f1b..aa0cabba5ace 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -2,7 +2,7 @@ menuconfig DRM_TINYDRM
tristate "Support for simple displays"
depends on DRM
select DRM_KMS_HELPER
- select DRM_KMS_CMA_HELPER
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option if you have a tinydrm supported display.
If M is selected the module will be called tinydrm.
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 255341ee4eb9..35de4dd3a0d6 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,7 +24,7 @@
*
* It is based on &drm_simple_display_pipe coupled with a &drm_connector which
* has only one fixed &drm_display_mode. The framebuffers are backed by the
- * cma helper and have support for framebuffer flushing (dirty).
+ * shmem buffers and have support for framebuffer flushing (dirty).
* fbdev support is also included.
*
*/
@@ -37,84 +38,37 @@
*/
/**
- * tinydrm_gem_cma_prime_import_sg_table - Produce a CMA GEM object from
- * another driver's scatter/gather table of pinned pages
- * @drm: DRM device to import into
- * @attach: DMA-BUF attachment
- * @sgt: Scatter/gather table of pinned pages
+ * tinydrm_fb_destroy - Destroy framebuffer
*
- * This function imports a scatter/gather table exported via DMA-BUF by
- * another driver using drm_gem_cma_prime_import_sg_table(). It sets the
- * kernel virtual address on the CMA object. Drivers should use this as their
- * &drm_driver->gem_prime_import_sg_table callback if they need the virtual
- * address. tinydrm_gem_cma_free_object() should be used in combination with
- * this function.
- *
- * Returns:
- * A pointer to a newly created GEM object or an ERR_PTR-encoded negative
- * error code on failure.
+ * This function unmaps the virtual address on the backing buffer and destroys
the framebuffer.
+ * Drivers should use this as their &drm_framebuffer_funcs->destroy callback.
*/
-struct drm_gem_object *
-tinydrm_gem_cma_prime_import_sg_table(struct drm_device *drm,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
+void tinydrm_fb_destroy(struct drm_framebuffer *fb)
{
- struct drm_gem_cma_object *cma_obj;
- struct drm_gem_object *obj;
- void *vaddr;
-
- vaddr = dma_buf_vmap(attach->dmabuf);
- if (!vaddr) {
- DRM_ERROR("Failed to vmap PRIME buffer\n");
- return ERR_PTR(-ENOMEM);
- }
-
- obj = drm_gem_cma_prime_import_sg_table(drm, attach, sgt);
- if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, vaddr);
- return obj;
- }
-
- cma_obj = to_drm_gem_cma_obj(obj);
- cma_obj->vaddr = vaddr;
-
- return obj;
+ drm_gem_shmem_vunmap(to_drm_gem_shmem_obj(fb->obj[0]));
+ drm_gem_fb_destroy(fb);
}
-EXPORT_SYMBOL(tinydrm_gem_cma_prime_import_sg_table);
-
-/**
- * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
- * object
- * @gem_obj: GEM object to free
- *
- * This function frees the backing memory of the CMA GEM object, cleans up the
- * GEM object state and frees the memory used to store the object itself using
- * drm_gem_cma_free_object(). It also handles PRIME buffers which has the
kernel
- * virtual address set by tinydrm_gem_cma_prime_import_sg_table(). Drivers
- * can use this as their &drm_driver->gem_free_object_unlocked callback.
- */
-void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj)
-{
- if (gem_obj->import_attach) {
- struct drm_gem_cma_object *cma_obj;
-
-
Re: [PATCH] drm: Convert to using %pOFn instead of device_node.name
Op 28-08-18 om 03:52 schreef Rob Herring:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Gustavo Padovan
> Cc: Maarten Lankhorst
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Rob Clark
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/drm_modes.c | 4 ++--
> drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 02db9ac82d7a..24a750436559 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -716,8 +716,8 @@ int of_get_drm_display_mode(struct device_node *np,
> if (bus_flags)
> drm_bus_flags_from_videomode(&vm, bus_flags);
>
> - pr_debug("%pOF: got %dx%d display mode from %s\n",
> - np, vm.hactive, vm.vactive, np->name);
> + pr_debug("%pOF: got %dx%d display mode\n",
> + np, vm.hactive, vm.vactive);
Aren't you removing it here instead of converting?
~Maarten
> drm_mode_debug_printmodeline(dmode);
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
> index c79659ca5706..23670907a29d 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
> @@ -579,7 +579,7 @@ static int msm_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> hdmi_cfg = (struct hdmi_platform_config *)
> of_device_get_match_data(dev);
> if (!hdmi_cfg) {
> - dev_err(dev, "unknown hdmi_cfg: %s\n", of_node->name);
> + dev_err(dev, "unknown hdmi_cfg: %pOFn\n", of_node);
> return -ENXIO;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/4] drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init()
Hi Lyude, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.19-rc1 next-20180828] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-dp_mst-Add-DP-MST-debugfs-nodes-for-all-drivers/20180828-083742 reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:977: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info' include/linux/mod_devicetable.h:763: warning: Function parameter or member 'driver_data' not described in 'typec_device_id' kernel/sched/fair.c:3371: warning: Funct
Re: [PATCH] of/platform: Initialise AMBA default DMA masks
On Tue, Aug 28, 2018 at 11:21 AM Christoph Hellwig wrote: > > + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > > + if (!dev->dev.dma_mask) > > + dev->dev.dma_mask = &dev->dev.coherent_dma_mask; > > We should never set dma_mask to point to the coherent_dma_mask, > as that will cause problems with devices that have different > mask for the two. > > How about something like this? (...) > + u64 dma_mask; We did that before, so this becomes effectively a revert of: commit 446b2a9380b64b9d7410d86ee8226031e03645cf DMA-API: amba: get rid of separate dma_mask AMBA Primecell devices always treat streaming and coherent DMA exactly the same, so there's no point in having the masks separated. So there is some history around this. There is also some code in drivers/amba/bus.c affected by that and I need to look over all static amba device allocations if we reintroduce this. That said, the remaining static allocations (a.k.a. boardfiles) appear to be very few and very limited, almost all systems use device tree or ACPI or iterative dynamic allocation (from amba/bus.c functions) of the amba devices now. Do you think we can proceed with this patch or do you want me to revert the split back? FWIW the platform devices have the same problem, but I know I know, two wrongs does not make one right :/ Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings
On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda wrote: > On 24.08.2018 14:23, Linus Walleij wrote: > > This adds bindings for a virtual display to be used with displays > > inside entirely virtual environments which do not emulate things > > like monitors but just need timing information to be supplied to > > its display controller. > > > > This is inspired by earlier work by Liviu Dudau. > > If this is pure virtual then it should be connected to other pure > virtual components. OK it's a bit of half-half but outside of my grasp, I am just trying to support legacy systems. The device tree is there: arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi The latter contains the CLCD which is the display driver. In RTSM, which is an ARM product I do not develop and cannot make changes to, there is an emulated CLCD. So that part appear as if it was real hardware. Like in QEMU. But the display does not have any emulation. The raw output from the CLCD is latched out to the screen. I do not know exactly know how the RTSM emulator actually works, but I suspect that the little graphic window on the screeen adapts to what gets written into the CLCD control registers, so anything goes, more or less. To satisfy the CLCD with some timings and resolution, this bridge gives it that, from the device tree, in a way that clearly conveys that "this is not a real thing". The old code uses DPI. This is not DPI, not even close to it. It worked simply because all the DPI really does is what this patch does: provide timings. By contrast on QEMU I have patches the emulator to properly represent the I2C DDC link and provide EDID so that is all fine. I cannot patch RTSM to emulate I2C and DDC. It's not open source. But the device tree in the kernel supports this "machine" and so, I have to maintain it when modernizng the fbdev driver to a DRM driver. I'm sorry RTSM is half/half. Not my fault. I can't fix... > And one more thing, you are defining virtual panel but you are using > drm_bridge framework, why not drm_panel? This was discussed before in the previous patch set: https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html Essentially, it's because the display driver is just connected to "something" not a panel and a bridge is likely the best I can come up with - a bridge over to a virtual display. A patch to add "VGA", "SGA" and "XGA" to the simple panels was NACKed (sort of, politely): https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html Also it was noted that it would be nice to have something that would make it easy to change resolutions on these virtual display things. Voila. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #9 from Fermulator --- this morning, at the system physically the issue I submitted originally is no longer happening (there have been several kernel updates since original submission ...) $ uname -r 4.17.17-100.fc27.x86_64 now however, the symptom is: noticed that the same monitor (connected via DisplayPort) had mis-match capabilities (wasn't able to go max resolution) ``` $ xrandr Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384 DisplayPort-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1920x1080 59.95* 1600x1200 59.95 1680x1050 59.95 1280x1024 59.95 1440x900 59.95 1280x800 59.95 1280x720 59.95 1024x768 59.95 800x600 59.95 640x480 59.95 HDMI-A-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 59.95 1600x1200 60.00 1680x1050 59.95 1280x1024 60.02 1440x900 59.95 1280x960 60.00 1280x800 59.95 1280x720 59.95 1024x768 60.00 800x600 60.3256.25 640x480 59.94 ``` The " 1920x1200 59.95*+" option is missing from the display port monitor. If I disconnect the DP, and reconnect, it comes back. ``` $ xrandr | grep + DisplayPort-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ DVI-D-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ ``` -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #10 from Fermulator --- (perhaps I should submit a NEW bug report and close this as not reproducible?) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #11 from Fermulator --- Created attachment 141308 --> https://bugs.freedesktop.org/attachment.cgi?id=141308&action=edit dmesg output post DP disconnect + reconnect to fix resolution -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #12 from Fermulator --- dumping newer versions too (which may explain why the original issue is no longer happening) $ dnf info xorg-x11-drv-amdgpu Failed to synchronize cache for repo 'mosquito-atom', disabling. Failed to synchronize cache for repo 'region51-chrome-gnome-shell', disabling. Failed to synchronize cache for repo 'spacewalk-client', disabling. Last metadata expiration check: 20 days, 23:02:26 ago on Tue 07 Aug 2018 11:04:16 AM EDT. Installed Packages Name : xorg-x11-drv-amdgpu Version : 18.0.1 Release : 1.fc27 Arch : x86_64 Size : 147 k Source : xorg-x11-drv-amdgpu-18.0.1-1.fc27.src.rpm Repo : @System >From repo: updates Summary : AMD GPU video driver URL : https://www.x.org/wiki License : MIT Description : X.Org X11 AMDGPU driver $ rpm -qa | egrep "amdgpu|gdm|dri-|xorg-x11-server|gnome-session" mesa-dri-drivers-17.3.9-1.fc27.x86_64 xorg-x11-server-utils-7.7-23.fc27.x86_64 xorg-x11-drv-amdgpu-18.0.1-1.fc27.x86_64 gnome-session-3.26.1-1.fc27.x86_64 gdm-3.26.2.1-3.fc27.x86_64 gnome-session-xsession-3.26.1-1.fc27.x86_64 xorg-x11-server-Xephyr-1.19.6-7.fc27.x86_64 gnome-session-wayland-session-3.26.1-1.fc27.x86_64 pulseaudio-gdm-hooks-12.2-1.fc27.x86_64 xorg-x11-server-Xorg-1.19.6-7.fc27.x86_64 xorg-x11-server-common-1.19.6-7.fc27.x86_64 xorg-x11-server-Xwayland-1.19.6-7.fc27.x86_64 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/platform: Initialise AMBA default DMA masks
On Tue, Aug 28, 2018 at 03:25:55PM +0200, Linus Walleij wrote: > On Tue, Aug 28, 2018 at 11:21 AM Christoph Hellwig wrote: > > > > + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > > > + if (!dev->dev.dma_mask) > > > + dev->dev.dma_mask = &dev->dev.coherent_dma_mask; > > > > We should never set dma_mask to point to the coherent_dma_mask, > > as that will cause problems with devices that have different > > mask for the two. > > > > How about something like this? > (...) > > + u64 dma_mask; > > We did that before, so this becomes effectively a revert of: > commit 446b2a9380b64b9d7410d86ee8226031e03645cf > > DMA-API: amba: get rid of separate dma_mask > > AMBA Primecell devices always treat streaming and coherent DMA exactly > the same, so there's no point in having the masks separated. > > So there is some history around this. > > There is also some code in drivers/amba/bus.c affected by that > and I need to look over all static amba device allocations if we > reintroduce this. I don't have the rest of this thread to read... But yes, the fundamental fact is that AMBA devices don't have any care about the differences between coherent and streaming DMA. The distinction that we make in the kernel is purely a software one when it comes to these devices. Most AMBA devices themselves are not DMA capable, as they are only connected to the APB (Amba peripheral bus) and they rely on a separate DMA engine for their DMA. APB devices should not have DMA masks - their DMA capabilities are entirely down to the DMA controller. So, the majority of AMBA devices should not have any DMA masks. Only those connected to a bus that they can master on (eg AXI) should have DMA masks - things like the PL08x DMA controllers, PL11x LCD controllers, etc. As I've said above, there is no difference between streaming and coherent DMA for these devices. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #13 from Michel Dänzer --- (In reply to Fermulator from comment #10) > (perhaps I should submit a NEW bug report and close this as not > reproducible?) Yes, please do. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings
Hi Andrzej,
Chirping in, as it was originally my work that Linus is adopting.
On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
> On 24.08.2018 14:23, Linus Walleij wrote:
> > This adds bindings for a virtual display to be used with displays
> > inside entirely virtual environments which do not emulate things
> > like monitors but just need timing information to be supplied to
> > its display controller.
> >
> > This is inspired by earlier work by Liviu Dudau.
>
> If this is pure virtual then it should be connected to other pure
> virtual components.
Any reason why you think this is the only way this should be connected?
My original implementation (and I haven't seen anything in this patch
that would invalidate it) assumed that the virtual bridge can be used by
any driver that uses the component framework. Hiding implementation
details is one of the benefits of using the component framework, so I
don't see what you gain by restricting connection to only other pure
virtual components.
> What will be this virtual bridge attached to? I expect some virtual
> encoder, virtual crtc? If yes then why don't you create whole virtual
> drm pipeline in one patchset?
This comment is probably more relevant to patch 2/2, but I agree that
it probably needs a virtual encoder. As for the CRTC, it should work
with any real DRM driver, AFAICT.
> Could you describe more what do you want to do.
He wants to enable the PL110 DRM driver on systems that lack a way of
detecting the actual encoder and connector being used (either because
there is none and they are emulated in software that doesn't mimic the
HW behaviour, or because the way you access the HW is done in a way that
doesn't model easily in the current DRM framework: by firmware, for
example).
Best regards,
Liviu
> And one more thing, you are defining virtual panel but you are using
> drm_bridge framework, why not drm_panel?
>
> Regards
> Andrzej
>
> >
> > Cc: Liviu Dudau
> > Cc: Ryan Harkin
> > Signed-off-by: Linus Walleij
> > ---
> > .../display/bridge/virtual-display-bridge.txt | 62 +++
> > 1 file changed, 62 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >
> > b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > new file mode 100644
> > index ..ea4f5a91ab94
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > @@ -0,0 +1,62 @@
> > +Virtual Display Bridge
> > +
> > +This represents a display that is contained within an emulated
> > +environment.
> > +
> > +This means that the display engine mainly expects some timing
> > +parameters to be written into it, and after that the emulator will
> > +respond by creating a virtual display with the requested
> > +resolution characteristics.
> > +
> > +As the operating system cannot "detect" such a display, rather the
> > +emulator will respond to what the controller outputs, a
> > +chicken-and-egg problem needs to be solved: the resolution and
> > +timing characteristics need to be defined and set up somewhere.
> > +
> > +The virtual display bridge solves this by defining a bridge with
> > +all timing characteristics encoded into the device tree node.
> > +
> > +Required properies:
> > +- compatible: shall be "virtual-display-bridge"
> > +
> > +Required subnodes:
> > +- display-timings: contains in turn a display timing node
> > + see display-timing.txt
> > +- ports: contains the display ports, see media/video-interfaces.txt
> > +
> > +Example:
> > +
> > +bridge {
> > + compatible = "virtual-display-bridge";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + display-timings {
> > + /* Some standard VGA timing */
> > + timing0 {
> > + clock-frequency = <23750>;
> > + hactive = <640>;
> > + vactive = <480>;
> > + hfront-porch = <48>;
> > + hback-porch = <16>;
> > + hsync-len = <96>;
> > + vfront-porch = <33>;
> > + vback-porch = <9>;
> > + vsync-len = <3>;
> > + vrefresh = <60>;
> > + };
> > + };
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + display_bridge_in: endpoint {
> > + remote-endpoint = <&foo>;
> > + };
> > + };
> > + };
> > +};
>
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.fre
Re: [PATCH 2/2] drm/bridge: Add support for a virtual display bridge
Hi Linus,
On Fri, Aug 24, 2018 at 02:23:32PM +0200, Linus Walleij wrote:
> This adds a very small and simple driver to read a virtual
and simple bridge driver
> display characteristic from the device tree and reflect it
> back into DRM so a display driver in a virtual environment
> knows how to configure its output.
It is the job of the encoder to configure itself as well, and I
think that for RTSM you need a virtual encoder as well.
>
> This was created for the ARM RTSM aemv8a emulator as a way
> forward to convert all ARM reference designs to use the
> PL11x DRM driver.
>
> Cc: Liviu Dudau
> Cc: Ryan Harkin
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/bridge/Kconfig | 10 ++
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/virtual-display.c | 186 +++
> 3 files changed, 197 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/virtual-display.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index fa2c7997e2fd..cfb61305b3f6 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -126,6 +126,16 @@ config DRM_TI_TFP410
> ---help---
> Texas Instruments TFP410 DVI/HDMI Transmitter driver
>
> +config DRM_VIRTUAL_DISPLAY_BRIDGE
> + tristate "Virtual Display Bridge support"
> + depends on OF
> + select DRM_KMS_HELPER
> + select VIDEOMODE_HELPERS
> + help
> + Support for virtualized environments where the avilable
> + resolution is controlled by software configuration in
> + the device tree.
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 35f88d48ec20..2bdf67d98972 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -14,4 +14,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_VIRTUAL_DISPLAY_BRIDGE) += virtual-display.o
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/virtual-display.c
> b/drivers/gpu/drm/bridge/virtual-display.c
> new file mode 100644
> index ..ab55b3d6be8a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/virtual-display.c
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2018 Linus Walleij
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct virtenc {
I think the name you picked is going to be confusing, as this is not an
encoder at all, but a virtual connector.
> + struct device *dev;
> + struct drm_device *drm;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct drm_display_mode mode;
> + u32 bus_flags;
> +};
> +
> +static inline struct virtenc *bridge_to_virtenc(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct virtenc, bridge);
> +}
> +
> +static inline struct virtenc *connector_to_virtenc(struct drm_connector *con)
> +{
> + return container_of(con, struct virtenc, connector);
> +}
> +
> +static enum drm_connector_status
> +virtenc_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
> +
> +static const struct drm_connector_funcs virtenc_connector_funcs = {
> + .detect = virtenc_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int virtenc_get_modes(struct drm_connector *connector)
> +{
> + struct virtenc *virtenc = connector_to_virtenc(connector);
> + struct drm_display_mode *mode = drm_mode_create(virtenc->drm);
> + u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> + int ret;
> +
> + drm_mode_copy(mode, &virtenc->mode);
> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> + mode->width_mm = 80;
> + mode->height_mm = 60;
> + drm_mode_set_name(mode);
> +
> + drm_mode_probed_add(connector, mode);
> + ret = drm_display_info_set_bus_formats(&connector->display_info,
> +&bus_format, 1);
> + if (ret)
> + return ret;
> +
> + return 1;
> +}
> +
> +static enum drm_mode_status virtenc_mode_valid(struct drm_connector
> *connector,
> +struct drm_display_mode *mode)
> +{
> + return MODE_OK;
> +}
> +
> +static const struct drm_connector_helper_funcs
> +virtenc_connector_helper_funcs = {
> + .get_modes = virtenc_get_modes,
> + .m
Re: [PATCH] drm: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 9:53 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Gustavo Padovan
> Cc: Maarten Lankhorst
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Rob Clark
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Rob Herring
for msm part,
Acked-by: Rob Clark
(for drm_modes part, I guess there is no harm removing the redundant name)
BR,
-R
> ---
> drivers/gpu/drm/drm_modes.c | 4 ++--
> drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 02db9ac82d7a..24a750436559 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -716,8 +716,8 @@ int of_get_drm_display_mode(struct device_node *np,
> if (bus_flags)
> drm_bus_flags_from_videomode(&vm, bus_flags);
>
> - pr_debug("%pOF: got %dx%d display mode from %s\n",
> - np, vm.hactive, vm.vactive, np->name);
> + pr_debug("%pOF: got %dx%d display mode\n",
> + np, vm.hactive, vm.vactive);
> drm_mode_debug_printmodeline(dmode);
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
> index c79659ca5706..23670907a29d 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
> @@ -579,7 +579,7 @@ static int msm_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> hdmi_cfg = (struct hdmi_platform_config *)
> of_device_get_match_data(dev);
> if (!hdmi_cfg) {
> - dev_err(dev, "unknown hdmi_cfg: %s\n", of_node->name);
> + dev_err(dev, "unknown hdmi_cfg: %pOFn\n", of_node);
> return -ENXIO;
> }
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Convert to using %pOFn instead of device_node.name
On Tue, Aug 28, 2018 at 7:54 AM Maarten Lankhorst
wrote:
>
> Op 28-08-18 om 03:52 schreef Rob Herring:
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Gustavo Padovan
> > Cc: Maarten Lankhorst
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Rob Clark
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
> > Signed-off-by: Rob Herring
> > ---
> > drivers/gpu/drm/drm_modes.c | 4 ++--
> > drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 02db9ac82d7a..24a750436559 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -716,8 +716,8 @@ int of_get_drm_display_mode(struct device_node *np,
> > if (bus_flags)
> > drm_bus_flags_from_videomode(&vm, bus_flags);
> >
> > - pr_debug("%pOF: got %dx%d display mode from %s\n",
> > - np, vm.hactive, vm.vactive, np->name);
> > + pr_debug("%pOF: got %dx%d display mode\n",
> > + np, vm.hactive, vm.vactive);
> Aren't you removing it here instead of converting?
Well, yes. The full path and name are already printed so the node name
alone was pretty redundant.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #9 from Alex Deucher --- Created attachment 141309 --> https://bugs.freedesktop.org/attachment.cgi?id=141309&action=edit possible fix This patch should help but please check if you can pass several S3 cycles with it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Fix crtc color management when doing suspend/resume
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problem is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the saved state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true in
drm_atomic_helper_check_modeset when at least one of gamma_lut,
degamma_lut, ctm is different between the new and the old crtc state.
Also, this makes unnecessary the setting of color_mgmt_changed in
places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
Changes since v2:
- Instead of setting color_mgmt_changed in commit_duplicated_set
just set it in check_modeset and clean up other place where it was
set, suggested by Maarten Lankhorst.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_atomic.c| 12 +++-
drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
drivers/gpu/drm/drm_fb_helper.c | 1 -
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d0478abc01bd..9bcada3c299e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->degamma_lut,
val,
-1, sizeof(struct drm_color_lut),
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->ctm_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->ctm,
val,
sizeof(struct drm_color_ctm), -1,
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->gamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
val,
-1, sizeof(struct drm_color_lut),
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2c23a48482da..fe22e1ad468a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return -EINVAL;
}
+ if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
||
+ new_crtc_state->ctm != old_crtc_state->ctm ||
+ new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
changed\n",
+crtc->base.id, crtc->name);
+ new_crtc_state->color_mgmt_changed = true;
+ }
}
ret = handle_conflicting_encoders(state, false);
@@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
- crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4b0dd20bccb8..8541e95a5410 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1442,7 +1442,6 @@ static int setcmap_atomic(struct fb_cmap *cmap, struct
fb_info *info)
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
gamma_lut);
- crtc_state->color_mgmt_change
Re: [PATCH 2/3] mach64: fix image corruption due to reading accelerator registers
On Mon, 27 Aug 2018, Ville Syrjälä wrote:
> On Sat, Aug 25, 2018 at 03:51:52PM -0400, Mikulas Patocka wrote:
> > Reading the registers without waiting for engine idle returns
> > unpredictable values. These unpredictable values result in display
> > corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
> > bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
> > never ever clear the bit, resulting in display corruption.
> >
> > We don't want to wait for idle because it would degrade performance, so
> > this patch modifies the driver so that it never reads accelerator
> > registers.
> >
> > HOST_CNTL doesn't have to be read, we can just write it with
> > HOST_BYTE_ALIGN because no other part of the driver cares if
> > HOST_BYTE_ALIGN is set.
> >
> > DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
> > with the default value and in atyfb_imageblit with the value set according
> > to the source image data.
> >
> > Signed-off-by: Mikulas Patocka
> > Cc: sta...@vger.kernel.org
> >
> > ---
> > drivers/video/fbdev/aty/mach64_accel.c | 22 +-
> > 1 file changed, 9 insertions(+), 13 deletions(-)
> >
> > Index: linux-stable/drivers/video/fbdev/aty/mach64_accel.c
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/mach64_accel.c
> > 2018-08-24 19:51:34.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/mach64_accel.c 2018-08-24
> > 20:28:55.0 +0200
> > @@ -127,7 +127,7 @@ void aty_init_engine(struct atyfb_par *p
> >
> > /* set host attributes */
> > wait_for_fifo(13, par);
> > - aty_st_le32(HOST_CNTL, 0, par);
> > + aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
> >
> > /* set pattern attributes */
> > aty_st_le32(PAT_REG0, 0, par);
> > @@ -233,7 +233,8 @@ void atyfb_copyarea(struct fb_info *info
> > rotation = rotation24bpp(dx, direction);
> > }
> >
> > - wait_for_fifo(4, par);
> > + wait_for_fifo(5, par);
> > + aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
> > aty_st_le32(DP_SRC, FRGD_SRC_BLIT, par);
> > aty_st_le32(SRC_Y_X, (sx << 16) | sy, par);
> > aty_st_le32(SRC_HEIGHT1_WIDTH1, (width << 16) | area->height, par);
> > @@ -269,7 +270,8 @@ void atyfb_fillrect(struct fb_info *info
> > rotation = rotation24bpp(dx, DST_X_LEFT_TO_RIGHT);
> > }
> >
> > - wait_for_fifo(3, par);
> > + wait_for_fifo(4, par);
> > + aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
> > aty_st_le32(DP_FRGD_CLR, color, par);
> > aty_st_le32(DP_SRC,
> > BKGD_SRC_BKGD_CLR | FRGD_SRC_FRGD_CLR | MONO_SRC_ONE,
> > @@ -284,7 +286,7 @@ void atyfb_imageblit(struct fb_info *inf
> > {
> > struct atyfb_par *par = (struct atyfb_par *) info->par;
> > u32 src_bytes, dx = image->dx, dy = image->dy, width = image->width;
> > - u32 pix_width_save, pix_width, host_cntl, rotation = 0, src, mix;
> > + u32 pix_width, rotation = 0, src, mix;
> >
> > if (par->asleep)
> > return;
> > @@ -296,8 +298,7 @@ void atyfb_imageblit(struct fb_info *inf
> > return;
> > }
> >
> > - pix_width = pix_width_save = aty_ld_le32(DP_PIX_WIDTH, par);
> > - host_cntl = aty_ld_le32(HOST_CNTL, par) | HOST_BYTE_ALIGN;
> > + pix_width = par->crtc.dp_pix_width;
> >
> > switch (image->depth) {
> > case 1:
> > @@ -370,12 +371,11 @@ void atyfb_imageblit(struct fb_info *inf
> > mix = FRGD_MIX_D_XOR_S | BKGD_MIX_D;
> > }
> >
> > - wait_for_fifo(6, par);
> > - aty_st_le32(DP_WRITE_MASK, 0x, par);
>
> Looks like init_engine() sets this one for us. So dropping should be ok.
>
> > + wait_for_fifo(5, par);
> > aty_st_le32(DP_PIX_WIDTH, pix_width, par);
> > aty_st_le32(DP_MIX, mix, par);
> > aty_st_le32(DP_SRC, src, par);
> > - aty_st_le32(HOST_CNTL, host_cntl, par);
> > + aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
>
> Presumably we could drop this as well since it never changes.
I tried to drop this HOST_CNTL write and it didn't work. It seems that the
register is written implicitly by some of the other commands.
Mikulas
> Either way
> Reviewed-by: Ville Syrjälä
>
> > aty_st_le32(DST_CNTL, DST_Y_TOP_TO_BOTTOM | DST_X_LEFT_TO_RIGHT |
> > rotation, par);
> >
> > draw_rect(dx, dy, width, image->height, par);
> > @@ -424,8 +424,4 @@ void atyfb_imageblit(struct fb_info *inf
> > aty_st_le32(HOST_DATA0, get_unaligned_le32(pbitmap),
> > par);
> > }
> > }
> > -
> > - /* restore pix_width */
> > - wait_for_fifo(1, par);
> > - aty_st_le32(DP_PIX_WIDTH, pix_width_save, par);
> > }
>
> --
> Ville Syrjälä
> syrj...@sci.fi
> http://www.sci.fi/~syrjala/
> ___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #6 from Claude Heiland-Allen (cla...@mathr.co.uk) --- still an issue with 4.18.5 still an issue with 4.19-rc1, I will attach dmesg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> When doing suspend/resume drivers usually use the
> drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> state and then re-comitting it.
>
> The problem is that drm_crtc_state has a bool field called
> color_mgmt_changed, which mali-dp and other drivers uses it to detect
> if coefficients need to be reprogrammed, but that never happens
> because the saved state has color_mgmt_changed set to 0.
>
> Fix that by setting color_mgmt_changed to true in
> drm_atomic_helper_check_modeset when at least one of gamma_lut,
> degamma_lut, ctm is different between the new and the old crtc state.
>
> Also, this makes unnecessary the setting of color_mgmt_changed in
> places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
Do all current drivers actually call drm_atomic_helper_check_modeset()
for every commit?
>
> Changes since v2:
> - Instead of setting color_mgmt_changed in commit_duplicated_set
> just set it in check_modeset and clean up other place where it was
> set, suggested by Maarten Lankhorst.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_atomic.c| 12 +++-
> drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> drivers/gpu/drm/drm_fb_helper.c | 1 -
> 3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d0478abc01bd..9bcada3c299e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> drm_property_blob_put(mode);
> return ret;
> } else if (property == config->degamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + return drm_atomic_replace_property_blob_from_id(dev,
> &state->degamma_lut,
> val,
> -1, sizeof(struct drm_color_lut),
> &replaced);
> - state->color_mgmt_changed |= replaced;
> - return ret;
> } else if (property == config->ctm_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + return drm_atomic_replace_property_blob_from_id(dev,
> &state->ctm,
> val,
> sizeof(struct drm_color_ctm), -1,
> &replaced);
> - state->color_mgmt_changed |= replaced;
> - return ret;
> } else if (property == config->gamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + return drm_atomic_replace_property_blob_from_id(dev,
> &state->gamma_lut,
> val,
> -1, sizeof(struct drm_color_lut),
> &replaced);
> - state->color_mgmt_changed |= replaced;
> - return ret;
> } else if (property == config->prop_out_fence_ptr) {
> s32 __user *fence_ptr = u64_to_user_ptr(val);
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2c23a48482da..fe22e1ad468a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>
> return -EINVAL;
> }
> + if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> ||
> + new_crtc_state->ctm != old_crtc_state->ctm ||
> + new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> changed\n",
> + crtc->base.id, crtc->name);
> + new_crtc_state->color_mgmt_changed = true;
> + }
> }
>
> ret = handle_conflicting_encoders(state, false);
> @@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> - crtc_state->color_mgmt_changed |= replaced;
>
> ret = drm_atomic_commit(state);
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4b0dd20bccb8..8541e95a5410 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1442,7 +1442,6 @@ static int setcmap_atomic(struct fb_cmap *cmap, struct
> fb_info *info)
>
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #7 from Claude Heiland-Allen (cla...@mathr.co.uk) --- Created attachment 278167 --> https://bugzilla.kernel.org/attachment.cgi?id=278167&action=edit dmesg for 4.19-rc1 amdgpu.dc=1 amdgpu.dc_log=1 drm.debug=6 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
Hi Alex,
On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problem is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the saved state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true in
drm_atomic_helper_check_modeset when at least one of gamma_lut,
degamma_lut, ctm is different between the new and the old crtc state.
Also, this makes unnecessary the setting of color_mgmt_changed in
places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
Changes since v2:
- Instead of setting color_mgmt_changed in commit_duplicated_set
just set it in check_modeset and clean up other place where it was
set, suggested by Maarten Lankhorst.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_atomic.c| 12 +++-
drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
drivers/gpu/drm/drm_fb_helper.c | 1 -
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d0478abc01bd..9bcada3c299e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->degamma_lut,
val,
-1, sizeof(struct drm_color_lut),
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->ctm_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->ctm,
val,
sizeof(struct drm_color_ctm), -1,
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->gamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
val,
-1, sizeof(struct drm_color_lut),
&replaced);
- state->color_mgmt_changed |= replaced;
- return ret;
Looks like 'replaced' is now unused, so you can remove it.
Cheers,
-Brian
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2c23a48482da..fe22e1ad468a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return -EINVAL;
}
+ if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
||
+ new_crtc_state->ctm != old_crtc_state->ctm ||
+ new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
changed\n",
+crtc->base.id, crtc->name);
+ new_crtc_state->color_mgmt_changed = true;
+ }
}
ret = handle_conflicting_encoders(state, false);
@@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
- crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4b0dd20bccb8..8541e95a5410 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1442,7 +1442,6 @@ static int setcmap_atomic(struct fb_cmap *cmap, struct
fb_info *info)
replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
replaced |= drm_property_r
[Bug 107689] System freezes on shutdown. [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=107689 --- Comment #4 from Andrey Grodzovsky --- Created attachment 141310 --> https://bugs.freedesktop.org/attachment.cgi?id=141310&action=edit 0001-drm-amdgpu-Only-retrieve-GPU-address-of-GART-table-a.patch Please try with our latest kernel from here https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next + the attached patch on top. Also just to be sure try to use latest firmware for amdgpu from here https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu P.S Don't forget to update your initramfs after you copy the firmware files to your /lib/firmware/XXX locatiotion -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 06:46:07PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> > When doing suspend/resume drivers usually use the
> > drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> > state and then re-comitting it.
> >
> > The problem is that drm_crtc_state has a bool field called
> > color_mgmt_changed, which mali-dp and other drivers uses it to detect
> > if coefficients need to be reprogrammed, but that never happens
> > because the saved state has color_mgmt_changed set to 0.
> >
> > Fix that by setting color_mgmt_changed to true in
> > drm_atomic_helper_check_modeset when at least one of gamma_lut,
> > degamma_lut, ctm is different between the new and the old crtc state.
> >
> > Also, this makes unnecessary the setting of color_mgmt_changed in
> > places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
>
> Do all current drivers actually call drm_atomic_helper_check_modeset()
> for every commit?
Yes, all drivers that use color_mgmt_changed either call directly
drm_atomic_helper_check_modeset or they use drm_atomic_helper_check
which calls drm_atomic_helper_check_modeset.
>
> >
> > Changes since v2:
> > - Instead of setting color_mgmt_changed in commit_duplicated_set
> > just set it in check_modeset and clean up other place where it was
> > set, suggested by Maarten Lankhorst.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c| 12 +++-
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> > drivers/gpu/drm/drm_fb_helper.c | 1 -
> > 3 files changed, 10 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index d0478abc01bd..9bcada3c299e 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > drm_property_blob_put(mode);
> > return ret;
> > } else if (property == config->degamma_lut_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->ctm_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->ctm,
> > val,
> > sizeof(struct drm_color_ctm), -1,
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->gamma_lut_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->gamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->prop_out_fence_ptr) {
> > s32 __user *fence_ptr = u64_to_user_ptr(val);
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 2c23a48482da..fe22e1ad468a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >
> > return -EINVAL;
> > }
> > + if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> > ||
> > + new_crtc_state->ctm != old_crtc_state->ctm ||
> > + new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> > + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> > changed\n",
> > +crtc->base.id, crtc->name);
> > + new_crtc_state->color_mgmt_changed = true;
> > + }
> > }
> >
> > ret = handle_conflicting_encoders(state, false);
> > @@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> > - crtc_state->color_mgmt_changed |= replaced
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 04:48:45PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> >When doing suspend/resume drivers usually use the
> >drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> >state and then re-comitting it.
> >
> >The problem is that drm_crtc_state has a bool field called
> >color_mgmt_changed, which mali-dp and other drivers uses it to detect
> >if coefficients need to be reprogrammed, but that never happens
> >because the saved state has color_mgmt_changed set to 0.
> >
> >Fix that by setting color_mgmt_changed to true in
> >drm_atomic_helper_check_modeset when at least one of gamma_lut,
> >degamma_lut, ctm is different between the new and the old crtc state.
> >
> >Also, this makes unnecessary the setting of color_mgmt_changed in
> >places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
> >
> >Changes since v2:
> > - Instead of setting color_mgmt_changed in commit_duplicated_set
> > just set it in check_modeset and clean up other place where it was
> > set, suggested by Maarten Lankhorst.
> >
> >Signed-off-by: Alexandru Gheorghe
> >---
> >drivers/gpu/drm/drm_atomic.c| 12 +++-
> >drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> >drivers/gpu/drm/drm_fb_helper.c | 1 -
> >3 files changed, 10 insertions(+), 11 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >index d0478abc01bd..9bcada3c299e 100644
> >--- a/drivers/gpu/drm/drm_atomic.c
> >+++ b/drivers/gpu/drm/drm_atomic.c
> >@@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > drm_property_blob_put(mode);
> > return ret;
> > } else if (property == config->degamma_lut_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
> > } else if (property == config->ctm_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->ctm,
> > val,
> > sizeof(struct drm_color_ctm), -1,
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
> > } else if (property == config->gamma_lut_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->gamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
>
> Looks like 'replaced' is now unused, so you can remove it.
It's needed as an argument for
drm_atomic_replace_property_blob_from_id, and the prototype of the
function makes sense to me.
>
> Cheers,
> -Brian
>
> > } else if (property == config->prop_out_fence_ptr) {
> > s32 __user *fence_ptr = u64_to_user_ptr(val);
> >
> >diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >b/drivers/gpu/drm/drm_atomic_helper.c
> >index 2c23a48482da..fe22e1ad468a 100644
> >--- a/drivers/gpu/drm/drm_atomic_helper.c
> >+++ b/drivers/gpu/drm/drm_atomic_helper.c
> >@@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >
> > return -EINVAL;
> > }
> >+if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> >||
> >+new_crtc_state->ctm != old_crtc_state->ctm ||
> >+new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> >+DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> >changed\n",
> >+ crtc->base.id, crtc->name);
> >+new_crtc_state->color_mgmt_changed = true;
> >+}
> > }
> >
> > ret = handle_conflicting_encoders(state, false);
> >@@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> >*crtc,
> > replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> >-crtc_state->color_mgmt_changed |= replaced;
> >
> > ret = drm_atomic_commit(state);
> >
> >diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >b/driver
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 05:08:51PM +0100, Alexandru-Cosmin Gheorghe wrote:
On Tue, Aug 28, 2018 at 04:48:45PM +0100, Brian Starkey wrote:
Hi Alex,
On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
>When doing suspend/resume drivers usually use the
>drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
>state and then re-comitting it.
>
>The problem is that drm_crtc_state has a bool field called
>color_mgmt_changed, which mali-dp and other drivers uses it to detect
>if coefficients need to be reprogrammed, but that never happens
>because the saved state has color_mgmt_changed set to 0.
>
>Fix that by setting color_mgmt_changed to true in
>drm_atomic_helper_check_modeset when at least one of gamma_lut,
>degamma_lut, ctm is different between the new and the old crtc state.
>
>Also, this makes unnecessary the setting of color_mgmt_changed in
>places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
>
>Changes since v2:
> - Instead of setting color_mgmt_changed in commit_duplicated_set
> just set it in check_modeset and clean up other place where it was
> set, suggested by Maarten Lankhorst.
>
>Signed-off-by: Alexandru Gheorghe
>---
>drivers/gpu/drm/drm_atomic.c| 12 +++-
>drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
>drivers/gpu/drm/drm_fb_helper.c | 1 -
>3 files changed, 10 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index d0478abc01bd..9bcada3c299e 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>drm_property_blob_put(mode);
>return ret;
>} else if (property == config->degamma_lut_property) {
>- ret = drm_atomic_replace_property_blob_from_id(dev,
>+ return drm_atomic_replace_property_blob_from_id(dev,
>&state->degamma_lut,
>val,
>-1, sizeof(struct drm_color_lut),
>&replaced);
>- state->color_mgmt_changed |= replaced;
>- return ret;
>} else if (property == config->ctm_property) {
>- ret = drm_atomic_replace_property_blob_from_id(dev,
>+ return drm_atomic_replace_property_blob_from_id(dev,
>&state->ctm,
>val,
>sizeof(struct drm_color_ctm), -1,
>&replaced);
>- state->color_mgmt_changed |= replaced;
>- return ret;
>} else if (property == config->gamma_lut_property) {
>- ret = drm_atomic_replace_property_blob_from_id(dev,
>+ return drm_atomic_replace_property_blob_from_id(dev,
>&state->gamma_lut,
>val,
>-1, sizeof(struct drm_color_lut),
>&replaced);
>- state->color_mgmt_changed |= replaced;
>- return ret;
Looks like 'replaced' is now unused, so you can remove it.
It's needed as an argument for
drm_atomic_replace_property_blob_from_id, and the prototype of the
function makes sense to me.
Silly me, I thought drm_atomic_replace_property_blob_from_id would
check it against NULL and skip, but I see it doesn't, and that'll
teach me to not trust my memory :-)
Sorry for the noise,
-Brian
Cheers,
-Brian
>} else if (property == config->prop_out_fence_ptr) {
>s32 __user *fence_ptr = u64_to_user_ptr(val);
>
>diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
>index 2c23a48482da..fe22e1ad468a 100644
>--- a/drivers/gpu/drm/drm_atomic_helper.c
>+++ b/drivers/gpu/drm/drm_atomic_helper.c
>@@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>
>return -EINVAL;
>}
>+ if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut ||
>+ new_crtc_state->ctm != old_crtc_state->ctm ||
>+ new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
>+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management changed\n",
>+crtc->base.id, crtc->name);
>+ new_crtc_state->color_mgmt_changed = true;
>+ }
>}
>
>ret = handle_conflicting_encoders(state, false);
>@@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
>replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
>replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
>replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
>- crtc_state->color_mgmt_changed |= replaced;
>
>ret = drm_atomic_commit(state);
>
>diff --git a/drivers/gpu/drm/drm_fb_he
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Tue, Aug 28, 2018 at 09:38:59AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-28 02:00:27)
> > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> > > Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > > > index 4a34b7be..8a0e3e76 100644
> > > > --- a/intel/intel_chipset.h
> > > > +++ b/intel/intel_chipset.h
> > > > @@ -568,6 +568,26 @@
> > > >
> > > > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> > > >
> > > > +/* New platforms use kernel pci ids */
> > > > +#include "i915_pciids.h"
> > > > +
> > > > +struct pci_device_id {
> > >
> > > Don't call it pci_device_id, depending on caller that name may already
> > > be taken by libpciaccess.
> > >
> > > > + uint32_t unused0, device;
> > > > + uint32_t unused1, unused2;
> > > > + uint32_t unused3, unused4;
> > > These are all uint16_t.
> >
> > more on this:
> >
> > I can make the first 2 uint16_t, but not the rest due to the way they
> > are declared in INTEL_VGA_DEVICE: (~0 has int type by default), unused3
> > and unused4 are clearly not uint16_t
>
> I had it in my mind that we did have one extra level of macro in there
> that would allow us to drop unused fields. We could redef
we don't have right now, that needs to be added. And for any extra level
of macro we need to redef INTEL_VGA_DEVICE nonetheless because it
expands to "{ ... }". I don't know any cpp trick to remove the extra
fields if it keeps the braces.
> INTEL_VGA_DEVICE() and INTEL_QUANTA_VGA_DEVICE() but one extra level of
> macro would be easier for future.
So... I don't see a way out except to redef it. This works today for
libdrm (on top of my unsent version of this patch):
[ NO CI ] diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
[ NO CI ] index 79581819..8ea24194 100644
[ NO CI ] --- a/intel/intel_chipset.c
[ NO CI ] +++ b/intel/intel_chipset.c
@@ -27,11 +27,12 @@
#include "i915_pciids.h"
+#undef INTEL_VGA_DEVICE
+#define INTEL_VGA_DEVICE(id, gen) { id, gen }
+
static const struct pci_device {
- uint16_t unused0, device;
- uint32_t unused1, unused2;
- uint32_t unused3, unused4;
- int gen;
+ uint16_t device;
+ uint16_t gen;
} pciids[] = {
INTEL_ICL_11_IDS(11),
INTEL_CNL_IDS(10),
>
> And then while you are there, add the missing 'u' to ~0u
> -Chris.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 --- Comment #5 from Andrey Grodzovsky --- Your kernel is a bit old, please try a later kernel - 4.18 for example to see if you still experience this sort of problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 04:58:42PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Tue, Aug 28, 2018 at 06:46:07PM +0300, Ville Syrjälä wrote:
> > On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> > > When doing suspend/resume drivers usually use the
> > > drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> > > state and then re-comitting it.
> > >
> > > The problem is that drm_crtc_state has a bool field called
> > > color_mgmt_changed, which mali-dp and other drivers uses it to detect
> > > if coefficients need to be reprogrammed, but that never happens
> > > because the saved state has color_mgmt_changed set to 0.
> > >
> > > Fix that by setting color_mgmt_changed to true in
> > > drm_atomic_helper_check_modeset when at least one of gamma_lut,
> > > degamma_lut, ctm is different between the new and the old crtc state.
> > >
> > > Also, this makes unnecessary the setting of color_mgmt_changed in
> > > places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
> >
> > Do all current drivers actually call drm_atomic_helper_check_modeset()
> > for every commit?
>
> Yes, all drivers that use color_mgmt_changed either call directly
> drm_atomic_helper_check_modeset or they use drm_atomic_helper_check
> which calls drm_atomic_helper_check_modeset.
Awesome.
Reviewed-by: Ville Syrjälä
>
> >
> > >
> > > Changes since v2:
> > > - Instead of setting color_mgmt_changed in commit_duplicated_set
> > > just set it in check_modeset and clean up other place where it was
> > > set, suggested by Maarten Lankhorst.
> > >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > drivers/gpu/drm/drm_atomic.c| 12 +++-
> > > drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> > > drivers/gpu/drm/drm_fb_helper.c | 1 -
> > > 3 files changed, 10 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index d0478abc01bd..9bcada3c299e 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc
> > > *crtc,
> > > drm_property_blob_put(mode);
> > > return ret;
> > > } else if (property == config->degamma_lut_property) {
> > > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > > + return drm_atomic_replace_property_blob_from_id(dev,
> > > &state->degamma_lut,
> > > val,
> > > -1, sizeof(struct drm_color_lut),
> > > &replaced);
> > > - state->color_mgmt_changed |= replaced;
> > > - return ret;
> > > } else if (property == config->ctm_property) {
> > > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > > + return drm_atomic_replace_property_blob_from_id(dev,
> > > &state->ctm,
> > > val,
> > > sizeof(struct drm_color_ctm), -1,
> > > &replaced);
> > > - state->color_mgmt_changed |= replaced;
> > > - return ret;
> > > } else if (property == config->gamma_lut_property) {
> > > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > > + return drm_atomic_replace_property_blob_from_id(dev,
> > > &state->gamma_lut,
> > > val,
> > > -1, sizeof(struct drm_color_lut),
> > > &replaced);
> > > - state->color_mgmt_changed |= replaced;
> > > - return ret;
> > > } else if (property == config->prop_out_fence_ptr) {
> > > s32 __user *fence_ptr = u64_to_user_ptr(val);
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 2c23a48482da..fe22e1ad468a 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device
> > > *dev,
> > >
> > > return -EINVAL;
> > > }
> > > + if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> > > ||
> > > + new_crtc_state->ctm != old_crtc_state->ctm ||
> > > + new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> > > + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> > > changed\n",
> > > + crtc->base.id, crtc->name);
> > > + new_crtc_state->color_mgmt_changed = true;
> > > + }
> > > }
> > >
> > > ret = handle_conflicting_encoders(state, false);
> > > @@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > > drm_crtc *crtc,
> > > replaced = drm_property_replac
[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930
https://bugs.freedesktop.org/show_bug.cgi?id=105760 --- Comment #57 from taij...@posteo.de --- Just to reconfirm: This bug is fixed for me as original reporter in the 4.18.y release. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107045] [4.18rc2] RX470 dGPU on hybrid laptop freezes screen after use
https://bugs.freedesktop.org/show_bug.cgi?id=107045 --- Comment #20 from taij...@posteo.de --- OK, here is a new twist: upon further investigating this, I came across some weird backlight behaviour that I originally reported here: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/53. However, as it turns out, this is not a gnome issue but a kernel one. Namely, doing echo X > /sys/class/backlight/intel_backlight/brightness will wake my dGPU, even though it really shouldn't be involved at all (and does not have a /sys/class/backlight device registered). Furthermore, repeatedly invoking this command before the dGPU has had the chance to go back to sleep will not do anything. Thirdly, this seems to be a very good way to get the system to hard lock up. So, is this an amdgpu issue? A i915 issue? ACPI? where should I take this bug report? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 --- Comment #2 from Andrey Grodzovsky --- >From looking into the log seems your system was out of memory in the time of calling suspend. I see a few user mode apps like steam crashing before that, coudl be related. That in turn caused GPU buffers eviction failure during suspend and hence failures after resume. See if you can check your memory status before suspending, try to figure out when memory exhausting problem starts, what use case. Use commands from here to check memory status - https://www.binarytides.com/linux-command-check-memory-usage/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Initialize local lists in ttm_bo_bulk_move_helper
From: Michel Dänzer
The first parameter of list_cut_position() must point to an initialized
list.
Noticed thanks to KASAN pointing out something's fishy here.
Fixes: "drm/ttm: add bulk move function on LRU"
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 39d9d559b279..35d53d81f486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -250,7 +250,8 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
struct list_head *lru, bool is_swap)
{
- struct list_head entries, before;
+ LIST_HEAD(entries);
+ LIST_HEAD(before);
struct list_head *list1, *list2;
list1 = is_swap ? &pos->last->swap : &pos->last->lru;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930
https://bugs.freedesktop.org/show_bug.cgi?id=105760 Michel Dänzer changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #58 from Michel Dänzer --- Resolving per comment 57. Anyone still having issues with current kernels, please file your own report. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init()
There's no actual reason we pass the connector ID instead of a pointer
to the connector itself, and we're going to need the entire connector
(but only temporarily) in order to name MST debugfs folders properly
since connector IDs can't be looked up until the driver has been
registered with userspace which happens after debugfs init.
So, just pass the entire drm_connector struct instead of just its id.
Signed-off-by: Lyude Paul
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
drivers/gpu/drm/i915/intel_dp.c| 2 +-
drivers/gpu/drm/i915/intel_dp_mst.c| 6 --
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c| 6 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
include/drm/drm_dp_mst_helper.h| 3 ++-
8 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9a300732ba37..60da7e8fcca7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -503,6 +503,6 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
&aconnector->dm_dp_aux.aux,
16,
4,
- aconnector->connector_id);
+ &aconnector->base);
}
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..acb7633f3f70 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3161,14 +3161,16 @@ EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
* @aux: DP helper aux channel to talk to this device
* @max_dpcd_transaction_bytes: hw specific DPCD transaction limit
* @max_payloads: maximum number of payloads this GPU can source
- * @conn_base_id: the connector object ID the MST device is connected to.
+ * @connector: the &struct drm_connector the MST device is connected to.
*
* Return 0 for success, or negative error code on failure
*/
int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_device *dev, struct drm_dp_aux *aux,
+struct drm_device *dev,
+struct drm_dp_aux *aux,
int max_dpcd_transaction_bytes,
-int max_payloads, int conn_base_id)
+int max_payloads,
+struct drm_connector *connector)
{
struct drm_dp_mst_topology_state *mst_state;
@@ -3186,7 +3188,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
mgr->aux = aux;
mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
mgr->max_payloads = max_payloads;
- mgr->conn_base_id = conn_base_id;
+ mgr->conn_base_id = connector->base.id;
if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cd0f649b57a5..3688df38dbe7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6247,7 +6247,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
(port == PORT_B || port == PORT_C ||
port == PORT_D || port == PORT_F))
intel_dp_mst_encoder_init(intel_dig_port,
- intel_connector->base.base.id);
+ &intel_connector->base);
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
intel_dp_aux_fini(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 7e3e01607643..6c07c29235df 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -583,7 +583,8 @@ intel_dp_create_fake_mst_encoders(struct intel_digital_port
*intel_dig_port)
}
int
-intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_base_id)
+intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port,
+ struct drm_connector *connector)
{
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -595,7 +596,8 @@ intel_dp_mst_encoder_init(struct intel_digital_port
*intel_dig_port, int conn_ba
/* create encoders */
intel_dp_create_fake_mst_encoders(intel_dig_port);
ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, dev,
-
[PATCH v2 1/4] drm/debugfs: Add support for dynamic debugfs initialization
Currently all debugfs related initialization for the DRM core happens in
drm_debugfs_init(), which is called when registering the minor device.
While this works fine for features such as atomic modesetting and GEM,
this doesn't work at all for resources like DP MST topology managers
which can potentially be created both before and after the minor
device has been registered.
So, in order to add driver-wide debugfs files for MST we'll need to be
able to handle debugfs initialization for such resources. We do so by
introducing drm_debugfs_callback_register() and
drm_debugfs_callback_unregister(). These functions allow driver-agnostic
parts of DRM to add additional debugfs initialization callbacks at any
point during a DRM driver's lifetime.
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/drm_debugfs.c | 173 +++--
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_internal.h | 5 +
include/drm/drm_debugfs.h | 27 +
include/drm/drm_file.h | 4 +
5 files changed, 203 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 6f28fe58f169..a53a454b167f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -39,6 +39,13 @@
#if defined(CONFIG_DEBUG_FS)
+struct drm_debugfs_callback {
+ void (*init)(void *data);
+ void (*cleanup_cb)(void *data);
+ void *data;
+ struct list_head list;
+};
+
/***
* Initialization, etc.
**/
@@ -67,6 +74,113 @@ static const struct file_operations drm_debugfs_fops = {
.release = single_release,
};
+/**
+ * drm_debugfs_register_callback - Register a callback for initializing
+ * dynamic driver-agnostic debugfs files
+ * @minor: device minor number
+ * @init: The callback to invoke to perform the debugfs initialization
+ * @cleanup_cb: The callback to invoke to cleanup any resources for the
+ * callback
+ * @data: Data to pass to @init and @cleanup_cb
+ * @out: Where to store the pointer to the callback struct
+ *
+ * Register an initialization callback with debugfs. This callback can be used
+ * to creating debugfs nodes for DRM resources that might get created before
+ * the debugfs node for @minor has been created.
+ *
+ * When a callback is registered with this function before the debugfs root
+ * has been created, the callback's execution will be delayed until all other
+ * debugfs nodes (including those owned by the DRM device's driver) have been
+ * instantiated. If a callback is registered with this function after the
+ * debugfs root has been created, @init and @cleanup_cb will be executed
+ * immediately without creating a &struct drm_debugfs_callback.
+ *
+ * In the event that debugfs creation for the device fails; all registered
+ * debugfs callbacks will have their @cleanup_cb callbacks invoked without
+ * having their @init callbacks invoked. This is to ensure that no resources
+ * are leaked during initialization of debugfs, even if the initialization
+ * process fails. Likewise; any callbacks that are registered after DRM has
+ * failed to initialize it's debugfs files will have their @cleanup_cb
+ * callbacks invoked immediately and all of their respective resources
+ * destroyed.
+ *
+ * Implementations of @cleanup_cb should clean up all resources for the
+ * callback, with the exception of freeing the memory for @out. Freeing @out
+ * will be handled by the DRM core automatically.
+ *
+ * Users of this function should take care to add a symmetric call to
+ * @drm_debugfs_unregister_callback to handle destroying a registered callback
+ * in case the resources for the user of this function are destroyed before
+ * debugfs root is initialized.
+ *
+ */
+int
+drm_debugfs_register_callback(struct drm_minor *minor,
+ void (*init)(void *),
+ void (*cleanup_cb)(void *),
+ void *data, struct drm_debugfs_callback **out)
+{
+ int ret = 0;
+
+ mutex_lock(&minor->debugfs_callback_lock);
+ if (minor->debugfs_callbacks_done) {
+ /* debugfs is already setup, so just handle the callback
+* immediately
+*/
+ if (minor->debugfs_root)
+ (*init)(data);
+ (*cleanup_cb)(data);
+ goto out_unlock;
+ }
+
+ *out = kzalloc(sizeof(**out), GFP_KERNEL);
+ if (!*out) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ (*out)->init = init;
+ (*out)->cleanup_cb = cleanup_cb;
+ (*out)->data = data;
+ list_add(&(*out)->list, &minor->debugfs_callback_list);
+
+out_unlock:
+ mutex_unlock(&minor->debugfs_callback_lock);
+ return ret;
+}
+EXPORT_SYMBOL(drm_debugfs_register
[PATCH v2 0/4] drm/dp_mst: Add DP MST debugfs nodes for all drivers
This is the next version of my patch series for teaching DRM how to automatically create debugfs nodes for drivers with MST topologies. This was originally intended just for nouveau, but has since been expanded to all DRM drivers. Changes since previous version: - Fix documentation error that got noticed by the kbuild bot in "drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init()" Cc: Maarten Lankhorst Cc: Daniel Stone Lyude Paul (4): drm/debugfs: Add support for dynamic debugfs initialization drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init() drm/dp_mst: Add dp_mst_status debugfs node for all drivers drm/i915: Remove i915_drm_dp_mst_status .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 173 +- drivers/gpu/drm/drm_dp_mst_topology.c | 116 +++- drivers/gpu/drm/drm_drv.c | 3 + drivers/gpu/drm/drm_internal.h| 5 + drivers/gpu/drm/i915/i915_debugfs.c | 32 drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_dp_mst.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +- drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +- include/drm/drm_debugfs.h | 27 +++ include/drm/drm_dp_mst_helper.h | 17 +- include/drm/drm_file.h| 4 + 14 files changed, 343 insertions(+), 55 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/dp_mst: Add dp_mst_status debugfs node for all drivers
Originally I was just going to be adding dp_mst_status for nouveau until
Daniel Stone pointed out that we should probably just make this so it's
magically added for every DRM driver that's using the DRM DP MST
helpers. So, let's do that!
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/drm_dp_mst_topology.c | 106 ++
include/drm/drm_dp_mst_helper.h | 14
2 files changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index acb7633f3f70..a6a2c03af62a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3154,6 +3155,104 @@ struct drm_dp_mst_topology_state
*drm_atomic_get_mst_topology_state(struct drm_a
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+#ifdef CONFIG_DEBUG_FS
+static int drm_dp_mst_debugfs_state_show(struct seq_file *m, void *data)
+{
+ drm_dp_mst_dump_topology(m, m->private);
+ return 0;
+}
+
+static int drm_dp_mst_debugfs_state_open(struct inode *inode,
+struct file *file)
+{
+ struct drm_dp_mst_topology_mgr *mgr = inode->i_private;
+
+ return single_open(file, drm_dp_mst_debugfs_state_show, mgr);
+}
+
+static const struct file_operations drm_dp_mst_debugfs_state_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_dp_mst_debugfs_state_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+struct drm_dp_mst_debugfs_init_data {
+ struct drm_dp_mst_topology_mgr *mgr;
+ char *connector_name;
+};
+
+static void
+drm_dp_mst_debugfs_init(void *data)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data = data;
+ struct drm_dp_mst_topology_mgr *mgr = init_data->mgr;
+ struct drm_minor *minor = mgr->dev->primary;
+ struct dentry *root;
+ bool put_ref = false;
+
+ /* Create the dp_mst directory for this device if it doesn't exist
+* already
+*/
+ root = debugfs_lookup("dp_mst", minor->debugfs_root);
+ if (root) {
+ put_ref = true;
+ } else {
+ root = debugfs_create_dir("dp_mst", minor->debugfs_root);
+ if (!root || IS_ERR(root))
+ return;
+ }
+
+ mgr->debugfs = debugfs_create_dir(init_data->connector_name, root);
+ if (!mgr->debugfs)
+ goto out_dput;
+
+ debugfs_create_file("state", 0444, mgr->debugfs, mgr,
+ &drm_dp_mst_debugfs_state_fops);
+
+out_dput:
+ if (put_ref)
+ dput(root);
+}
+
+static void
+drm_dp_mst_debugfs_cleanup_cb(void *data)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data = data;
+
+ init_data->mgr->debugfs_init_cb = NULL;
+ kfree(init_data->connector_name);
+ kfree(init_data);
+}
+
+static void
+drm_dp_mst_debugfs_register(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_connector *connector)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data;
+
+ if (!connector)
+ return;
+
+ init_data = kmalloc(sizeof(*init_data), GFP_KERNEL);
+ if (!init_data)
+ return;
+
+ init_data->mgr = mgr;
+ init_data->connector_name = kstrdup(connector->name, GFP_KERNEL);
+ if (!init_data->connector_name) {
+ kfree(init_data);
+ return;
+ }
+
+ drm_debugfs_register_callback(mgr->dev->primary,
+ drm_dp_mst_debugfs_init,
+ drm_dp_mst_debugfs_cleanup_cb,
+ init_data, &mgr->debugfs_init_cb);
+}
+#endif
+
/**
* drm_dp_mst_topology_mgr_init - initialise a topology manager
* @mgr: manager struct to initialise
@@ -3214,6 +3313,9 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(&mgr->base,
&mst_state->base,
&mst_state_funcs);
+#ifdef CONFIG_DEBUG_FS
+ drm_dp_mst_debugfs_register(mgr, connector);
+#endif
return 0;
}
@@ -3225,6 +3327,10 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
*/
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr)
{
+#ifdef CONFIG_DEBUG_FS
+ drm_debugfs_unregister_callback(mgr->dev->primary,
+ mgr->debugfs_init_cb);
+#endif
flush_work(&mgr->work);
flush_work(&mgr->destroy_connector_work);
mutex_lock(&mgr->payload_lock);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index ef8ba093ae8a..c70b81cd78b1 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -25,6 +25,7 @@
#include
#include
#include
+#i
[PATCH v2 4/4] drm/i915: Remove i915_drm_dp_mst_status
Now that DRM can create these debugfs nodes automatically; this isn't
needed.
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 -
1 file changed, 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f9ce35da4123..5014828ca022 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3534,37 +3534,6 @@ static int i915_drrs_status(struct seq_file *m, void
*unused)
return 0;
}
-static int i915_dp_mst_info(struct seq_file *m, void *unused)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = &dev_priv->drm;
- struct intel_encoder *intel_encoder;
- struct intel_digital_port *intel_dig_port;
- struct drm_connector *connector;
- struct drm_connector_list_iter conn_iter;
-
- drm_connector_list_iter_begin(dev, &conn_iter);
- drm_for_each_connector_iter(connector, &conn_iter) {
- if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort)
- continue;
-
- intel_encoder = intel_attached_encoder(connector);
- if (!intel_encoder || intel_encoder->type ==
INTEL_OUTPUT_DP_MST)
- continue;
-
- intel_dig_port = enc_to_dig_port(&intel_encoder->base);
- if (!intel_dig_port->dp.can_mst)
- continue;
-
- seq_printf(m, "MST Source Port %c\n",
- port_name(intel_dig_port->base.port));
- drm_dp_mst_dump_topology(m, &intel_dig_port->dp.mst_mgr);
- }
- drm_connector_list_iter_end(&conn_iter);
-
- return 0;
-}
-
static ssize_t i915_displayport_test_active_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
@@ -4733,7 +4702,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
- {"i915_dp_mst_info", i915_dp_mst_info, 0},
{"i915_wa_registers", i915_wa_registers, 0},
{"i915_ddb_info", i915_ddb_info, 0},
{"i915_sseu_status", i915_sseu_status, 0},
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 640/655] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:480: warning: Function parameter or member 'level' not described in 'amdgpu_vm_bo_param'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 30c3f838bd24ea52f6d3ebb44996340e4d98890d commit: 7b7d78f626410923ce18ba9a183048dc8ca7db41 [640/655] drm/amdgpu: add helper for VM PD/PT allocation parameters v2 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) mm/mempool.c:228: warning: Function parameter or member 'pool' not described in 'mempool_init' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4279: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/mac80211.h:2282: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw' include/net/mac80211.h:2282: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw' include/net/mac80211.h:955: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' net/mac80
Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge
On Tue, Aug 28, 2018 at 07:49:28PM +0200, Peter Rosin wrote: > On 2018-07-06 14:43, Russell King - ARM Linux wrote: > > On Fri, Jul 06, 2018 at 11:03:46AM +0100, Russell King - ARM Linux wrote: > >> On Wed, Apr 25, 2018 at 11:01:15PM +0300, Jyri Sarha wrote: > >>> Oh yes. But in this case the substandard solution is already there and > >>> it is already widely used, despite it being severely broken. I am merely > >>> trying to fix the existing substandard solution. > >>> > >>> I admit that a full integration with component helpers would probably be > >>> more elegant solution to the problem, but the amount of work is just too > >>> much. The change would impact the way all the master drm drivers pull > >>> them selves together. The drivers that already use the component helpers > >>> for some internal stuff will add their own challenge. Separate component > >>> matching implementations are needed for device-tree and ACPI (are ther > >>> more flavors?) etc. I just do not see this happening any time soon (am > >>> happy to be wrong about this). > >> > >> The issue is actually worse than that: > >> > >> - drivers that are already componentised can't use bridges > >> - drivers that use bridges can't use componentised stuff > >> > >> because bridges don't register themselves with the component helper, > >> and the helpers in drm_of.c assume that all graph nodes will be > >> components. > >> > >> The whole thing about whether stuff is componentised or bridge based > >> is really getting out of hand, and the push is towards bridge based > >> stuff even though that is technically inferior when it comes to being > >> able to develop and test (which involves being able to remove and > >> re-insert modules.) > >> > >> Consequently more and more code is being written for bridges, and > >> the component helper ignored, and the problems with bridges are > >> being ignored. This is not healthy. > >> > >> The problem is only going to get worse. Someone needs to bite the > >> bullet and fix bridges before the problem gets any more out of hand. > > > > This patch (which is actually two patches locally) allows the component > > helper to know what's going on inside the bridge code wrt bridge > > availability, and takes the appropriate action at the correct time. > > No need for device links or similar, or incompatibilities between > > bridges and components. The only requirement is that bridges set the > > "device" member of struct drm_bridge to opt-in to this. > > > > Tested with Armada converted to support bridges, TDA998x as a > > componentised bridge, and dumb-vga-dac as a non-componentised bridge: > > > > root@cubox:~# less /sys/kernel/debug/device_component/display-subsystem > > master namestatus > > - > > display-subsystem bound > > > > device namestatus > > - > > port registered > > port registered > > hdmi-encoder registered > > vga-bridge registered > > root@cubox:~# dmesg |grep bound > > [1.921798] armada-drm display-subsystem: bound f182.lcd-controller > > (ops > > armada_lcd_ops) > > [1.931014] armada-drm display-subsystem: bound f181.lcd-controller > > (ops > > armada_lcd_ops) > > [2.069231] armada-drm display-subsystem: bound 1-0070 (ops tda998x_ops) > > [2.076059] armada-drm display-subsystem: bound vga-bridge (ops > > dummy_ops) > > > > Without this, the same DT fails because "vga-bridge" is never added > > to the component helpers. > > What did you need to do to convert Armada to support bridges? How much > work is it to convert drivers that support bridges so that they > support components? Maybe that's not needed? What happens with tda998x? > I mean, it already calls component_add, and with this there's an > indirect call in drm_bridge_add which it also calls. I guess I'm asking > if a component may call component_add several times without things > sliding sideways? The difference with tda998x is that with the code below (as it stood in an earlier revision of the bridge code, when we had a separate bridge->of_node member), bridge->device is not set for the tda998x, which avoids the duplicated component_add() - which would be illegal (and cause problems.) However, I also hacked tda998x to make tda998x_bind() a no-op - without such a hack, the DRM driver needs to know whether the bridge is tda998x or not, so it knows whether it needs to create the encoder. I don't think there's any simple, non-hacky solution to this problem. > > > > > diff --git a/drivers/base/component.c b/drivers/base/component.c > > index 8946dfee4768..b14b3a3655ea 100644 > > --- a/driver
Re: [Freedreno] [PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
On Mon, Aug 27, 2018 at 09:11:12AM -0600, Jordan Crouse wrote:
> Add the interconnect properties for the GPU on SDM845
> and set the corresponding OPP bandwidth values.
>
> Signed-off-by: Jordan Crouse
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 10db0ceb3699..1e67f4fdd7d1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
> opp-71000 {
> opp-hz = /bits/ 64 <71000>;
> qcom,level = <416>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 721600>;
> };
>
> opp-67500 {
> opp-hz = /bits/ 64 <67500>;
> qcom,level = <384>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 721600>;
> };
>
> opp-59600 {
> opp-hz = /bits/ 64 <59600>;
> qcom,level = <320>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 518400>;
> };
>
> opp-52000 {
> opp-hz = /bits/ 64 <52000>;
> qcom,level = <256>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 406800>;
> };
>
> opp-41400 {
> opp-hz = /bits/ 64 <41400>;
> qcom,level = <192>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 307200>;
> };
>
> opp-34200 {
> opp-hz = /bits/ 64 <34200>;
> qcom,level = <128>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 218800>;
> };
>
> opp-25700 {
> opp-hz = /bits/ 64 <25700>;
> qcom,level = <64>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 12>;
> };
> };
>
> @@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
>
> operating-points-v2 = <&gpu_opp_table>;
>
> + interconnects = <&qnoc 26 &qnoc 512>;
Pointing out for posterity that the src_id here is incorrect. It should be 36.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC||andrey.grodzov...@amd.com --- Comment #6 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Jon from comment #5) > Is there any other information I can provide to help diagnose? I'm not even > sure if I have this bug filed in the right place. Please provide full dmesg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107729] Nouveau gr BUG
https://bugs.freedesktop.org/show_bug.cgi?id=107729 Bug ID: 107729 Summary: Nouveau gr BUG Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: ne-vleza...@yandex.ru [20747.330911] nouveau :01:00.0: fifo: DMA_PUSHER - ch 7 [minetest[12365]] get 03a100 put 080cc8 ib_get 01f6 ib_put 01f9 state 800075e0 (err: INVALID_CMD) push 00406040 [20747.343913] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.343931] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0d80 data [20747.343949] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.343960] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0d84 data 3c808081 [20747.343976] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.343986] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0d88 data 3d30b0b1 [20747.344002] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344010] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0d8c data 3f80 [20747.344027] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344035] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0d90 data 3f80 [20747.344051] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344059] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 19d0 data 003d [20747.344076] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344084] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 12d4 data 1d01 [20747.344123] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344131] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1688 data [20747.344147] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344156] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1534 data [20747.344173] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344181] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 13b0 data 3f80 [20747.344197] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344205] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1570 data [20747.344221] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344229] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 166c data [20747.344245] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344254] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1518 data 3f80 [20747.344269] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344278] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1520 data [20747.344293] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344302] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1658 data [20747.344317] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344326] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0dac data 1b02 [20747.344342] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344350] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0db0 data 1b02 [20747.344366] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344374] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 0db4 data [20747.344390] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344398] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 1918 data [20747.344414] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.344422] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 191c data 0900 [20747.344438] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE] [20747.37] nouveau :01:00.0: gr: 0010 [] ch 7 [000f3de000 minetest[12365]] subc 3 class 8297 mthd 19
[Bug 107729] Nouveau gr BUG
https://bugs.freedesktop.org/show_bug.cgi?id=107729 Alexey changed: What|Removed |Added Keywords||NEEDINFO -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #7 from Jon (jon...@gmail.com) --- Created attachment 278177 --> https://bugzilla.kernel.org/attachment.cgi?id=278177&action=edit dmesg output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107729] Nouveau gr BUG
https://bugs.freedesktop.org/show_bug.cgi?id=107729 --- Comment #1 from Ilia Mirkin --- (In reply to Alexey from comment #0) > [20747.330911] nouveau :01:00.0: fifo: DMA_PUSHER - ch 7 > [minetest[12365]] get 03a100 put 080cc8 ib_get 01f6 ib_put > 01f9 state 800075e0 (err: INVALID_CMD) push 00406040 This is indicative of some sort of error processing commands, anything that happens after that is just indicative of the screwup. The 406040 error is a long-standing issue on Tesla-family GPUs. Still no idea what goes wrong. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107729] Nouveau gr BUG
https://bugs.freedesktop.org/show_bug.cgi?id=107729 Ilia Mirkin changed: What|Removed |Added Product|DRI |xorg Version|XOrg git|unspecified Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg Component|DRM/other |Driver/nouveau QA Contact||xorg-t...@lists.x.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #37 from Marek Olšák --- Created attachment 141323 --> https://bugs.freedesktop.org/attachment.cgi?id=141323&action=edit patch - fix ddebug BO list reporting Hi, Can you please get a new ddebug report with the attached patch? Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #38 from Andrey Grodzovsky --- (In reply to Marek Olšák from comment #37) > Created attachment 141323 [details] [review] > patch - fix ddebug BO list reporting > > Hi, > > Can you please get a new ddebug report with the attached patch? Thanks. Just to be clear, you need to rebuild you mesa library with that patch on top. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree
On Tue, Aug 28, 2018 at 07:29:59AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> ccb748df0058 ("drm/vc4: Fix the "no scaling" case on multi-planar YUV
> formats")
>
> is missing a Signed-off-by from its committer.
>
> It was rebased.
Hi Stephen,
I've fixed the commit and fixed our tooling to avoid this in the future. Thanks
for the poke,
Sean
>
> --
> Cheers,
> Stephen Rothwell
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/dp_mst: Add dp_mst_status debugfs node for all drivers
Hi Lyude, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.19-rc1 next-20180828] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-dp_mst-Add-DP-MST-debugfs-nodes-for-all-drivers/20180828-083742 reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:977: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:977: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info' include/linux/mod_devicetable.h:763: warning: Function parameter or member 'driver_data' not described in 'typec_device_id' kernel/sched/fair.c:3371: warning: Funct
[radeon-alex:drm-next-4.20-wip 220/235] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:771:1-3: WARNING: PTR_ERR_OR_ZERO can be used
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip head: bdb1922abd620d24715906bac4d119274d98f4c9 commit: e498eb7136042aa9a352b1039c678537f4694158 [220/235] drm/amd/display: Add support for hw_state logging via debugfs coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:771:1-3: >> WARNING: PTR_ERR_OR_ZERO can be used Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: fix ptr_ret.cocci warnings
From: kbuild test robot
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:771:1-3:
WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: e498eb713604 ("drm/amd/display: Add support for hw_state logging via
debugfs")
CC: Nicholas Kazlauskas
Signed-off-by: kbuild test robot
---
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: bdb1922abd620d24715906bac4d119274d98f4c9
commit: e498eb7136042aa9a352b1039c678537f4694158 [220/235] drm/amd/display: Add
support for hw_state logging via debugfs
amdgpu_dm_debugfs.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -768,8 +768,5 @@ int dtn_debugfs_init(struct amdgpu_devic
adev,
&dtn_log_fops);
- if (IS_ERR(ent))
- return PTR_ERR(ent);
-
- return 0;
+ return PTR_ERR_OR_ZERO(ent);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 --- Comment #3 from mikhail.v.gavri...@gmail.com --- Yep you right. But suspend mode will be totally useless on the computer on which no programs are running. The sence of suspend mode to put the computer to sleep with all running programs, and then wake up and that everything continues to work. Anyway, I see that in swap there was enough space for unloading the full size of RAM. $ free -m totalusedfree shared buff/cache available Mem: 32158 275001054119336033007 Swap: 655357912 57623 $ cat /proc/meminfo MemTotal: 32930572 kB MemFree: 1149372 kB MemAvailable:3127012 kB Buffers: 28 kB Cached: 3366532 kB SwapCached: 1007320 kB Active: 20999764 kB Inactive:3531864 kB Active(anon): 19666712 kB Inactive(anon): 2725324 kB Active(file):1333052 kB Inactive(file): 806540 kB Unevictable: 31468 kB Mlocked: 31468 kB SwapTotal: 67108860 kB SwapFree: 59004668 kB Dirty: 2008 kB Writeback: 0 kB AnonPages: 21151436 kB Mapped: 1888740 kB Shmem: 1222624 kB Slab: 894752 kB SReclaimable: 301996 kB SUnreclaim: 592756 kB KernelStack: 77072 kB PageTables: 405340 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:83574144 kB Committed_AS: 347269980 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB Percpu:12864 kB HardwareCorrupted: 0 kB AnonHugePages: 2207744 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k:29582752 kB DirectMap2M: 3901440 kB DirectMap1G: 1048576 kB $ vmstat -s 32930572 K total memory 28110600 K used memory 21000912 K active memory 3542156 K inactive memory 1140784 K free memory 28 K buffer memory 3679160 K swap cache 67108860 K total swap 8103680 K used swap 59005180 K free swap 21926506 non-nice user cpu ticks 1867047 nice user cpu ticks 4336923 system cpu ticks 101407781 idle cpu ticks 547470 IO-wait cpu ticks 452621 IRQ cpu ticks 266687 softirq cpu ticks 0 stolen cpu ticks 40223592 pages paged in 62917184 pages paged out 2325269 pages swapped in 4803989 pages swapped out 2369356089 interrupts 4293312571 CPU context switches 1535402349 boot time 398972 forks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 --- Comment #4 from mikhail.v.gavri...@gmail.com --- Created attachment 141325 --> https://bugs.freedesktop.org/attachment.cgi?id=141325&action=edit system log (4.19.0-0.rc1.git0.1) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: add in missing sentinel to a of_device_id array
On Thu, Aug 23, 2018 at 1:16 PM zhong jiang wrote: > I has posted the same patch about a month ago. but it seems to be ignored.:-( > > https://lore.kernel.org/patchwork/patch/971652/ I applied your patch and pushed it. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm: dpu: Allow planes to extend past active display
From: Sean Paul
The atomic_check is a bit too aggressive with respect to planes which
leave the active area. This caused a bunch of log spew when the cursor
got to the edge of the screen and stopped it from going all the way.
This patch removes the conservative bounds checks from atomic and clips
the dst rect such that we properly display planes which go off the
screen.
Changes in v2:
- Apply the clip to src as well (taking into account scaling)
Cc: Sravanthi Kollukuduru
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 14 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 07c2d15b45f2..f0a5e776ba32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1551,8 +1551,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
cnt++;
dst = drm_plane_state_dest(pstate);
- if (!drm_rect_intersect(&clip, &dst) ||
- !drm_rect_equals(&clip, &dst)) {
+ if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
DPU_ERROR("display: " DRM_RECT_FMT " plane: "
DRM_RECT_FMT "\n", DRM_RECT_ARG(&crtc_rect),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index efdf9b200dd9..adfd16625188 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1254,7 +1254,8 @@ static int dpu_plane_sspp_atomic_update(struct drm_plane
*plane,
const struct dpu_format *fmt;
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
- struct drm_rect src, dst;
+ struct drm_rect clip = { 0 }, src, dst;
+ int hscale, vscale;
if (!plane) {
DPU_ERROR("invalid plane\n");
@@ -1300,6 +1301,17 @@ static int dpu_plane_sspp_atomic_update(struct drm_plane
*plane,
dst = drm_plane_state_dest(state);
+ hscale = drm_rect_calc_hscale(&src, &dst,
+ pdpu->pipe_sblk->maxupscale,
+ pdpu->pipe_sblk->maxdwnscale);
+ vscale = drm_rect_calc_vscale(&src, &dst,
+ pdpu->pipe_sblk->maxupscale,
+ pdpu->pipe_sblk->maxdwnscale);
+
+ clip.x2 = crtc->state->adjusted_mode.hdisplay;
+ clip.y2 = crtc->state->adjusted_mode.vdisplay;
+ drm_rect_clip_scaled(&src, &dst, &clip, hscale, vscale);
+
DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FMT "->crtc%u " DRM_RECT_FMT
", %4.4s ubwc %d\n", fb->base.id, DRM_RECT_ARG(&src),
crtc->base.id, DRM_RECT_ARG(&dst),
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.20-wip 231/235] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_priv.h:655:22: error: field 'mmu_notifier' has incomplete type
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: bdb1922abd620d24715906bac4d119274d98f4c9
commit: 521fb7d021f7952aa3030e56c19edf342309cf9f [231/235] drm/amdgpu: Move KFD
parameters to amdgpu (v3)
config: i386-randconfig-s0-08280925 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 521fb7d021f7952aa3030e56c19edf342309cf9f
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:42:0:
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_priv.h:655:22: error: field
>> 'mmu_notifier' has incomplete type
struct mmu_notifier mmu_notifier;
^~~~
vim +/mmu_notifier +655 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_priv.h
52a5fdce Alexey Skidanov 2014-11-19 624
4a488a7a Oded Gabbay 2014-07-16 625 /* Process data */
4a488a7a Oded Gabbay 2014-07-16 626 struct kfd_process {
19f6d2a6 Oded Gabbay 2014-07-16 627/*
19f6d2a6 Oded Gabbay 2014-07-16 628 * kfd_process are stored in an
mm_struct*->kfd_process*
19f6d2a6 Oded Gabbay 2014-07-16 629 * hash table (kfd_processes in
kfd_process.c)
19f6d2a6 Oded Gabbay 2014-07-16 630 */
19f6d2a6 Oded Gabbay 2014-07-16 631struct hlist_node kfd_processes;
19f6d2a6 Oded Gabbay 2014-07-16 632
9b56bb11 Felix Kuehling 2017-10-27 633/*
9b56bb11 Felix Kuehling 2017-10-27 634 * Opaque pointer to mm_struct.
We don't hold a reference to
9b56bb11 Felix Kuehling 2017-10-27 635 * it so it should never be
dereferenced from here. This is
9b56bb11 Felix Kuehling 2017-10-27 636 * only used for looking up
processes by their mm.
9b56bb11 Felix Kuehling 2017-10-27 637 */
9b56bb11 Felix Kuehling 2017-10-27 638void *mm;
19f6d2a6 Oded Gabbay 2014-07-16 639
5ce10687 Felix Kuehling 2017-11-27 640struct kref ref;
5ce10687 Felix Kuehling 2017-11-27 641struct work_struct release_work;
5ce10687 Felix Kuehling 2017-11-27 642
19f6d2a6 Oded Gabbay 2014-07-16 643struct mutex mutex;
19f6d2a6 Oded Gabbay 2014-07-16 644
19f6d2a6 Oded Gabbay 2014-07-16 645/*
19f6d2a6 Oded Gabbay 2014-07-16 646 * In any process, the thread
that started main() is the lead
19f6d2a6 Oded Gabbay 2014-07-16 647 * thread and outlives the rest.
19f6d2a6 Oded Gabbay 2014-07-16 648 * It is here because
amd_iommu_bind_pasid wants a task_struct.
894a8293 Felix Kuehling 2017-11-01 649 * It can also be used for
safely getting a reference to the
894a8293 Felix Kuehling 2017-11-01 650 * mm_struct of the process.
19f6d2a6 Oded Gabbay 2014-07-16 651 */
19f6d2a6 Oded Gabbay 2014-07-16 652struct task_struct *lead_thread;
19f6d2a6 Oded Gabbay 2014-07-16 653
19f6d2a6 Oded Gabbay 2014-07-16 654/* We want to receive a
notification when the mm_struct is destroyed */
19f6d2a6 Oded Gabbay 2014-07-16 @655struct mmu_notifier
mmu_notifier;
19f6d2a6 Oded Gabbay 2014-07-16 656
19f6d2a6 Oded Gabbay 2014-07-16 657/* Use for delayed freeing of
kfd_process structure */
19f6d2a6 Oded Gabbay 2014-07-16 658struct rcu_head rcu;
19f6d2a6 Oded Gabbay 2014-07-16 659
19f6d2a6 Oded Gabbay 2014-07-16 660unsigned int pasid;
a91e70e3 Felix Kuehling 2017-08-26 661unsigned int doorbell_index;
19f6d2a6 Oded Gabbay 2014-07-16 662
19f6d2a6 Oded Gabbay 2014-07-16 663/*
19f6d2a6 Oded Gabbay 2014-07-16 664 * List of kfd_process_device
structures,
19f6d2a6 Oded Gabbay 2014-07-16 665 * one for each device the
process is using.
19f6d2a6 Oded Gabbay 2014-07-16 666 */
19f6d2a6 Oded Gabbay 2014-07-16 667struct list_head
per_device_data;
19f6d2a6 Oded Gabbay 2014-07-16 668
45102048 Ben Goz 2014-07-17 669struct process_queue_manager
pqm;
45102048 Ben Goz 2014-07-17 670
19f6d2a6 Oded Gabbay 2014-07-16 671/*Is the user space process 32
bit?*/
19f6d2a6 Oded Gabbay 2014-07-16 672bool is_32bit_user_mode;
f3a39818 Andrew Lewycky 2015-05-10 673
f3a39818 Andrew Lewycky 2015-05-10 674/* Event-related data */
f3a39818 Andrew Lewycky 2015-05-10 675struct mutex event_mutex;
482f0777 Felix Kuehling 2017-10-27 676/* Event ID allocator and
lookup */
482f0777 Felix Kuehling 2017-10-27 677struct idr event_idr;
50cb7dd9 Felix Kuehling 2017-10-27 678/* Event page */
50cb7dd9 Felix Kuehling 2017-10-27 679struct kfd_signal_page
*signal_page;
b9a5d0a5 Felix Kuehling 2017-10-27 680size_t signal_mapped_size;
f3a39818 Andrew Lewycky 2015-05-10 681size_t signal_event_count;
c986
