Re: [PATCH drm/hisilicon 1/2] drm/hisilicon: Use managed mode-config init
Hi
Am 07.12.20 um 01:49 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..d631f82 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,7 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
priv->mode_config_initialized = true;
I think mode_config_initialized is only required by hibmc_kms_finit(),
which you remove. You should remove this line and the field from struct
hibmc_drm_private.
Best regards
Thomas
dev->mode_config.min_width = 0;
@@ -125,14 +127,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +256,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon 2/2] drm/hisilicon: Delete unused local parameters
Am 07.12.20 um 01:49 schrieb Tian Tao:
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d631f82..772f58e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,12 +251,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
- dev->dev_private = NULL;
+
return 0;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm: rcar-du: Fix crash when using LVDS1 clock for CRTC
Hi Laurent,
On Fri, Dec 4, 2020 at 11:02 PM Laurent Pinchart
wrote:
> On D3 and E3 platforms, the LVDS encoder includes a PLL that can
> generate a clock for the corresponding CRTC, used even when the CRTC
> output to a non-LVDS port. This mechanism is supported by the driver,
> but the implementation is broken in dual-link LVDS mode. In that case,
> the LVDS1 drm_encoder is skipped, which causes a crash when trying to
> access its bridge later on.
>
> Fix this by storing bridge pointers internally instead of retrieving
> them from the encoder.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
I think this warrants a Fixes tag, to assist the stable team in backporting
this fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/13] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
Hi
Am 06.12.20 um 20:37 schrieb Randy Dunlap:
On 12/6/20 11:02 AM, Sam Ravnborg wrote:
Fix kernel-doc warnings reported when using W=1
v2:
- Improve subject (Lee)
v3:
- Add RETURNS documentation (Thomas)
Hi Sam,
Yes, RETURNS: will work. It just looks like any kernel-doc section name,
such as Context: or Note:.
However, the documented format for return info is "Return:".
(see Documentation/doc-guide/kernel-doc.rst)
Thanks for the note. I asked for RETURNS: because the rest of the file
appears to be using it. Returns: is certainly the better alternative. I
didn't know there was a difference.
Best regards
Thomas
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Sam Ravnborg
Cc: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Alexander A. Klimov"
---
drivers/video/fbdev/core/fb_notify.c | 10 ++
drivers/video/fbdev/core/fbmon.c | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_notify.c
b/drivers/video/fbdev/core/fb_notify.c
index 74c2da528884..4e39c61fae1f 100644
--- a/drivers/video/fbdev/core/fb_notify.c
+++ b/drivers/video/fbdev/core/fb_notify.c
@@ -19,6 +19,9 @@ static BLOCKING_NOTIFIER_HEAD(fb_notifier_list);
/**
*fb_register_client - register a client notifier
*@nb: notifier block to callback on events
+ *
+ * RETURNS:
+ * 0 on success, negative error code on failure.
*/
int fb_register_client(struct notifier_block *nb)
{
@@ -29,6 +32,9 @@ EXPORT_SYMBOL(fb_register_client);
/**
*fb_unregister_client - unregister a client notifier
*@nb: notifier block to callback on events
+ *
+ * RETURNS:
+ * 0 on success, negative error code on failure.
*/
int fb_unregister_client(struct notifier_block *nb)
{
@@ -38,7 +44,11 @@ EXPORT_SYMBOL(fb_unregister_client);
/**
* fb_notifier_call_chain - notify clients of fb_events
+ * @val: value passed to callback
+ * @v: pointer passed to callback
*
+ * RETURNS:
+ * The return value of the last notifier function
*/
int fb_notifier_call_chain(unsigned long val, void *v)
{
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 1bf82dbc9e3c..b0e690f41025 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -605,6 +605,7 @@ static void get_detailed_timing(unsigned char *block,
* fb_create_modedb - create video mode database
* @edid: EDID data
* @dbsize: database size
+ * @specs: monitor specifications, may be NULL
*
* RETURNS: struct fb_videomode, @dbsize contains length of database
*
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/13] video: fbdev: omapfb: Fix set but not used warnings in hdmi*_core
Am 06.12.20 um 20:02 schrieb Sam Ravnborg: Fix a few W=1 warnings about unused assignments. Drop the unused error code. v2: - Subject updated (Lee) Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Qilong Zhang Cc: "Alexander A. Klimov" Cc: Daniel Vetter Cc: Lee Jones Acked-by: Thomas Zimmermann --- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 4 ++-- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c index 726c190862d4..e6363a420933 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c @@ -679,7 +679,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config acore; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -741,7 +741,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, &n, &cts); + hdmi_compute_acr(pclk, fs_nr, &n, &cts); /* Audio clock regeneration settings */ acore.n = n; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c index eda29d3032e1..cb63bc0e92ca 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c @@ -790,7 +790,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config core_cfg; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -833,7 +833,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, &n, &cts); + hdmi_compute_acr(pclk, fs_nr, &n, &cts); core_cfg.n = n; core_cfg.cts = cts; -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/13] video: fbdev: uvesafb: Fix set but not used warning
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Fix W=1 warning by deleting unused local variable.
v2:
- Updated subject (Lee)
v3:
- Return early in case of an error (Thomas)
Signed-off-by: Sam Ravnborg
Cc: Michal Januszewski
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/uvesafb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 6c9cfab39313..4df6772802d7 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -560,6 +560,8 @@ static int uvesafb_vbe_getpmi(struct uvesafb_ktask *task,
task->t.regs.eax = 0x4f0a;
task->t.regs.ebx = 0x0;
err = uvesafb_exec(task);
+ if (err)
+ return err;
if ((task->t.regs.eax & 0x) != 0x4f || task->t.regs.es < 0xc000) {
par->pmi_setpal = par->ypan = 0;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/13] sh: Fix set but not used warnings with !CONFIG_MMU
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Building fbdev drivers for sh with W=1 produces the following warning:
tmiofb.c: In function ‘tmiofb_remove’:
tmiofb.c:805:21: warning: variable ‘par’ set but not used
This is with allmodconfig and ARCH=sh
This boiled down to iounmap() defined as empty for !CONFIG_MMU.
Fix this by by adding "(void)addr;" to tell the compiler the
argument to iounmap() should be considered used.
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Lee Jones
Cc: Rich Felker
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Mike Rapoport
Cc: Kuninori Morimoto
Cc: Peter Zijlstra
Cc: Sam Ravnborg
Cc: Andrew Morton
Acked-by: Thomas Zimmermann
---
arch/sh/include/asm/io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 6d5c6463bc07..5ad56c6c1e1e 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -271,7 +271,7 @@ static inline void __iomem *ioremap_prot(phys_addr_t
offset, unsigned long size,
#endif /* CONFIG_HAVE_IOREMAP_PROT */
#else /* CONFIG_MMU */
-#define iounmap(addr) do { } while (0)
+#define iounmap(addr) do { (void)addr; } while (0)
#define ioremap(offset, size) ((void __iomem *)(unsigned long)(offset))
#endif /* CONFIG_MMU */
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 06/13] video: fbdev: sparc drivers: fix kernel-doc warnings for blank_mode
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Fix kernel-doc warnings caused by a wrong parameter name
blank_mode => blank
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/bw2.c | 2 +-
drivers/video/fbdev/cg3.c | 2 +-
drivers/video/fbdev/cg6.c | 2 +-
drivers/video/fbdev/ffb.c | 2 +-
drivers/video/fbdev/leo.c | 2 +-
drivers/video/fbdev/p9100.c | 2 +-
drivers/video/fbdev/tcx.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/bw2.c b/drivers/video/fbdev/bw2.c
index 0d9a6bb57a09..e7702fe1fe7d 100644
--- a/drivers/video/fbdev/bw2.c
+++ b/drivers/video/fbdev/bw2.c
@@ -116,7 +116,7 @@ struct bw2_par {
/**
* bw2_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*/
static int
diff --git a/drivers/video/fbdev/cg3.c b/drivers/video/fbdev/cg3.c
index 77f6470ce665..bdcc3f6ab666 100644
--- a/drivers/video/fbdev/cg3.c
+++ b/drivers/video/fbdev/cg3.c
@@ -179,7 +179,7 @@ static int cg3_setcolreg(unsigned regno,
/**
* cg3_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*/
static int cg3_blank(int blank, struct fb_info *info)
diff --git a/drivers/video/fbdev/cg6.c b/drivers/video/fbdev/cg6.c
index a1c68cd48d7e..97ef43c25974 100644
--- a/drivers/video/fbdev/cg6.c
+++ b/drivers/video/fbdev/cg6.c
@@ -511,7 +511,7 @@ static int cg6_setcolreg(unsigned regno,
/**
*cg6_blank - Blanks the display.
*
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
*@info: frame buffer structure that represents a single frame buffer
*/
static int cg6_blank(int blank, struct fb_info *info)
diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c
index 948b73184433..b3d580e57221 100644
--- a/drivers/video/fbdev/ffb.c
+++ b/drivers/video/fbdev/ffb.c
@@ -667,7 +667,7 @@ static int ffb_setcolreg(unsigned regno,
/**
*ffb_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
*@info: frame buffer structure that represents a single frame buffer
*/
static int ffb_blank(int blank, struct fb_info *info)
diff --git a/drivers/video/fbdev/leo.c b/drivers/video/fbdev/leo.c
index 40b11cce0ad6..3eb0f3583f4f 100644
--- a/drivers/video/fbdev/leo.c
+++ b/drivers/video/fbdev/leo.c
@@ -308,7 +308,7 @@ static int leo_setcolreg(unsigned regno,
/**
* leo_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*/
static int leo_blank(int blank, struct fb_info *info)
diff --git a/drivers/video/fbdev/p9100.c b/drivers/video/fbdev/p9100.c
index 6da672e92643..4e88a0a195ad 100644
--- a/drivers/video/fbdev/p9100.c
+++ b/drivers/video/fbdev/p9100.c
@@ -175,7 +175,7 @@ static int p9100_setcolreg(unsigned regno,
/**
* p9100_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*/
static int
diff --git a/drivers/video/fbdev/tcx.c b/drivers/video/fbdev/tcx.c
index 34b2e5b6e84a..1638a40fed22 100644
--- a/drivers/video/fbdev/tcx.c
+++ b/drivers/video/fbdev/tcx.c
@@ -196,7 +196,7 @@ static int tcx_setcolreg(unsigned regno,
/**
* tcx_blank - Optional function. Blanks the display.
- * @blank_mode: the blank mode we want.
+ * @blank: the blank mode we want.
* @info: frame buffer structure that represents a single frame buffer
*/
static int
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drivers may provide multiple primary planes per CRTC
On Sun, 06 Dec 2020 15:24:29 + Simon Ser wrote: > Sorry, I think I lost track of this thread at some point and forgot > about it. That said… > > On Friday, August 7th, 2020 at 3:06 PM, Daniel Vetter wrote: > > > On Fri, Aug 07, 2020 at 12:38:02PM +0300, Pekka Paalanen wrote: > > > On Fri, 7 Aug 2020 11:07:06 +0200 > > > Daniel Vetter wrote: > > > > > > > On Thu, Aug 06, 2020 at 10:33:31AM +, Simon Ser wrote: > > > > > Some drivers may expose primary planes compatible with multiple CRTCs. > > > > > Make this clear in the docs: the current wording may be misunderstood > > > > > as > > > > > "exactly one primary plane per CRTC". > > > > > > > > > > Signed-off-by: Simon Ser > > > > > Cc: Daniel Vetter > > > > > --- > > > > > drivers/gpu/drm/drm_plane.c | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > > > > index b7b90b3a2e38..108a922e8c23 100644 > > > > > --- a/drivers/gpu/drm/drm_plane.c > > > > > +++ b/drivers/gpu/drm/drm_plane.c > > > > > @@ -49,8 +49,8 @@ > > > > > * &struct drm_plane (possibly as part of a larger structure) and > > > > > registers it > > > > > * with a call to drm_universal_plane_init(). > > > > > * > > > > > - * Cursor and overlay planes are optional. All drivers should > > > > > provide one > > > > > - * primary plane per CRTC to avoid surprising userspace too much. > > > > > See enum > > > > > + * Cursor and overlay planes are optional. All drivers should > > > > > provide at least > > > > > + * one primary plane per CRTC to avoid surprising userspace too > > > > > much. See enum > > > > > > > > I think that's even more confusing, since this reads like there could be > > > > multiple primary planes for a specific CRTC. That's not the case, there' > > > > only one pointer going from drm_crtc->primary to a drm_plane in the > > > > kernel. > > > > > > There could be multiple primary planes *usable* for a specific CRTC but > > > just one used at a time, right? > > > > I'm not sure what you mean here, the crtc->primary link is invariant over > > the lifetime of a driver load. You can't pick a different one, that's set > > at driver init before drm_dev_register (and hence before userspace ever > > sees anything). > > OK. I'm personally not very interested in documenting legacy bits, so I'll > skip > that. I'm mainly interested here in making it clear possible_crtcs for a > primary plane can have more than one bit set. Because of the paragraph in the > current docs, some user-space developers have understood "more than one bit > set > in possible_crtcs for a primary plane is a kernel bug". > > I'll send a v2 that makes it clear these pointers are for legacy uAPI. Right, so this and what danvet said seem to be in direct conflict in atomic uAPI, repeating above: > > I'm not sure what you mean here, the crtc->primary link is invariant over > > the lifetime of a driver load. You can't pick a different one, that's set > > at driver init before drm_dev_register (and hence before userspace ever > > sees anything). But still, it is considered not a kernel bug that a primary plane has more than one bit set in its possible_crtcs. If a primary plane has more than one bit set in possible_crtcs, and it is not a kernel bug, then userspace expects to be able to choose any of the multiple indicated possible CRTCs for this primary plane. Which way is it? Or, is there a different limitation that for each CRTC, there must be exactly one primary plane with that CRTCs bit set in its possible_crtcs? IOW, you can have more CRTCs than primary planes in total, and you can activate each CRTC alone, but you cannot activate all CRTCs simultaneously because there are not enough primary planes for them? Representing it mathematically, the possible assignments according to possible_crtcs while ignoring all other limitations are: N CRTCs <-> M primary planes - Is N one or greater than one? - Is M one or greater than one? Thanks, pq pgphz8VjW3IPJ.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Fri, 4 Dec 2020 11:07:41 -0800 James Park wrote: > I could adjust the block to look like this: > > #ifdef DRM_FOURCC_STANDALONE > #if defined(__linux__) > #include > #else > #include > typedef uint32_t __u32; > typedef uint64_t __u64; > #endif > #else > #include "drm.h" > #endif > > Alternatively, I could create a new common header to be included from both > drm.h and drm_fourcc.h, drm_base_types.h or something like that: > > #ifdef DRM_FOURCC_STANDALONE > #include "drm_base_types.h" > #else > #include "drm.h" > #endif Hi, my point is, any solution relying on DRM_FOURCC_STANDALONE will fail sometimes, because there is no reason why userspace would *not* #define DRM_FOURCC_STANDALONE. Hence, #ifdef DRM_FOURCC_STANDALONE is completely moot, you have to make the headers work in any include order when DRM_FOURCC_STANDALONE is defined anyway. Thanks. pq > On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote: > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen wrote: > > > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > > Daniel Vetter wrote: > > > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park > > > > > > wrote: > > > > > > > > > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't > > > > > intentional, right? Should I put all the integer types, or just the > > > > > ones that are used in that file? > > > > > > > > Yeah that trailing _ just slipped in. And I'd just do the types > > > > already used. I don't think anything else than __u32 (for drm fourcc) > > > > and __u64 (for drm modifier) is needed. > > > > > > Hi, > > > > > > can that create conflicts if userspace first includes drm_fourcc.h and > > > then drm.h? > > > > > > I would find it natural to userspace have generic headers including > > > drm_fourcc.h and then DRM-specific C-files including drm.h as well > > > (through libdrm headers). I think Weston might already do this. > > > > > > The generic userspace (weston) header would obviously #define > > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as well. > > > > Hm yes that would break. I guess we could just include the linux types > > header for this. And I guess on windows you'd need to have that from > > somewhere. Or we just require that users of the standalone header pull > > the right header or defines in first? > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > pgpi8rADzD5mR.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/7] drm/vc4: kms: Remove unassigned_channels from the HVS state
The HVS state now has both unassigned_channels that reflects the
channels that are not used in the associated state, and the in_use
boolean for each channel that says whether or not a particular channel
is in use.
Both express pretty much the same thing, and we need the in_use variable
to properly track the commits, so let's get rid of unassigned_channels.
Suggested-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index fdd698df5fbe..fa40c44eb770 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -39,7 +39,6 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
drm_private_state *priv)
struct vc4_hvs_state {
struct drm_private_state base;
- unsigned int unassigned_channels;
struct {
unsigned in_use: 1;
@@ -798,7 +797,6 @@ vc4_hvs_channels_duplicate_state(struct drm_private_obj
*obj)
__drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
- state->unassigned_channels = old_state->unassigned_channels;
for (i = 0; i < HVS_NUM_CHANNELS; i++) {
state->fifo_state[i].in_use = old_state->fifo_state[i].in_use;
@@ -849,7 +847,6 @@ static int vc4_hvs_channels_obj_init(struct vc4_dev *vc4)
if (!state)
return -ENOMEM;
- state->unassigned_channels = GENMASK(HVS_NUM_CHANNELS - 1, 0);
drm_atomic_private_obj_init(&vc4->base, &vc4->hvs_channels,
&state->base,
&vc4_hvs_state_funcs);
@@ -893,12 +890,17 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
struct vc4_hvs_state *hvs_new_state;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc *crtc;
+ unsigned int unassigned_channels;
unsigned int i;
hvs_new_state = vc4_hvs_get_global_state(state);
if (!hvs_new_state)
return -EINVAL;
+ for (i = 0; i < HVS_NUM_CHANNELS; i++)
+ if (!hvs_new_state->fifo_state[i].in_use)
+ unassigned_channels |= BIT(i);
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
struct vc4_crtc_state *old_vc4_crtc_state =
to_vc4_crtc_state(old_crtc_state);
@@ -918,8 +920,6 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
/* If we're disabling our CRTC, we put back our channel */
if (!new_crtc_state->enable) {
channel = old_vc4_crtc_state->assigned_channel;
-
- hvs_new_state->unassigned_channels |= BIT(channel);
hvs_new_state->fifo_state[channel].in_use = false;
new_vc4_crtc_state->assigned_channel =
VC4_HVS_CHANNEL_DISABLED;
continue;
@@ -949,13 +949,13 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
* the future, we will need to have something smarter,
* but it works so far.
*/
- matching_channels = hvs_new_state->unassigned_channels &
vc4_crtc->data->hvs_available_channels;
+ matching_channels = unassigned_channels &
vc4_crtc->data->hvs_available_channels;
if (!matching_channels)
return -EINVAL;
channel = ffs(matching_channels) - 1;
new_vc4_crtc_state->assigned_channel = channel;
- hvs_new_state->unassigned_channels &= ~BIT(channel);
+ unassigned_channels &= ~BIT(channel);
hvs_new_state->fifo_state[channel].in_use = true;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings
On 2020/12/5 1:41, Mark Brown wrote: > On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote: >> All warnings are related only to "wrong indentation", except one: >> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \ >> [error] missing document start "---" (document-start) > > It would make life easier (and be more normal practice) to split this up > by driver/subsystem and send a bunch of separate patches to the relevant > maintainers, this makes it much easier to review and handle things. Okay, I'll split this patch and send them separately. I'm not going to mark the new patches as v2 to save trouble. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ingenic: depend on COMMON_CLK to fix compile tests
Hi Krzysztof, Le ven. 4 déc. 2020 à 10:18, Krzysztof Kozlowski a écrit : On Mon, Nov 16, 2020 at 07:54:03PM +, Paul Cercueil wrote: Hi Krzysztof, Le lun. 16 nov. 2020 à 18:53, Krzysztof Kozlowski a écrit : > The Ingenic DRM uses Common Clock Framework thus it cannot be built on > platforms without it (e.g. compile test on MIPS with RALINK and > SOC_RT305X): > > /usr/bin/mips-linux-gnu-ld: > drivers/gpu/drm/ingenic/ingenic-drm-drv.o: in function > `ingenic_drm_bind.isra.0': > ingenic-drm-drv.c:(.text+0x1600): undefined reference to > `clk_get_parent' > /usr/bin/mips-linux-gnu-ld: ingenic-drm-drv.c:(.text+0x16b0): > undefined reference to `clk_get_parent' > > Reported-by: kernel test robot > Signed-off-by: Krzysztof Kozlowski Acked-by: Paul Cercueil Thanks for the ack. David and Daniel, I think there is no dedicated maintainer for Ingenic DRM, so can you pick it up directly? I am. Pushed to drm-misc-next, thanks! -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/5] ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property,
so add them to the 'hdmi' node for 'rk3066a.dtsi'.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..67fcb0dc9 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -124,6 +124,7 @@
pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
status = "disabled";
ports {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] irq: export kstat_irqs
Jerry, On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote: The proper prefix is 'genirq:' git log kernel/irq/irqdesc.c would have told you. > To try and detect potential interrupt storms that > have been occurring with tpm_tis devices it was suggested > to use kstat_irqs() to get the number of interrupts. > Since tpm_tis can be built as a module it needs kstat_irqs > exported. I'm not really enthused about exporting this without making it at least safe. Using it from an interrupt handler is obviously safe vs. concurrent removal, but the next driver writer who thinks this is cool is going to get it wrong for sure. Though I still have to figure out what the advantage of invoking a function which needs to do a radix tree lookup over a device local counter is just to keep track of this. I'll reply on the TPM part of this as well. Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/1] dt-bindings: display: eliminate yamllint warnings
This patch is based on the latest linux-next code. v1 --> v2: Extract the modification of the Documentation/devicetree/bindings/display/ parts and send the patch separately. https://www.spinics.net/lists/arm-kernel/msg860713.html v1: There're too many people, I just send to the maintainer, reviewer, supporter. Eliminate below warnings: ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml:32:13: [warning] wrong indentation: expected 14 but found 12 (indentation) ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml:35:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml:21:6: [warning] wrong indentation: expected 6 but found 5 (indentation) ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml:52:9: [warning] wrong indentation: expected 6 but found 8 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml:42:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml:25:10: [warning] wrong indentation: expected 10 but found 9 (indentation) ./Documentation/devicetree/bindings/media/i2c/adv7604.yaml:24:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: [error] missing document start "---" (document-start) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:29:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:32:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml:79:17: [warning] wrong indentation: expected 14 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml:88:17: [warning] wrong indentation: expected 14 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml:72:17: [warning] wrong indentation: expected 18 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml:75:17: [warning] wrong indentation: expected 18 but found 16 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:20:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:30:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:33:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml:10:4: [warning] wrong indentation: expected 2 but found 3 (indentation) Zhen Lei (1): dt-bindings: display: eliminate yamllint warnings .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 ++-- .../devicetree/bindings/display/bridge/intel,keembay-dsi.yaml | 4 ++-- Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml | 4 ++-- Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
On Sun, Dec 06 2020 at 14:47, Jerry Snitselaar wrote: > Thomas Gleixner @ 2020-12-06 09:38 MST: > > I don't know the history behind this bit. I stumbled across it in cscope > when looking for places using kstat_irqs. I'm not ranting at you. The i915 people are on Cc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver
From: Zheng Yang
Add sound support to the rk3066 HDMI driver.
The I2S input of the HDMI TX allows transmission of
DVD-Audio and decoded Dolby Digital
to A/V Receivers and high-end displays.
The interface supports 2 to 8 channels audio up to 192 kHz.
The HDMI TX supports variable word length of
16bits to 32bits for I2S audio inputs.(This driver 24bit max)
There are three I2S input modes supported.(This driver HDMI_I2S only)
On RK3066/PX2 the HDMI TX audio source is connected to I2S_8CH.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/Kconfig | 2 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 277 -
2 files changed, 278 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 310aa1546..4c20445dc 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -11,6 +11,8 @@ config DRM_ROCKCHIP
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
+ select SND_SOC_HDMI_CODEC if ROCKCHIP_RK3066_HDMI && SND_SOC
+ select SND_SOC_ROCKCHIP_I2S if ROCKCHIP_RK3066_HDMI && SND_SOC
help
Choose this option if you have a Rockchip soc chipset.
This driver provides kernel mode setting and buffer
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1c546c3a8..2f8654023 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
#include "rk3066_hdmi.h"
#include "rockchip_drm_drv.h"
@@ -20,9 +22,16 @@
#define DEFAULT_PLLA_RATE 3000
+struct audio_info {
+ int channels;
+ int sample_rate;
+ int sample_width;
+};
+
struct hdmi_data_info {
int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
bool sink_is_hdmi;
+ bool sink_has_audio;
unsigned int enc_out_format;
unsigned int colorimetry;
};
@@ -54,12 +63,19 @@ struct rk3066_hdmi {
unsigned int tmdsclk;
+ struct platform_device *audio_pdev;
+ struct audio_info audio;
+ bool audio_enable;
+
struct hdmi_data_info hdmi_data;
struct drm_display_mode previous_mode;
};
#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+static int
+rk3066_hdmi_config_audio(struct rk3066_hdmi *hdmi, struct audio_info *audio);
+
static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
{
return readl_relaxed(hdmi->regs + offset);
@@ -205,6 +221,23 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi,
HDMI_INFOFRAME_AVI, 0, 0, 0);
}
+static int rk3066_hdmi_config_aai(struct rk3066_hdmi *hdmi,
+ struct audio_info *audio)
+{
+ union hdmi_infoframe frame;
+ int rc;
+
+ rc = hdmi_audio_infoframe_init(&frame.audio);
+
+ frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
+ frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
+ frame.audio.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
+ frame.audio.channels = hdmi->audio.channels;
+
+ return rk3066_hdmi_upload_frame(hdmi, rc, &frame,
+ HDMI_INFOFRAME_AAI, 0, 0, 0);
+}
+
static int rk3066_hdmi_config_video_timing(struct rk3066_hdmi *hdmi,
struct drm_display_mode *mode)
{
@@ -353,6 +386,7 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK,
HDMI_VIDEO_MODE_HDMI);
rk3066_hdmi_config_avi(hdmi, mode);
+ rk3066_hdmi_config_audio(hdmi, &hdmi->audio);
} else {
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK, 0);
}
@@ -369,9 +403,20 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
*/
rk3066_hdmi_i2c_init(hdmi);
- /* Unmute video output. */
+ /* Unmute video and audio output. */
hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
HDMI_VIDEO_AUDIO_DISABLE_MASK, HDMI_AUDIO_DISABLE);
+ if (hdmi->audio_enable) {
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2, HDMI_AUDIO_DISABLE, 0);
+ /* Reset audio capture logic. */
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK,
+ HDMI_AUDIO_CP_LOGIC_RESET);
+ usleep_range(900, 1000);
+ hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK, 0);
+ }
+
return 0;
}
@@ -473,9 +518,13 @@ static int rk3066_hdmi_connector_get_modes(struct
drm_connector *connector)
edid = drm_get_edid(connector, hdmi->ddc);
[PATCH v3 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..d59e2db
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+oneOf:
+ - const: fsl,imx8qxp-prg
+ - const: fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <&dc0_prg0_lpcg IMX_LPCG_CLK_0>,
+ <&dc0_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = <&pd IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 19-11-20, 11:35, Viresh Kumar wrote:
> On 18-11-20, 08:53, Rob Clark wrote:
> > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > wrote:
> > >
> > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > With that on top of the previous patch,
> > >
> > > Don't you still have this ? Which fixed the lockdep in the remove path.
> > >
> > > https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
> > >
> > > To make it clear you need these patches to fix the OPP stuff:
> > >
> > > //From 5.10-rc3 (the one from the above link).
> > > commit e0df59de670b ("opp: Reduce the size of critical section in
> > > _opp_table_kref_release()")
>
> This fixes debugfs stuff while the OPP table is removed.
>
> > > //Below two from linux-next
> > > commit ef43f01ac069 ("opp: Always add entries in dev_list with
> > > opp_table->lock held")
> > > commit 27c09484dd3d ("opp: Allocate the OPP table outside of
> > > opp_table_lock")
>
> This fixes debugfs stuff while the OPP table is added.
>
> > > This matches the diff I gave you earlier.
> > >
> >
> > no, I did not have all three, only "opp: Allocate the OPP table
> > outside of opp_table_lock" plus the fixup. But with all three:
>
> And looking at the lockdep you gave now, it looks like we have a
> problem with OPP table's internal lock (opp_table->lock) as well apart
> from the global opp_table_lock.
>
> I wish there was a way for me to reproduce the lockdep :(
>
> I know this is exhausting for both of us and I really want to be over
> with it as soon as possible, this really should be the last patch
> here, please try this along with other two. This fixes the debugfs
> thing while the OPPs in the OPP table are removed (they are already
> added without a lock around debugfs stuff).
>
> AFAIU, there is no further debugfs stuff that happens from within the
> locks and so this really should be the last patch unless I missed
> something.
Rob, were you able to test this patch ?
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] irq: export kstat_irqs
On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote: > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote: >> To try and detect potential interrupt storms that >> have been occurring with tpm_tis devices it was suggested >> to use kstat_irqs() to get the number of interrupts. >> Since tpm_tis can be built as a module it needs kstat_irqs >> exported. > > I think you should also have a paragraph explicitly stating that > i915_pmu.c contains a duplicate of kstat_irqs() because it is not > exported as of today. It adds a lot more weight to this given that > there is already existing mainline usage (kind of). It's abusage and just the fact that it exists is not an argument by itself. Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/5] ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi
Add hdmi-sound node to rk3066a.dtsi, so that it
can be reused by boards with HDMI support.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 67fcb0dc9..f91ce3054 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -49,6 +49,22 @@
ports = <&vop0_out>, <&vop1_out>;
};
+ hdmi_sound: hdmi-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "HDMI";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <256>;
+ status = "disabled";
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0>;
+ };
+ };
+
sram: sram@1008 {
compatible = "mmio-sram";
reg = <0x1008 0x1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/13] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
On 12/6/20 11:02 AM, Sam Ravnborg wrote:
> Fix kernel-doc warnings reported when using W=1
>
> v2:
> - Improve subject (Lee)
>
> v3:
> - Add RETURNS documentation (Thomas)
Hi Sam,
Yes, RETURNS: will work. It just looks like any kernel-doc section name,
such as Context: or Note:.
However, the documented format for return info is "Return:".
(see Documentation/doc-guide/kernel-doc.rst)
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Sam Ravnborg
> Cc: Randy Dunlap
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: "Alexander A. Klimov"
> ---
> drivers/video/fbdev/core/fb_notify.c | 10 ++
> drivers/video/fbdev/core/fbmon.c | 2 +-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/fb_notify.c
> b/drivers/video/fbdev/core/fb_notify.c
> index 74c2da528884..4e39c61fae1f 100644
> --- a/drivers/video/fbdev/core/fb_notify.c
> +++ b/drivers/video/fbdev/core/fb_notify.c
> @@ -19,6 +19,9 @@ static BLOCKING_NOTIFIER_HEAD(fb_notifier_list);
> /**
> * fb_register_client - register a client notifier
> * @nb: notifier block to callback on events
> + *
> + * RETURNS:
> + * 0 on success, negative error code on failure.
> */
> int fb_register_client(struct notifier_block *nb)
> {
> @@ -29,6 +32,9 @@ EXPORT_SYMBOL(fb_register_client);
> /**
> * fb_unregister_client - unregister a client notifier
> * @nb: notifier block to callback on events
> + *
> + * RETURNS:
> + * 0 on success, negative error code on failure.
> */
> int fb_unregister_client(struct notifier_block *nb)
> {
> @@ -38,7 +44,11 @@ EXPORT_SYMBOL(fb_unregister_client);
>
> /**
> * fb_notifier_call_chain - notify clients of fb_events
> + * @val: value passed to callback
> + * @v: pointer passed to callback
> *
> + * RETURNS:
> + * The return value of the last notifier function
> */
> int fb_notifier_call_chain(unsigned long val, void *v)
> {
> diff --git a/drivers/video/fbdev/core/fbmon.c
> b/drivers/video/fbdev/core/fbmon.c
> index 1bf82dbc9e3c..b0e690f41025 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -605,6 +605,7 @@ static void get_detailed_timing(unsigned char *block,
> * fb_create_modedb - create video mode database
> * @edid: EDID data
> * @dbsize: database size
> + * @specs: monitor specifications, may be NULL
> *
> * RETURNS: struct fb_videomode, @dbsize contains length of database
> *
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state
Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning. The precedent has already been set by other macros in the same file. Signed-off-by: Liu Ying --- v2->v3: * Add a missing blank line. v1->v2: * No change. include/drm/drm_atomic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 54e051a..2e087d7 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -888,7 +888,10 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (__i)++) \ for_each_if ((__state)->planes[__i].ptr && \ ((plane) = (__state)->planes[__i].ptr, \ - (old_plane_state) = (__state)->planes[__i].old_state, 1)) + (void)(plane) /* Only to avoid unused-but-set-variable warning */, \ + (old_plane_state) = (__state)->planes[__i].old_state, \ + (void)(old_plane_state) /* Only to avoid unused-but-set-variable warning */, 1)) + /** * for_each_new_plane_in_state - iterate over all planes in an atomic update * @__state: &struct drm_atomic_state pointer -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm/vc4: kms: Convert to atomic helpers
Now that the semaphore is gone, our atomic_commit implementation is
basically drm_atomic_helper_commit with a somewhat custom commit_tail,
the main difference being that we're using wait_for_flip_done instead of
wait_for_vblanks used in the drm_atomic_helper_commit_tail helper.
Let's switch to using drm_atomic_helper_commit.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 110 +-
1 file changed, 3 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ffbfdde55fff..05f451f3e642 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -332,8 +332,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
}
}
-static void
-vc4_atomic_complete_commit(struct drm_atomic_state *state)
+static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -357,10 +356,6 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
if (vc4->hvs->hvs5)
clk_set_min_rate(hvs->core_clk, 5);
- drm_atomic_helper_wait_for_fences(dev, state, false);
-
- drm_atomic_helper_wait_for_dependencies(state);
-
old_hvs_state = vc4_hvs_get_old_global_state(state);
if (!old_hvs_state)
return;
@@ -412,20 +407,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
- drm_atomic_helper_commit_cleanup_done(state);
-
if (vc4->hvs->hvs5)
clk_set_min_rate(hvs->core_clk, 0);
-
- drm_atomic_state_put(state);
-}
-
-static void commit_work(struct work_struct *work)
-{
- struct drm_atomic_state *state = container_of(work,
- struct drm_atomic_state,
- commit_work);
- vc4_atomic_complete_commit(state);
}
static int vc4_atomic_commit_setup(struct drm_atomic_state *state)
@@ -458,94 +441,6 @@ static int vc4_atomic_commit_setup(struct drm_atomic_state
*state)
return 0;
}
-/**
- * vc4_atomic_commit - commit validated state object
- * @dev: DRM device
- * @state: the driver state object
- * @nonblock: nonblocking commit
- *
- * This function commits a with drm_atomic_helper_check() pre-validated state
- * object. This can still fail when e.g. the framebuffer reservation fails. For
- * now this doesn't implement asynchronous commits.
- *
- * RETURNS
- * Zero for success or -errno.
- */
-static int vc4_atomic_commit(struct drm_device *dev,
-struct drm_atomic_state *state,
-bool nonblock)
-{
- int ret;
-
- if (state->async_update) {
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- drm_atomic_helper_async_commit(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-
- return 0;
- }
-
- /* We know for sure we don't want an async update here. Set
-* state->legacy_cursor_update to false to prevent
-* drm_atomic_helper_setup_commit() from auto-completing
-* commit->flip_done.
-*/
- state->legacy_cursor_update = false;
- ret = drm_atomic_helper_setup_commit(state, nonblock);
- if (ret)
- return ret;
-
- INIT_WORK(&state->commit_work, commit_work);
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- if (!nonblock) {
- ret = drm_atomic_helper_wait_for_fences(dev, state, true);
- if (ret) {
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
- }
- }
-
- /*
-* This is the point of no return - everything below never fails except
-* when the hw goes bonghits. Which means we can commit the new state on
-* the software side now.
-*/
-
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since com
Re: [RFC PATCH 1/2] drm: RFC add choice to use dynamic debug in drm-debug
On Fri, Dec 4, 2020 at 8:42 AM Ville Syrjälä wrote: > > On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote: > > drm's debug system uses distinct categories of debug messages, mapped > > to bits in drm.debug. Currently, code does a lot of unlikely bit-mask > > checks on drm.debug (in drm_debug_enabled), we can use dynamic debug > > instead, and get all that jump_label goodness. > > whatis jump_label? Sorry, I should have at least capitalized that, and spelled it differently kernel/Makefile 118:obj-$(CONFIG_JUMP_LABEL) += jump_label.o it is the hot-patching substrate underneath it all. static-key, static-call, etc? dynamic-debug uses static-key directly. > > One thing that bugs me about the current drm_dbg() stuff is that > it's a function, and thus we pay the cost of setting up the > arguments even when debugs are not enabled. I played around a bit > with making it a macro again with the unlikely bit check moved > into the macro. That did seem to make some of the asm a bit nicer > where the debug stuff got shoved out the main codepath, but > it did result in a slight net increase in code size. What I didn't > have time to do is check if this has any measurable speed effect > on eg. TEST_ONLY commits. > > And while doing that I started to ponder if we could use something > like the alternate() instruction stuff to patch the code at runtime > in order to turn all those debug checks into nops when debugging > is not enabled. But I couldn't immediately find any generic > infrastructure for it. So now I wonder if this jump_label is something > like that? > this is the droid youre looking for ;-) > > > -- > Ville Syrjälä > Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Allow drm_fourcc.h without including drm.h
The typedefs might also conflict on Linux if DRM_FOURCC_STANDALONE is enabled with whatever LInux declared __u32/__u64 as, but I think the implication is that once DRM_FOURCC_STANDALONE has been declared, that's kind of a promise not to include drm.h. I'm fine with this, but I'm not married to it if someone has a problem where they want to define DRM_FOURCC_STANDALONE, but also can't avoid including drm.h for some reason. On Fri, Dec 4, 2020 at 12:53 AM Simon Ser wrote: > On Friday, December 4, 2020 5:53 AM, James Park > wrote: > > > +#ifdef DRM_FOURCC_STANDALONE > > +#include > > > > +typedef uint32_t __u32; > > +typedef uint64_t __u64; > > +#else > > #include "drm.h" > > +#endif > > C11 allows duplicate typedefs, but older versions of the standard > don't AFAIK. If this is a concern, a solution would be to guard the > typedefs. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver
Add myself as the maintainer of the i.MX8qxp DPU DRM driver. Signed-off-by: Liu Ying --- v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 970d9ce..dee4586 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5834,6 +5834,15 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE i.MX8QXP +M: Liu Ying +L: dri-devel@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml +F: drivers/gpu/drm/imx/dpu/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-devel@lists.freedesktop.org -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/7] drm/vc4: kms: Remove async modeset semaphore
Now that we have proper ordering guaranteed by the previous patch, the
semaphore is redundant and can be removed.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 -
drivers/gpu/drm/vc4/vc4_drv.h | 2 --
drivers/gpu/drm/vc4/vc4_kms.c | 24 ++--
3 files changed, 2 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 482219fb4db2..c469594a2d3a 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -690,7 +690,6 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
container_of(cb, struct vc4_async_flip_state, cb);
struct drm_crtc *crtc = flip_state->crtc;
struct drm_device *dev = crtc->dev;
- struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane = crtc->primary;
vc4_plane_async_set_fb(plane, flip_state->fb);
@@ -722,8 +721,6 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
}
kfree(flip_state);
-
- up(&vc4->async_modeset);
}
/* Implements async (non-vblank-synced) page flips.
@@ -738,7 +735,6 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
uint32_t flags)
{
struct drm_device *dev = crtc->dev;
- struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane = crtc->primary;
int ret = 0;
struct vc4_async_flip_state *flip_state;
@@ -767,15 +763,6 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
flip_state->crtc = crtc;
flip_state->event = event;
- /* Make sure all other async modesetes have landed. */
- ret = down_interruptible(&vc4->async_modeset);
- if (ret) {
- drm_framebuffer_put(fb);
- vc4_bo_dec_usecnt(bo);
- kfree(flip_state);
- return ret;
- }
-
/* Save the current FB before it's replaced by the new one in
* drm_atomic_set_fb_for_plane(). We'll need the old FB in
* vc4_async_page_flip_complete() to decrement the BO usecnt and keep
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c5f2944d5bc6..4dcef3140dff 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -215,8 +215,6 @@ struct vc4_dev {
struct work_struct reset_work;
} hangcheck;
- struct semaphore async_modeset;
-
struct drm_modeset_lock ctm_state_lock;
struct drm_private_obj ctm_manager;
struct drm_private_obj hvs_channels;
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index fa40c44eb770..ffbfdde55fff 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -418,8 +418,6 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
clk_set_min_rate(hvs->core_clk, 0);
drm_atomic_state_put(state);
-
- up(&vc4->async_modeset);
}
static void commit_work(struct work_struct *work)
@@ -477,26 +475,17 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct drm_atomic_state *state,
bool nonblock)
{
- struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
if (state->async_update) {
- ret = down_interruptible(&vc4->async_modeset);
- if (ret)
- return ret;
-
ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret) {
- up(&vc4->async_modeset);
+ if (ret)
return ret;
- }
drm_atomic_helper_async_commit(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
- up(&vc4->async_modeset);
-
return 0;
}
@@ -512,21 +501,14 @@ static int vc4_atomic_commit(struct drm_device *dev,
INIT_WORK(&state->commit_work, commit_work);
- ret = down_interruptible(&vc4->async_modeset);
- if (ret)
- return ret;
-
ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret) {
- up(&vc4->async_modeset);
+ if (ret)
return ret;
- }
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret) {
drm_atomic_helper_cleanup_planes(dev, state);
- up(&vc4->async_modeset);
return ret;
}
}
@@ -1008,8 +990,6 @@ int vc4_kms_load(struct drm_device *dev)
vc4->load_tracker_enabled = true;
}
- sema_init(&vc4->async_modeset, 1);
-
/* Set support for vblank irq fast disable, before drm_vblank_init() */
dev->vblank_disable_immediate = true;
--
2.28.0
___
dri-
[PATCH v3 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
This patch adds bindings for i.MX8qxp/qm Display Processing Unit. Signed-off-by: Liu Ying --- Note that this depends on the 'two cell binding' clock patch set which has already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h won't be found. v2->v3: * No change. v1->v2: * Fix yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the display controller subsystem spec does say that they exist. * Use new dt binding way to add clocks in the example. * Trivial tweaks for the example. .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 + 1 file changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml new file mode 100644 index ..045df5a --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml @@ -0,0 +1,416 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Processing Unit + +maintainers: + - Liu Ying + +description: | + The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two + main components that include a blit engine for 2D graphics accelerations + and a display controller for display output processing, as well as a command + sequencer. + +properties: + compatible: +oneOf: + - const: fsl,imx8qxp-dpu + - const: fsl,imx8qm-dpu + + reg: +maxItems: 1 + + interrupts: +items: + - description: | + store9 shadow load interrupt(blit engine) + - description: | + store9 frame complete interrupt(blit engine) + - description: | + store9 sequence complete interrupt(blit engine) + - description: | + extdst0 shadow load interrupt + (display controller, content stream 0) + - description: | + extdst0 frame complete interrupt + (display controller, content stream 0) + - description: | + extdst0 sequence complete interrupt + (display controller, content stream 0) + - description: | + extdst4 shadow load interrupt + (display controller, safety stream 0) + - description: | + extdst4 frame complete interrupt + (display controller, safety stream 0) + - description: | + extdst4 sequence complete interrupt + (display controller, safety stream 0) + - description: | + extdst1 shadow load interrupt + (display controller, content stream 1) + - description: | + extdst1 frame complete interrupt + (display controller, content stream 1) + - description: | + extdst1 sequence complete interrupt + (display controller, content stream 1) + - description: | + extdst5 shadow load interrupt + (display controller, safety stream 1) + - description: | + extdst5 frame complete interrupt + (display controller, safety stream 1) + - description: | + extdst5 sequence complete interrupt + (display controller, safety stream 1) + - description: | + disengcfg0 shadow load interrupt + (display controller, display stream 0) + - description: | + disengcfg0 frame complete interrupt + (display controller, display stream 0) + - description: | + disengcfg0 sequence complete interrupt + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt0 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt1 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt2 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt3 + (display controller, display stream 0) + - description: | + signature0 shadow load interrupt + (display controller, display stream 0) + - description: | + signature0 measurement valid interrupt + (display controller, display stream 0) + - description: | + signature0 error condition interrupt + (display controller, display stream 0) + - description: | + disengcfg1 shadow load interrupt + (display controller, display stream 1) + - description: | + disengcfg1 frame complete interrupt + (display controller, display stream 1) + - description: | + disengcfg1 sequence complete interrupt + (display controller, display stream 1) + - descriptio
[RFC PATCH v1 06/12] omap: Replace strstarts() by str_has_prefix().
From: Francis Laniel
The two functions indicates if a string begins with a given prefix.
The only difference is that strstarts() returns a bool while str_has_prefix()
returns the length of the prefix if the string begins with it or 0 otherwise.
Signed-off-by: Francis Laniel
---
drivers/gpu/drm/omapdrm/dss/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gpu/drm/omapdrm/dss/base.c
index c7650a7c155d..dd3d466293d1 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -350,7 +350,7 @@ static bool omapdss_component_is_loaded(struct
omapdss_comp_node *comp)
{
if (comp->dss_core_component)
return true;
- if (!strstarts(comp->compat, "omapdss,"))
+ if (!str_has_prefix(comp->compat, "omapdss,"))
return true;
if (omapdss_device_is_registered(comp->node))
return true;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 04/10] memory: tegra124-emc: Make driver modular
04.12.2020 19:41, Thierry Reding пишет:
...
>> +bool tegra124_clk_emc_driver_available(struct clk_hw *hw)
>> +{
>> +struct tegra_clk_emc *tegra = container_of(hw, struct tegra_clk_emc,
>> hw);
>> +
>> +return tegra->prepare_timing_change && tegra->complete_timing_change;
>> +}
>
> This looks a bit hackish and I prefer the way this was done for
> Tegra210.
I may have an opposite opinion :)
> But that's mostly an implementation detail and we can always
> restructure this if we want to.
This is true. I'm not saying that the current v11 variant is absolutely
ideal, but it should be good enough for the starter (IMO) and actually I
don't have any ideas right about what could be done better.
>> diff --git a/drivers/clk/tegra/clk-tegra124.c
>> b/drivers/clk/tegra/clk-tegra124.c
>> index e931319dcc9d..934520aab6e3 100644
>> --- a/drivers/clk/tegra/clk-tegra124.c
>> +++ b/drivers/clk/tegra/clk-tegra124.c
>> @@ -1500,6 +1500,26 @@ static void __init tegra124_132_clock_init_pre(struct
>> device_node *np)
>> writel(plld_base, clk_base + PLLD_BASE);
>> }
>>
>> +static struct clk *tegra124_clk_src_onecell_get(struct of_phandle_args
>> *clkspec,
>> +void *data)
>> +{
>> +struct clk_hw *hw;
>> +struct clk *clk;
>> +
>> +clk = of_clk_src_onecell_get(clkspec, data);
>> +if (IS_ERR(clk))
>> +return clk;
>> +
>> +hw = __clk_get_hw(clk);
>> +
>> +if (clkspec->args[0] == TEGRA124_CLK_EMC) {
>> +if (!tegra124_clk_emc_driver_available(hw))
>> +return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +return clk;
>> +}
>
> Hm... why exactly do we need this? On Tegra210 and later, the EMC driver
> is the only consumer of the EMC clock and since it also provides some of
> the necessary parts to scale the EMC clock, that's a chicken and egg
> problem.
The T124 EMC driver has an existing active user for the EMC clock, the
devfreq/actmon driver which watches and drives the EMC clock rate. The
EMC clock shan't be requested by the devfreq driver until EMC driver is
ready, the only sensible way to achieve this is implemented by this patch.
The devfreq driver doesn't support T210 (yet?) and you should witness
the problem if you'll try to implement the T210 support.
> I'm not sure I fully understand how this is supposed to work
> here and why we can't do this in a similar way than Tegra210.
The CCF returns -EPROBE_DEFER for clk_get() only until clock provider is
registered, otherwise it returns a dummy/stub clock once provider is
available and clk (of the provider) isn't registered. The CCF provider
for the EMC clock is the tegra-clk driver, not the EMC driver.
Once clk_get() is invoked by a clk user, the CCF performs the clk lookup
using the DT specifier and this lookup is aborted with a -EPROBE_DEFER
from the clk_src_onecell_get() callback if EMC driver isn't loaded yet.
I don't think that there are any other variants to achieve this behaviour.
I also prefer to have a clean separation of the clk and EMC drivers
because this is a much more expressive variant than mixing drivers
together in obscure way. The pre-T210 EMC drivers don't need to touch
clk registers for programming of the memory timings, hence those EMC
drivers are in a bit better position than the T210 driver.
The T210 EMC driver also could have a cleaner separation by using a
special tegra-clk API for the clk/EMC functions, instead of shoving a
raw clk IO pointer to the EMC driver. It feels like I was already
suggesting this about a half-year ago, before the T210 driver was merged.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/vc4: Simplify a bit the global atomic_check
When we can't allocate a new channel, we can simply return instead of
having to handle both cases, and that simplifies a bit the code.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba310c0ab5f6..8937eb0b751d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -794,6 +794,7 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
to_vc4_crtc_state(new_crtc_state);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
unsigned int matching_channels;
+ unsigned int channel;
/* Nothing to do here, let's skip it */
if (old_crtc_state->enable == new_crtc_state->enable)
@@ -834,14 +835,12 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
* but it works so far.
*/
matching_channels = hvs_new_state->unassigned_channels &
vc4_crtc->data->hvs_available_channels;
- if (matching_channels) {
- unsigned int channel = ffs(matching_channels) - 1;
-
- new_vc4_crtc_state->assigned_channel = channel;
- hvs_new_state->unassigned_channels &= ~BIT(channel);
- } else {
+ if (!matching_channels)
return -EINVAL;
- }
+
+ channel = ffs(matching_channels) - 1;
+ new_vc4_crtc_state->assigned_channel = channel;
+ hvs_new_state->unassigned_channels &= ~BIT(channel);
}
return 0;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..91e9472
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+ fetches display data before the display pipeline needs the data to drive
+ pixels in the active display region. This data is transformed, or resolved,
+ from a variety of tiled buffer formats into linear format, if needed.
+ The DPR works with a double bank memory structure. This memory structure is
+ implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+ as A and B. Each bank is either 4 or 8 lines high depending on the source
+ frame buffer format.
+
+properties:
+ compatible:
+oneOf:
+ - const: fsl,imx8qxp-dpr-channel
+ - const: fsl,imx8qm-dpr-channel
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: apb clock
+ - description: b clock
+ - description: rtram clock
+
+ clock-names:
+items:
+ - const: apb
+ - const: b
+ - const: rtram
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+ fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+ associated with this DPRC instance.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,sc-resource
+ - fsl,prgs
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <&dc0_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <&dc0_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <&dc0_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <&dc0_prg4>, <&dc0_prg5>;
+power-domains = <&pd IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm/vc4: kms: Wait on previous FIFO users before a commit
If we're having two subsequent, non-blocking, commits on two different
CRTCs that share no resources, there's no guarantee on the order of
execution of both commits.
However, the second one will consider the first one as the old state,
and will be in charge of freeing it once that second commit is done.
If the first commit happens after that second commit, it might access
some resources related to its state that has been freed, resulting in a
use-after-free bug.
The standard DRM objects are protected against this, but our HVS private
state isn't so let's make sure we wait for all the previous FIFO users
to finish their commit before going with our own.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 123 +-
1 file changed, 122 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 8937eb0b751d..fdd698df5fbe 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -40,6 +40,11 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
drm_private_state *priv)
struct vc4_hvs_state {
struct drm_private_state base;
unsigned int unassigned_channels;
+
+ struct {
+ unsigned in_use: 1;
+ struct drm_crtc_commit *pending_commit;
+ } fifo_state[HVS_NUM_CHANNELS];
};
static struct vc4_hvs_state *
@@ -182,6 +187,32 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct
drm_atomic_state *state)
VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
}
+static struct vc4_hvs_state *
+vc4_hvs_get_new_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_new_private_obj_state(state,
&vc4->hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
+static struct vc4_hvs_state *
+vc4_hvs_get_old_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_old_private_obj_state(state,
&vc4->hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
static struct vc4_hvs_state *
vc4_hvs_get_global_state(struct drm_atomic_state *state)
{
@@ -308,8 +339,10 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_hvs *hvs = vc4->hvs;
+ struct drm_crtc_state *old_crtc_state;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+ struct vc4_hvs_state *old_hvs_state;
int i;
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -329,6 +362,36 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
drm_atomic_helper_wait_for_dependencies(state);
+ old_hvs_state = vc4_hvs_get_old_global_state(state);
+ if (!old_hvs_state)
+ return;
+
+ for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
+ struct vc4_crtc_state *vc4_crtc_state =
+ to_vc4_crtc_state(old_crtc_state);
+ struct drm_crtc_commit *commit;
+ unsigned int channel = vc4_crtc_state->assigned_channel;
+ unsigned long done;
+
+ if (channel == VC4_HVS_CHANNEL_DISABLED)
+ continue;
+
+ if (!old_hvs_state->fifo_state[channel].in_use)
+ continue;
+
+ commit = old_hvs_state->fifo_state[i].pending_commit;
+ if (!commit)
+ continue;
+
+ done = wait_for_completion_timeout(&commit->hw_done, 10 * HZ);
+ if (!done)
+ drm_err(dev, "Timed out waiting for hw_done\n");
+
+ done = wait_for_completion_timeout(&commit->flip_done, 10 * HZ);
+ if (!done)
+ drm_err(dev, "Timed out waiting for flip_done\n");
+ }
+
drm_atomic_helper_commit_modeset_disables(dev, state);
vc4_ctm_commit(vc4, state);
@@ -368,6 +431,36 @@ static void commit_work(struct work_struct *work)
vc4_atomic_complete_commit(state);
}
+static int vc4_atomic_commit_setup(struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct vc4_hvs_state *hvs_state;
+ struct drm_crtc *crtc;
+ unsigned int i;
+
+ hvs_state = vc4_hvs_get_new_global_state(state);
+ if (!hvs_state)
+ return -EINVAL;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ struct vc4_crtc_state *vc4_crtc_state =
+ to_vc4_crtc_state(crtc_state);
+
[PATCH v2 1/7] drm: Introduce an atomic_commit_setup function
Private objects storing a state shared across all CRTCs need to be
carefully handled to avoid a use-after-free issue.
The proper way to do this to track all the commits using that shared
state and wait for the previous commits to be done before going on with
the current one to avoid the reordering of commits that could occur.
However, this commit setup needs to be done after
drm_atomic_helper_setup_commit(), because before the CRTC commit
structure hasn't been allocated before, and before the workqueue is
scheduled, because we would be potentially reordered already otherwise.
That means that drivers currently have to roll their own
drm_atomic_helper_commit() function, even though it would be identical
if not for the commit setup.
Let's introduce a hook to do so that would be called as part of
drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
Suggested-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +
include/drm/drm_modeset_helper_vtables.h | 21 +
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f9170b4b22e7..f754e21b96eb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2034,6 +2034,9 @@ crtc_or_fake_commit(struct drm_atomic_state *state,
struct drm_crtc *crtc)
* should always call this function from their
* &drm_mode_config_funcs.atomic_commit hook.
*
+ * Drivers that need to extend the commit setup to private objects can use the
+ * &drm_mode_config_helper_funcs.atomic_commit_setup hook.
+ *
* To be able to use this support drivers need to use a few more helper
* functions. drm_atomic_helper_wait_for_dependencies() must be called before
* actually committing the hardware state, and for nonblocking commits this
call
@@ -2077,8 +2080,11 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
struct drm_plane *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_crtc_commit *commit;
+ const struct drm_mode_config_helper_funcs *funcs;
int i, ret;
+ funcs = state->dev->mode_config.helper_private;
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
commit = kzalloc(sizeof(*commit), GFP_KERNEL);
if (!commit)
@@ -2155,6 +2161,9 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
new_plane_state->commit = drm_crtc_commit_get(commit);
}
+ if (funcs && funcs->atomic_commit_setup)
+ return funcs->atomic_commit_setup(state);
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 4efec30f8bad..0ebb3f191bbc 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1406,6 +1406,27 @@ struct drm_mode_config_helper_funcs {
* drm_atomic_helper_commit_tail().
*/
void (*atomic_commit_tail)(struct drm_atomic_state *state);
+
+ /**
+* @atomic_commit_setup:
+*
+* This hook is used by the default atomic_commit() hook implemented in
+* drm_atomic_helper_commit() together with the nonblocking helpers (see
+* drm_atomic_helper_setup_commit()) to extend the DRM commit setup. It
+* is not used by the atomic helpers.
+*
+* This function is called at the end of
+* drm_atomic_helper_setup_commit(), so once the commit has been
+* properly setup across the generic DRM object states. It allows
+* drivers to do some additional commit tracking that isn't related to a
+* CRTC, plane or connector, tracked in a &drm_private_obj structure.
+*
+* Note that the documentation of &drm_private_obj has more details on
+* how one should implement this.
+*
+* This hook is optional.
+*/
+ int (*atomic_commit_setup)(struct drm_atomic_state *state);
};
#endif
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi, This patch set introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support. DPU is comprised of a blit engine for 2D graphics, a display controller and a command sequencer. Outside of DPU, optional prefetch engines can fetch data from memory prior to some DPU fetchunits of blit engine and display controller. The pre-fetchers support linear formats and Vivante GPU tile formats. Reference manual can be found at: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM This patch set adds kernel modesetting support for the display controller part. It supports two CRTCs per display controller, several planes, prefetch engines and some properties of CRTC and plane. Currently, the registers of the controller is accessed without command sequencer involved, instead just by using CPU. DRM connectors would be created from the DPU KMS driver. If people want to try this series with i.MX8qxp, clock patches can be found at: https://www.spinics.net/lists/arm-kernel/msg859763.html and, power domain patches have already landed in Shawn's i.MX for-next git branch. This version drops the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. It depends on the below series to do basic conversions for the platforms which has not landed yet: https://www.spinics.net/lists/linux-mmc/msg61965.html I will send other patch sets to add downstream bridges(embedded in i.MX8qxp) to support LVDS displays. A brief look at the pipe: prefetch eng -> DPU -> pixel combiner -> pixel link -> pixel to DPI(pxl2dpi) -> LVDS display bridge(LDB) Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines. Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver uses it. Patch 5 introduces the DPU DRM support. Patch 6 updates MAINTAINERS. Welcome comments, thanks. v2->v3: * Fix DPU DRM driver build warnings which are Reported-by: kernel test robot . * Add a missing blank line in include/drm/drm_atomic.h. v1->v2: * Test this patch set also with i.MX8qm LVDS displays. * Drop the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. This depends on a not-yet-landed patch set to do basic conversions for the platforms. * Fix dt binding yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's dt binding documentation. * Use new dt binding way to add clocks in the dt binding examples. * Address several comments from Laurentiu on the DPU DRM patch. Liu Ying (6): dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state drm/imx: Introduce i.MX8qm/qxp DPU DRM MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++ .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 + .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++ MAINTAINERS| 9 + drivers/gpu/drm/imx/Kconfig| 1 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dpu/Kconfig| 10 + drivers/gpu/drm/imx/dpu/Makefile | 10 + drivers/gpu/drm/imx/dpu/dpu-constframe.c | 170 drivers/gpu/drm/imx/dpu/dpu-core.c | 881 drivers/gpu/drm/imx/dpu/dpu-crtc.c | 926 + drivers/gpu/drm/imx/dpu/dpu-crtc.h | 62 ++ drivers/gpu/drm/imx/dpu/dpu-disengcfg.c| 114 +++ drivers/gpu/drm/imx/dpu/dpu-dprc.c | 721 drivers/gpu/drm/imx/dpu/dpu-dprc.h | 40 + drivers/gpu/drm/imx/dpu/dpu-drv.c | 297 +++ drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + drivers/gpu/drm/imx/dpu/dpu-extdst.c | 296 +++ drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 291 +++ drivers/gpu/drm/imx/dpu/dpu-fetcheco.c | 221 + drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c | 151 drivers/gpu/drm/imx/dpu/dpu-fetchunit.c| 609 ++ drivers/gpu/drm/imx/dpu/dpu-fetchunit.h| 191 + drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c| 247 ++ drivers/gpu/drm/imx/dpu/dpu-framegen.c | 392 + drivers/gpu/drm/imx/dpu/dpu-gammacor.c | 220 + drivers/gpu/drm/imx/dpu/dpu-hscaler.c | 272 ++ drivers/gpu/drm/imx/dpu/dpu-kms.c | 543 drivers/gpu/drm/imx/dpu/dpu-kms.h | 23 + drivers/gpu/drm/imx/dpu/dpu-layerblend.c | 345 drivers/gpu/drm/imx/dpu/dpu-plane.c| 703 drivers/gpu/drm/imx/dpu/dpu-plane.h| 56 ++ drivers/gpu/drm/imx/dpu/dpu-p
[PATCH v2 2/7] drm: Document use-after-free gotcha with private objects
The private objects have a gotcha that could result in a use-after-free,
make sure it's properly documented.
Reviewed-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
include/drm/drm_atomic.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d07c851d255b..5d34c1df03f3 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -248,6 +248,26 @@ struct drm_private_state_funcs {
*drm_dev_register()
* 2/ all calls to drm_atomic_private_obj_fini() must be done after calling
*drm_dev_unregister()
+ *
+ * If that private object is used to store a state shared by multiple
+ * CRTCs, proper care must be taken to ensure that non-blocking commits are
+ * properly ordered to avoid a use-after-free issue.
+ *
+ * Indeed, assuming a sequence of two non-blocking &drm_atomic_commit on two
+ * different &drm_crtc using different &drm_plane and &drm_connector, so with
no
+ * resources shared, there's no guarantee on which commit is going to happen
+ * first. However, the second &drm_atomic_commit will consider the first
+ * &drm_private_obj its old state, and will be in charge of freeing it whenever
+ * the second &drm_atomic_commit is done.
+ *
+ * If the first &drm_atomic_commit happens after it, it will consider its
+ * &drm_private_obj the new state and will be likely to access it, resulting in
+ * an access to a freed memory region. Drivers should store (and get a
reference
+ * to) the &drm_crtc_commit structure in our private state in
+ * &drm_mode_config_helper_funcs.atomic_commit_setup, and then wait for that
+ * commit to complete as the first step of
+ * &drm_mode_config_helper_funcs.atomic_commit_tail, similar to
+ * drm_atomic_helper_wait_for_dependencies().
*/
struct drm_private_obj {
/**
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote: > On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote: >> Now that kstat_irqs is exported, get rid of count_interrupts in >> i915_pmu.c > > May I ask why this has been merged in the first place? > > Nothing in a driver has ever to fiddle with the internals of an irq > descriptor. We have functions for properly accessing them. Just because > C allows to fiddle with everything is not a justification. If the > required function is not exported then adding the export with a proper > explanation is not asked too much. > > Also this lacks protection or at least a comment why this can be called > safely and is not subject to a concurrent removal of the irq descriptor. > The same problem exists when calling kstat_irqs(). It's even documented > at the top of the function. And as pointed out vs. that TPM thing this really could have been a trivial i915->irqs++; in the interrupt handler and a read of that instead of iterating over all possible cpus and summing it up. Oh well... Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] irq: export kstat_irqs
On Sun, Dec 06 2020 at 09:40, James Bottomley wrote: > On Sun, 2020-12-06 at 17:40 +0100, Thomas Gleixner wrote: >> On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote: >> > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote: >> > > To try and detect potential interrupt storms that >> > > have been occurring with tpm_tis devices it was suggested >> > > to use kstat_irqs() to get the number of interrupts. >> > > Since tpm_tis can be built as a module it needs kstat_irqs >> > > exported. >> > >> > I think you should also have a paragraph explicitly stating that >> > i915_pmu.c contains a duplicate of kstat_irqs() because it is not >> > exported as of today. It adds a lot more weight to this given that >> > there is already existing mainline usage (kind of). >> >> It's abusage and just the fact that it exists is not an argument by >> itself. > > What we want is a count of the interrupts to see if we're having an > interrupt storm from the TPM device (some seem to be wired to fire the > interrupt even when there's no event to warrant it). Since > kstat_irqs_user() does the correct RCU locking, should we be using that > instead? If we need to export it, yes. But I still have to understand the value. See my other reply. Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> Now that kstat_irqs is exported, get rid of count_interrupts in
> i915_pmu.c
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer
> *hrtimer)
> return HRTIMER_RESTART;
> }
>
> -static u64 count_interrupts(struct drm_i915_private *i915)
> -{
> - /* open-coded kstat_irqs() */
> - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> - u64 sum = 0;
> - int cpu;
> -
> - if (!desc || !desc->kstat_irqs)
> - return 0;
> -
> - for_each_possible_cpu(cpu)
> - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> -
> - return sum;
> -}
May I ask why this has been merged in the first place?
Nothing in a driver has ever to fiddle with the internals of an irq
descriptor. We have functions for properly accessing them. Just because
C allows to fiddle with everything is not a justification. If the
required function is not exported then adding the export with a proper
explanation is not asked too much.
Also this lacks protection or at least a comment why this can be called
safely and is not subject to a concurrent removal of the irq descriptor.
The same problem exists when calling kstat_irqs(). It's even documented
at the top of the function.
Thanks,
tglx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/drv: switch to using devm_add_action_or_reset()
switch to using devm_add_action_or_reset() instead of devm_add_action. Signed-off-by: Tian Tao --- drivers/gpu/drm/drm_drv.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 7343038..b92f7fd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -675,11 +675,8 @@ static int devm_drm_dev_init(struct device *parent, if (ret) return ret; - ret = devm_add_action(parent, devm_drm_dev_init_release, dev); - if (ret) - devm_drm_dev_init_release(dev); - - return ret; + return devm_add_action_or_reset(parent, + devm_drm_dev_init_release, dev); } void *__devm_drm_dev_alloc(struct device *parent, -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Allow drm_fourcc.h without including drm.h
I suppose I should do this to avoid fighting with #ifdef DRM_FOURCC_STANDALONE #if defined(__linux__) #include #else #include typedef uint32_t __u32; typedef uint64_t __u64; #endif #else #include "drm.h" #endif I'll wait for more feedback before updating the patch though. On Fri, Dec 4, 2020 at 1:47 AM James Park wrote: > The typedefs might also conflict on Linux if DRM_FOURCC_STANDALONE is > enabled with whatever LInux declared __u32/__u64 as, but I think the > implication is that once DRM_FOURCC_STANDALONE has been declared, that's > kind of a promise not to include drm.h. > > I'm fine with this, but I'm not married to it if someone has a problem > where they want to define DRM_FOURCC_STANDALONE, but also can't avoid > including drm.h for some reason. > > On Fri, Dec 4, 2020 at 12:53 AM Simon Ser wrote: > >> On Friday, December 4, 2020 5:53 AM, James Park >> wrote: >> >> > +#ifdef DRM_FOURCC_STANDALONE >> > +#include >> > >> > +typedef uint32_t __u32; >> > +typedef uint64_t __u64; >> > +#else >> > #include "drm.h" >> > +#endif >> >> C11 allows duplicate typedefs, but older versions of the standard >> don't AFAIK. If this is a concern, a solution would be to guard the >> typedefs. >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon 2/2] drm/hisilicon: Delete unused local parameters
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d631f82..772f58e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,12 +251,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
- dev->dev_private = NULL;
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> @@ -715,9 +717,23 @@ static irqreturn_t tis_int_handler(int dummy, void
> *dev_id)
> {
> struct tpm_chip *chip = dev_id;
> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
> + static bool check_storm = true;
> + static unsigned int check_start;
So this assumes that there can't be two TPMs which is probably true, but
everything else in this driver has stuff in tpm_tis_data per device.
> u32 interrupt;
> int i, rc;
>
> + if (unlikely(check_storm)) {
> + if (!check_start) {
> + check_start = jiffies_to_msecs(jiffies);
Yuck. I had to read that twice to figure out that it's correct vs. the
truncation of the result to unsigned int. You can spare that conversion
by simply doing
unsigned long end_of_check = jiffies + HZ / 2;
and then the check becomes
time_before(jiffies, end_of_check)
> + } else if ((kstat_irqs(priv->irq) > 1000) &&
> +(jiffies_to_msecs(jiffies) - check_start < 500)) {
I assume you can't call disable_irq_nosync() here, but shouldn't this
shut up the interrupt at the TPM level right here?
> + check_storm = false;
> + schedule_work(&priv->storm_work);
> + } else if (jiffies_to_msecs(jiffies) - check_start >= 500) {
> + check_storm = false;
> + }
> + }
So back to kstat_irqs(). As this needs two extra variables anyway:
init()
priv->irq_check = 1;
priv->end_check = 0;
isr()
if (unlikely(priv->irq_check)) {
if (!priv->end_check) {
priv->end_check = jiffies + HZ / 2;
} else if (time_before(jiffies, priv->end_check)) {
if (priv->irq_check++ > 1000)
schedule_work(...);
} else {
priv->irq_check = 0;
}
}
Hmm? I still need to see an argument for an kstat_irqs() export being
superior.
Though I wonder whether such an infrastructure should be provided in the
irq core. Let me think about it.
Just as a side note. I was looking at tpm_tis_probe_irq_single() and
that function is leaking the interrupt request if any of the checks
afterwards fails, except for the final interrupt probe check which does
a cleanup. That means on fail before that the interrupt handler stays
requested up to the point where the module is removed. If that's a
shared interrupt and some other device is active on the same line, then
each interrupt from that device will call into the TPM code. Something
like the below is needed.
Also the X86 autoprobe mechanism is interesting:
if (IS_ENABLED(CONFIG_X86))
for (i = 3; i <= 15; i++)
if (!tpm_tis_probe_irq_single(chip, intmask, 0, i))
return;
The third argument is 'flags' which is handed to request_irq(). So that
won't ever be able to probe a shared interrupt. But if an interrupt
number > 0 is handed to tpm_tis_core_init() the interrupt is requested
with IRQF_SHARED. Same issue when the chip has an interrupt number in
the register. It's also requested exclusive which is pretty likely
to fail on ancient x86 machines.
The vast amount of comments didn't help to figure out what the reasoning
is.
Thanks,
tglx
---
drivers/char/tpm/tpm_tis_core.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -782,26 +782,26 @@ static int tpm_tis_probe_irq_single(stru
rc = tpm_tis_read8(priv, TPM_INT_VECTOR(priv->locality),
&original_int_vec);
if (rc < 0)
- return rc;
+ goto fail;
rc = tpm_tis_write8(priv, TPM_INT_VECTOR(priv->locality), irq);
if (rc < 0)
- return rc;
+ goto fail;
rc = tpm_tis_read32(priv, TPM_INT_STATUS(priv->locality), &int_status);
if (rc < 0)
- return rc;
+ goto fail;
/* Clear all existing */
rc = tpm_tis_write32(priv, TPM_INT_STATUS(priv->locality), int_status);
if (rc < 0)
- return rc;
+ goto fail;
/* Turn on */
rc = tpm_tis_write32(priv, TPM_INT_ENABLE(priv->locality),
intmask | TPM_GLOBAL_INT_ENABLE);
if (rc < 0)
- return rc;
+ goto fail;
priv->irq_tested = false;
@@ -825,6 +825,10 @@ static int tpm_tis_probe_irq_single(stru
}
return 0;
+
+fail:
+ disable_interrupts(chip);
+ return rc;
}
/* Try to find the IRQ the TPM is using. This is for legacy x86 systems that
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.free
[PATCH drm/hisilicon 1/2] drm/hisilicon: Use managed mode-config init
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..d631f82 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,7 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
priv->mode_config_initialized = true;
dev->mode_config.min_width = 0;
@@ -125,14 +127,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +256,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 00/12] Replace strstarts() by str_has_prefix()
From: Francis Laniel
Hi.
First, I hope you are fine and the same for your relatives.
In this patch set, I replaced all calls to strstarts() by calls to
str_has_prefix().
Indeed, the kernel has two functions to test if a string begins with an other:
1. strstarts() which returns a bool, so 1 if the string begins with the prefix,
0 otherwise.
2. str_has_prefix() which returns the length of the prefix or 0.
str_has_prefix() was introduced later than strstarts(), in commit 495d714ad140
which also stated that str_has_prefix() should replace strstarts().
This is what this patch set does.
Concerning the patches, the modifications cover different areas of the kernel.
I compiled all of them and they compile smoothly.
Unfortunately, I did not test all of them, so here are the status of the patches
regarding test:
1. Tested with qemu-system-arm using insmod.
2. I do not have access to a bcm47xx MIPS CPU an qemu-system-mips does not
emulate this board.
3. Tested with qemu-system-x86_64 calling
crypto_alloc_skcipher("essiv(authenc(hmac(sha256),cbc(aes)),sha256)", 0, 0)
through LKDTM.
4. Tested with qemu-system-x86_64 using crypsetup.
5. I do not have access to a renesas board and I lack some context to test it
with qemu-system-arm.
6. I do not have access to an OMAP board and I lack some context to test it with
qemu-system-arm.
7. I did not find how to boot from the EFI_STUB with qemu. If you know how to
do, I would be happy to try running this code.
8. I ran qemu-system-x86_64 with a floppy disk attached but impossible to go
through this module code...
9. I do not have access to a bcm63xx MIPS CPU an qemu-system-mips does not
emulate this board.
10. Tested with qemu-system-x86_64 using insmod.
11. I do not have access to an AM335x or DA8xx platforms and I lack some context
to test it with qemu-system-arm.
If you see a way to improve the patches or if I did something wrong with the
mail do not hesitate to ask.
Best regards.
Francis Laniel (12):
arm: Replace strstarts() by str_has_prefix().
mips: Replace strstarts() by str_has_prefix().
crypto: Replace strstarts() by str_has_prefix().
device-mapper: Replace strstarts() by str_has_prefix().
renesas: Replace strstarts() by str_has_prefix().
omap: Replace strstarts() by str_has_prefix().
efi: Replace strstarts() by str_has_prefix().
ide: Replace strstarts() by str_has_prefix().
mips: Replace strstarts() by str_has_prefix().
module: Replace strstarts() by str_has_prefix().
musb: Replace strstarts() by str_has_prefix().
string.h: Remove strstarts().
arch/arm/kernel/module.c | 12 +--
arch/mips/bcm47xx/board.c | 4 ++--
arch/mips/bcm63xx/boards/board_bcm963xx.c | 2 +-
crypto/essiv.c| 2 +-
.../firmware/efi/libstub/efi-stub-helper.c| 2 +-
drivers/firmware/efi/libstub/gop.c| 10 +-
drivers/gpu/drm/omapdrm/dss/base.c| 2 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +-
drivers/ide/ide-floppy.c | 4 ++--
drivers/md/dm-crypt.c | 4 ++--
drivers/usb/musb/musb_cppi41.c| 4 ++--
drivers/usb/musb/musb_debugfs.c | 20 +--
include/linux/string.h| 10 --
kernel/module.c | 6 +++---
14 files changed, 37 insertions(+), 47 deletions(-)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/5] dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi
'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property.
Add it to rockchip,rk3066-hdmi.yaml to document that the
rk3066 HDMI TX also can be used to transmit some audio.
Signed-off-by: Johan Jonker
---
.../devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
index 4110d003c..585a8d3b9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
+++
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -42,6 +42,9 @@ properties:
description:
This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
+ "#sound-dai-cells":
+const: 0
+
ports:
type: object
@@ -101,6 +104,7 @@ examples:
pinctrl-names = "default";
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
ports {
#address-cells = <1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
I could adjust the block to look like this: #ifdef DRM_FOURCC_STANDALONE #if defined(__linux__) #include #else #include typedef uint32_t __u32; typedef uint64_t __u64; #endif #else #include "drm.h" #endif Alternatively, I could create a new common header to be included from both drm.h and drm_fourcc.h, drm_base_types.h or something like that: #ifdef DRM_FOURCC_STANDALONE #include "drm_base_types.h" #else #include "drm.h" #endif On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote: > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen wrote: > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > Daniel Vetter wrote: > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park > wrote: > > > > > > > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't > > > > intentional, right? Should I put all the integer types, or just the > > > > ones that are used in that file? > > > > > > Yeah that trailing _ just slipped in. And I'd just do the types > > > already used. I don't think anything else than __u32 (for drm fourcc) > > > and __u64 (for drm modifier) is needed. > > > > Hi, > > > > can that create conflicts if userspace first includes drm_fourcc.h and > > then drm.h? > > > > I would find it natural to userspace have generic headers including > > drm_fourcc.h and then DRM-specific C-files including drm.h as well > > (through libdrm headers). I think Weston might already do this. > > > > The generic userspace (weston) header would obviously #define > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as well. > > Hm yes that would break. I guess we could just include the linux types > header for this. And I guess on windows you'd need to have that from > somewhere. Or we just require that users of the standalone header pull > the right header or defines in first? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "xen: add helpers to allocate unpopulated memory"
This reverts commit 9e2369c06c8a181478039258a4598c1ddd2cadfa. On a Xen PV dom0, with NVME disk, this makes the dom0 crash when starting a domain. This looks like some bad interaction between xen-blkback and NVME driver, both using ZONE_DEVICE. Since the author is on leave now, revert the change until proper solution is developed. The specific crash message is: general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI CPU: 1 PID: 134 Comm: kworker/u12:2 Not tainted 5.9.9-1.qubes.x86_64 #1 Hardware name: LENOVO 20M9CTO1WW/20M9CTO1WW, BIOS N2CET50W (1.33 ) 01/15/2020 Workqueue: dm-thin do_worker [dm_thin_pool] RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Call Trace: nvme_queue_rq+0xa7/0x1a0 [nvme] __blk_mq_try_issue_directly+0x11d/0x1e0 ? add_wait_queue_exclusive+0x70/0x70 blk_mq_try_issue_directly+0x35/0xc0l[ blk_mq_submit_bio+0x58f/0x660 __submit_bio_noacct+0x300/0x330 process_shared_bio+0x126/0x1b0 [dm_thin_pool] process_cell+0x226/0x280 [dm_thin_pool] process_thin_deferred_cells+0x185/0x320 [dm_thin_pool] process_deferred_bios+0xa4/0x2a0 [dm_thin_pool]UX do_worker+0xcc/0x130 [dm_thin_pool] process_one_work+0x1b4/0x370 worker_thread+0x4c/0x310 ? process_one_work+0x370/0x370 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60< ret_from_fork+0x22/0x30 Modules linked in: loop snd_seq_dummy snd_hrtimer nf_tables nfnetlink vfat fat snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_soc_skl snd_soc_sst_ ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine elan_i2c snd_hda_codec_hdmi mei_hdcp iTCO_wdt intel_powerclamp intel_pmc_bxt ee1004 intel_rapl_msr iTCO_vendor _support joydev pcspkr intel_wmi_thunderbolt wmi_bmof thunderbolt ucsi_acpi idma64 typec_ucsi snd_hda_codec_realtek typec snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec thinkpad_acpi snd_hda_core ledtrig_audio int3403_ thermal snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi snd_timer processor_thermal_device mei_me cfg80211 intel_rapl_common snd e1000e mei int3400_thermal int340x_thermal_zone i2c_i801 acpi_thermal_rel soundcore intel_soc_dts_iosf i2c_s mbus rfkill intel_pch_thermal xenfs ip_tables dm_thin_pool dm_persistent_data dm_bio_prison dm_crypt nouveau rtsx_pci_sdmmc mmc_core mxm_wmi crct10dif_pclmul ttm crc32_pclmul crc32c_intel i915 ghash_clmulni_intel i2c_algo_bit serio_raw nvme drm_kms_helper cec xhci_pci nvme _core rtsx_pci xhci_pci_renesas drm xhci_hcd wmi video pinctrl_cannonlake pinctrl_intel xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn uinput ---[ end trace f8d47e4aa6724df4 ]--- RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Discussion at https://lore.kernel.org/xen-devel/20201205082839.ts3ju6yta46cgwjn@Air-de-Roger/T Cc: sta...@vger.kernel.org #v5.9+ (for 5.9 it's easier to revert the original commit directly) Signed-off-by: Marek Marczykowski-Górecki --- drivers/gpu/drm/xen/xen_drm_front_gem.c | 9 +- drivers/xen/Kconfig | 10 -- drivers/x
Re: [PATCH v3 02/13] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
On 12/6/20 12:52 PM, Sam Ravnborg wrote: > Hi Randy. > > On Sun, Dec 06, 2020 at 11:37:17AM -0800, Randy Dunlap wrote: >> On 12/6/20 11:02 AM, Sam Ravnborg wrote: >>> Fix kernel-doc warnings reported when using W=1 >>> >>> v2: >>> - Improve subject (Lee) >>> >>> v3: >>> - Add RETURNS documentation (Thomas) >> >> Hi Sam, >> >> Yes, RETURNS: will work. It just looks like any kernel-doc section name, >> such as Context: or Note:. >> However, the documented format for return info is "Return:". >> (see Documentation/doc-guide/kernel-doc.rst) > OK, like this? Yes. LGTM. Acked-by: Randy Dunlap > I did not fix any existing uses of RETURNS, thats for another patch. > > Sam > > commit 03b7c3ecf7cb51b5429ca0ef58a32bb4dc486610 > Author: Sam Ravnborg > Date: Sat Nov 28 23:40:49 2020 +0100 > > video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify > > Fix kernel-doc warnings reported when using W=1 > > v2: > - Improve subject (Lee) > > v3: > - Add RETURNS documentation (Thomas) > > v4: > - Use Return: not RETURNS (Randy) > > Signed-off-by: Sam Ravnborg > Cc: Lee Jones > Cc: Sam Ravnborg > Cc: Randy Dunlap > Cc: Bartlomiej Zolnierkiewicz > Cc: Daniel Vetter > Cc: "Alexander A. Klimov" -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 05/12] renesas: Replace strstarts() by str_has_prefix().
From: Francis Laniel
The two functions indicates if a string begins with a given prefix.
The only difference is that strstarts() returns a bool while str_has_prefix()
returns the length of the prefix if the string begins with it or 0 otherwise.
Signed-off-by: Francis Laniel
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index fe86a3e67757..3f9972165afa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1016,7 +1016,7 @@ static int rcar_du_crtc_parse_crc_source(struct
rcar_du_crtc *rcrtc,
} else if (!strcmp(source_name, "auto")) {
*source = VSP1_DU_CRC_OUTPUT;
return 0;
- } else if (strstarts(source_name, "plane")) {
+ } else if (str_has_prefix(source_name, "plane")) {
unsigned int i;
*source = VSP1_DU_CRC_PLANE;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon 0/2] Code refactoring
patch #1 is used drmm_mode_config_init() to do code refactoring. patch #2 is deleted unused variable ‘priv’ to avoid warning. Tian Tao (2): drm/hisilicon: Use managed mode-config init drm/hisilicon: Delete unused local parameters drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/13] video: fbdev: hgafb: Fix kernel-doc warnings
On 12/6/20 11:02 AM, Sam Ravnborg wrote: > Fix kernel-doc comments. > > v2: > - Updated subject (Lee) > > v3: > - Add space after ':' (Randy) > - Fix name of function in comment > > Signed-off-by: Sam Ravnborg > Cc: Ferenc Bakonyi > Cc: linux-nvi...@lists.surfsouth.com > Cc: Lee Jones > --- > drivers/video/fbdev/hgafb.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c > index a45fcff1461f..8bbac7182ad3 100644 > --- a/drivers/video/fbdev/hgafb.c > +++ b/drivers/video/fbdev/hgafb.c > @@ -357,8 +357,8 @@ static int hga_card_detect(void) > > /** > * hgafb_open - open the framebuffer device > - * @info:pointer to fb_info object containing info for current hga board > - * @int:open by console system or userland. > + * @info: pointer to fb_info object containing info for current hga board > + * @init: open by console system or userland. > */ > > static int hgafb_open(struct fb_info *info, int init) > @@ -370,9 +370,9 @@ static int hgafb_open(struct fb_info *info, int init) > } > > /** > - * hgafb_open - open the framebuffer device > - * @info:pointer to fb_info object containing info for current hga board > - * @int:open by console system or userland. > + * hgafb_release - open the framebuffer device > + * @info: pointer to fb_info object containing info for current hga board > + * @init: open by console system or userland. > */ > > static int hgafb_release(struct fb_info *info, int init) > LGTM. Thanks. Acked-by: Randy Dunlap -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] vc4: Convert to drm_atomic_helper_commit
Hi, Here's a conversion of vc4 to remove the hand-rolled atomic_commit helper from vc4 in favour of the generic one. This requires some rework of vc4, but also a new hook and some documentation for corner-cases in the DRM core that have been reported and explained by Daniel recently. Let me know what you think, Maxime Changes from v1: - Addressed the comments from Dave and Thomas on the documentation - s/last_user/pending_commit/ - Check that the commit is not NULL before waiting on it - Fixed a compilation error on an intermediate patch - Drop the assigned_channels variable redundant with the in_use variable Maxime Ripard (7): drm: Introduce an atomic_commit_setup function drm: Document use-after-free gotcha with private objects drm/vc4: Simplify a bit the global atomic_check drm/vc4: kms: Wait on previous FIFO users before a commit drm/vc4: kms: Remove unassigned_channels from the HVS state drm/vc4: kms: Remove async modeset semaphore drm/vc4: kms: Convert to atomic helpers drivers/gpu/drm/drm_atomic_helper.c | 9 + drivers/gpu/drm/vc4/vc4_crtc.c | 13 -- drivers/gpu/drm/vc4/vc4_drv.h| 2 - drivers/gpu/drm/vc4/vc4_kms.c| 248 +++ include/drm/drm_atomic.h | 20 ++ include/drm/drm_modeset_helper_vtables.h | 21 ++ 6 files changed, 172 insertions(+), 141 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/5] Enable rk3066a HDMI sound
Update the rk3066a HDMI documents with a #sound-dai-cells property. Include the code for sound in the HDMI driver. Add a simple-sound-card compatible node to rk3066a.dtsi, because I2S0 and HDMI TX are connected internally. And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -j4 cp ./arch/arm/boot/zImage ../zImage-dtb cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb ../tools/rkcrc -k ../zImage-dtb ../mk808.img sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img sudo ../tools/rkflashtool b Changed v6: remove patches that are applied to linux-next add platform_device_unregister() restyle Changed v5: removed unused variable fill frame structure Johan Jonker (4): dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808 Zheng Yang (1): drm: rockchip: add sound support to rk3066 hdmi driver .../display/rockchip/rockchip,rk3066-hdmi.yaml | 4 + arch/arm/boot/dts/rk3066a-mk808.dts| 8 + arch/arm/boot/dts/rk3066a.dtsi | 17 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 277 - 5 files changed, 307 insertions(+), 1 deletion(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
Create drm_basic_types.h to define types previously defined by drm.h. Use DRM_FOURCC_STANDALONE to include drm_fourcc.h, replacing drm.h dependency with drm_basic_types.h. This will allow Mesa to port code to Windows more easily. Signed-off-by: James Park James Park (1): drm: drm_basic_types.h, DRM_FOURCC_STANDALONE include/uapi/drm/drm.h | 14 ++ include/uapi/drm/drm_basic_types.h | 52 ++ include/uapi/drm/drm_fourcc.h | 4 +++ 3 files changed, 58 insertions(+), 12 deletions(-) create mode 100644 include/uapi/drm/drm_basic_types.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: enable DSPP support on SM8[12]50
On Tue, 3 Nov 2020 at 08:21, Dmitry Baryshkov
wrote:
>
> Add support for color correction sub block on SM8150 and SM8250.
Gracious ping for this patch
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 26 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 3 +--
> 2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index bb1add2e49dd..240a21c5e5fe 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -466,9 +466,9 @@ static const struct dpu_lm_cfg sc7180_lm[] = {
>
> static const struct dpu_lm_cfg sm8150_lm[] = {
> LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> - &sdm845_lm_sblk, PINGPONG_0, LM_1, 0),
> + &sdm845_lm_sblk, PINGPONG_0, LM_1, DSPP_0),
> LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> - &sdm845_lm_sblk, PINGPONG_1, LM_0, 0),
> + &sdm845_lm_sblk, PINGPONG_1, LM_0, DSPP_1),
> LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
> &sdm845_lm_sblk, PINGPONG_2, LM_3, 0),
> LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
> @@ -487,16 +487,28 @@ static const struct dpu_dspp_sub_blks sc7180_dspp_sblk
> = {
> .len = 0x90, .version = 0x1},
> };
>
> -#define DSPP_BLK(_name, _id, _base) \
> +static const struct dpu_dspp_sub_blks sm8150_dspp_sblk = {
> + .pcc = {.id = DPU_DSPP_PCC, .base = 0x1700,
> + .len = 0x90, .version = 0x4},
> +};
> +
> +#define DSPP_BLK(_name, _id, _base, _sblk) \
> {\
> .name = _name, .id = _id, \
> .base = _base, .len = 0x1800, \
> .features = DSPP_SC7180_MASK, \
> - .sblk = &sc7180_dspp_sblk \
> + .sblk = _sblk \
> }
>
> static const struct dpu_dspp_cfg sc7180_dspp[] = {
> - DSPP_BLK("dspp_0", DSPP_0, 0x54000),
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, &sc7180_dspp_sblk),
> +};
> +
> +static const struct dpu_dspp_cfg sm8150_dspp[] = {
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, &sm8150_dspp_sblk),
> + DSPP_BLK("dspp_1", DSPP_1, 0x56000, &sm8150_dspp_sblk),
> + DSPP_BLK("dspp_2", DSPP_2, 0x58000, &sm8150_dspp_sblk),
> + DSPP_BLK("dspp_3", DSPP_3, 0x5a000, &sm8150_dspp_sblk),
> };
>
> /*
> @@ -888,6 +900,8 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
> .sspp = sdm845_sspp,
> .mixer_count = ARRAY_SIZE(sm8150_lm),
> .mixer = sm8150_lm,
> + .dspp_count = ARRAY_SIZE(sm8150_dspp),
> + .dspp = sm8150_dspp,
> .pingpong_count = ARRAY_SIZE(sm8150_pp),
> .pingpong = sm8150_pp,
> .merge_3d_count = ARRAY_SIZE(sm8150_merge_3d),
> @@ -919,6 +933,8 @@ static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
> .sspp = sm8250_sspp,
> .mixer_count = ARRAY_SIZE(sm8150_lm),
> .mixer = sm8150_lm,
> + .dspp_count = ARRAY_SIZE(sm8150_dspp),
> + .dspp = sm8150_dspp,
> .pingpong_count = ARRAY_SIZE(sm8150_pp),
> .pingpong = sm8150_pp,
> .merge_3d_count = ARRAY_SIZE(sm8150_merge_3d),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
> index a7a24539921f..e42f901a7de5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
> @@ -57,8 +57,7 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
> static void _setup_dspp_ops(struct dpu_hw_dspp *c,
> unsigned long features)
> {
> - if (test_bit(DPU_DSPP_PCC, &features) &&
> - IS_SC7180_TARGET(c->hw.hwversion))
> + if (test_bit(DPU_DSPP_PCC, &features))
> c->ops.setup_pcc = dpu_setup_dspp_pcc;
> }
>
> --
> 2.28.0
>
--
With best wishes
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
Create drm_basic_types.h to define types previously defined by drm.h.
Use DRM_FOURCC_STANDALONE to include drm_fourcc.h, replacing drm.h
dependency with drm_basic_types.h.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
---
include/uapi/drm/drm.h | 14 ++
include/uapi/drm/drm_basic_types.h | 52 ++
include/uapi/drm/drm_fourcc.h | 4 +++
3 files changed, 58 insertions(+), 12 deletions(-)
create mode 100644 include/uapi/drm/drm_basic_types.h
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a..a7f38fc 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -36,32 +36,22 @@
#ifndef _DRM_H_
#define _DRM_H_
+#include "drm_basic_types.h"
+
#if defined(__KERNEL__)
-#include
#include
typedef unsigned int drm_handle_t;
#elif defined(__linux__)
-#include
#include
typedef unsigned int drm_handle_t;
#else /* One of the BSDs */
-#include
#include
#include
-typedef int8_t __s8;
-typedef uint8_t __u8;
-typedef int16_t __s16;
-typedef uint16_t __u16;
-typedef int32_t __s32;
-typedef uint32_t __u32;
-typedef int64_t __s64;
-typedef uint64_t __u64;
-typedef size_t __kernel_size_t;
typedef unsigned long drm_handle_t;
#endif
diff --git a/include/uapi/drm/drm_basic_types.h
b/include/uapi/drm/drm_basic_types.h
new file mode 100644
index 000..b3c00bb
--- /dev/null
+++ b/include/uapi/drm/drm_basic_types.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DRM_BASIC_TYPES_H_
+#define _DRM_BASIC_TYPES_H_
+
+#if defined(__KERNEL__)
+
+#include
+
+#elif defined(__linux__)
+
+#include
+
+#else /* One of the BSDs */
+
+#include
+typedef int8_t __s8;
+typedef uint8_t __u8;
+typedef int16_t __s16;
+typedef uint16_t __u16;
+typedef int32_t __s32;
+typedef uint32_t __u32;
+typedef int64_t __s64;
+typedef uint64_t __u64;
+typedef size_t __kernel_size_t;
+
+#endif
+
+#endif
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..5eb07a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#ifdef DRM_FOURCC_STANDALONE
+#include "drm_basic_types.h"
+#else
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/5] ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808
Make some noise with mk808. Enable the hdmi_sound node and
add i2s0 as sound source for hdmi.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a-mk808.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
b/arch/arm/boot/dts/rk3066a-mk808.dts
index eed9e60cf..5fe74c097 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -116,6 +116,14 @@
};
};
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2s0 {
+ status = "okay";
+};
+
&mmc0 {
bus-width = <4>;
cap-mmc-highspeed;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
VIRTIO itself has no dependencies and therefore can easily be just select'ed, instead of depending on it. The current depends on causes any others trying to select VIRTIO to fail like this: drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2:symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2:symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47:symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER It seems that having both 'depends on' as well as 'select' on the same symbol sends us into big trouble, and Kconfig can't break up the circular dependency (note that in the tested configuration, neither I2C, FB or DRM are enabled at all). Perhaps we could consider this a bug in Kconfig, but the trouble can easily be circumvented by changing 'depends on' into 'select'. DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that option will only show up if the user already enabled virtio in the config. This change didn't cause any changes in the .config after menuconfig run, so we should be completely safe here. Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/gpu/drm/virtio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index b925b8b1da16..51ec7c3240c9 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO && VIRTIO_MENU && MMU + depends on DRM && VIRTIO_MENU && MMU + select VIRTIO select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER select VIRTIO_DMA_SHARED_BUFFER -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/1] dt-bindings: display: eliminate yamllint warnings
Eliminate the following yamllint warnings: ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml :52:9: [warning] wrong indentation: expected 6 but found 8 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml :42:8: [warning] wrong indentation: expected 8 but found 7 (indentation) :45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml :21:6: [warning] wrong indentation: expected 6 but found 5 (indentation) ./Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml :25:10: [warning] wrong indentation: expected 10 but found 9 (indentation) Signed-off-by: Zhen Lei Acked-by: Sam Ravnborg --- .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 ++-- .../devicetree/bindings/display/bridge/intel,keembay-dsi.yaml | 4 ++-- Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml | 4 ++-- Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 60585a4fc22bc9f..9392b5502a3293c 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -49,8 +49,8 @@ properties: Video port for panel or connector. required: -- port@0 -- port@1 + - port@0 + - port@1 required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml index ab5be26252240ea..35c9dfd866501a0 100644 --- a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml @@ -39,10 +39,10 @@ properties: properties: '#address-cells': - const: 1 +const: 1 '#size-cells': - const: 0 +const: 0 port@0: type: object diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml index 40caa61188098c2..a222b52d8b8ff6b 100644 --- a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml +++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml @@ -18,8 +18,8 @@ description: | properties: compatible: items: - - const: intel,keembay-msscam - - const: syscon + - const: intel,keembay-msscam + - const: syscon reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index d2170de6b72302f..2f5df1d235aea8a 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -22,7 +22,7 @@ properties: compatible: items: - enum: - - tianma,fhd-video + - tianma,fhd-video - const: novatek,nt36672a description: This indicates the panel manufacturer of the panel that is in turn using the NT36672A panel driver. This compatible string -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drivers may provide multiple primary planes per CRTC
On Monday, December 7th, 2020 at 9:45 AM, Pekka Paalanen wrote: > > > > > > - * Cursor and overlay planes are optional. All drivers should > > > > > > provide one > > > > > > - * primary plane per CRTC to avoid surprising userspace too much. > > > > > > See enum > > > > > > + * Cursor and overlay planes are optional. All drivers should > > > > > > provide at least > > > > > > + * one primary plane per CRTC to avoid surprising userspace too > > > > > > much. See enum > > > > > > > > > > I think that's even more confusing, since this reads like there could > > > > > be > > > > > multiple primary planes for a specific CRTC. That's not the case, > > > > > there' > > > > > only one pointer going from drm_crtc->primary to a drm_plane in the > > > > > kernel. > > > > > > > > There could be multiple primary planes *usable* for a specific CRTC but > > > > just one used at a time, right? > > > > > > I'm not sure what you mean here, the crtc->primary link is invariant over > > > the lifetime of a driver load. You can't pick a different one, that's set > > > at driver init before drm_dev_register (and hence before userspace ever > > > sees anything). > > > > OK. I'm personally not very interested in documenting legacy bits, so I'll > > skip > > that. I'm mainly interested here in making it clear possible_crtcs for a > > primary plane can have more than one bit set. Because of the paragraph in > > the > > current docs, some user-space developers have understood "more than one bit > > set > > in possible_crtcs for a primary plane is a kernel bug". > > > > I'll send a v2 that makes it clear these pointers are for legacy uAPI. > > Right, so this and what danvet said seem to be in direct conflict in > atomic uAPI, repeating above: > > > > I'm not sure what you mean here, the crtc->primary link is invariant over > > > the lifetime of a driver load. You can't pick a different one, that's set > > > at driver init before drm_dev_register (and hence before userspace ever > > > sees anything). > > But still, it is considered not a kernel bug that a primary plane has > more than one bit set in its possible_crtcs. > > If a primary plane has more than one bit set in possible_crtcs, and it > is not a kernel bug, then userspace expects to be able to choose any > of the multiple indicated possible CRTCs for this primary plane. > > Which way is it? > > Or, is there a different limitation that for each CRTC, there must be > exactly one primary plane with that CRTCs bit set in its possible_crtcs? > > IOW, you can have more CRTCs than primary planes in total, and you can > activate each CRTC alone, but you cannot activate all CRTCs > simultaneously because there are not enough primary planes for them? > > Representing it mathematically, the possible assignments according to > possible_crtcs while ignoring all other limitations are: > N CRTCs <-> M primary planes > > - Is N one or greater than one? > - Is M one or greater than one? I think the current situation is that: - It's perfectly fine for a driver to expose multiple bits in possible_crtcs. User-space can attach the primary plane to any of these CRTCs (of course, a primary plane still can only be attached to a single CRTC at a time). Drivers should provide as many primary planes as there are CRTCs. - The legacy API doesn't expose primary planes. Some legacy IOCTLs like drmModeSetCrtc allow user-space to attach a FB directly to a CRTC. The driver needs to implicitly select a primary plane for this operation. That's the only case where the internal CRTC → primary plane link is used in the kernel. Is this correct, Daniel? So I believe M > 1 and N > 1 is possible and isn't a kernel bug. For instance some drivers hardcode possible_crtcs to 0xFF (although it might be nicer to user-space to set the bitmask depending on the number of CRTCs, to avoid setting bits for non-existing CRTCs). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committing the
patch. Your cover letter for the series already does this correctly.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks for all these updates.
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector *connector)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "xen: add helpers to allocate unpopulated memory"
On 06.12.20 18:22, Marek Marczykowski-Górecki wrote: This reverts commit 9e2369c06c8a181478039258a4598c1ddd2cadfa. On a Xen PV dom0, with NVME disk, this makes the dom0 crash when starting a domain. This looks like some bad interaction between xen-blkback and xen-scsiback has the same use pattern. NVME driver, both using ZONE_DEVICE. Since the author is on leave now, revert the change until proper solution is developed. The specific crash message is: general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI CPU: 1 PID: 134 Comm: kworker/u12:2 Not tainted 5.9.9-1.qubes.x86_64 #1 Hardware name: LENOVO 20M9CTO1WW/20M9CTO1WW, BIOS N2CET50W (1.33 ) 01/15/2020 Workqueue: dm-thin do_worker [dm_thin_pool] RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Call Trace: nvme_queue_rq+0xa7/0x1a0 [nvme] __blk_mq_try_issue_directly+0x11d/0x1e0 ? add_wait_queue_exclusive+0x70/0x70 blk_mq_try_issue_directly+0x35/0xc0l[ blk_mq_submit_bio+0x58f/0x660 __submit_bio_noacct+0x300/0x330 process_shared_bio+0x126/0x1b0 [dm_thin_pool] process_cell+0x226/0x280 [dm_thin_pool] process_thin_deferred_cells+0x185/0x320 [dm_thin_pool] process_deferred_bios+0xa4/0x2a0 [dm_thin_pool]UX do_worker+0xcc/0x130 [dm_thin_pool] process_one_work+0x1b4/0x370 worker_thread+0x4c/0x310 ? process_one_work+0x370/0x370 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60< ret_from_fork+0x22/0x30 Modules linked in: loop snd_seq_dummy snd_hrtimer nf_tables nfnetlink vfat fat snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_soc_skl snd_soc_sst_ ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine elan_i2c snd_hda_codec_hdmi mei_hdcp iTCO_wdt intel_powerclamp intel_pmc_bxt ee1004 intel_rapl_msr iTCO_vendor _support joydev pcspkr intel_wmi_thunderbolt wmi_bmof thunderbolt ucsi_acpi idma64 typec_ucsi snd_hda_codec_realtek typec snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec thinkpad_acpi snd_hda_core ledtrig_audio int3403_ thermal snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi snd_timer processor_thermal_device mei_me cfg80211 intel_rapl_common snd e1000e mei int3400_thermal int340x_thermal_zone i2c_i801 acpi_thermal_rel soundcore intel_soc_dts_iosf i2c_s mbus rfkill intel_pch_thermal xenfs ip_tables dm_thin_pool dm_persistent_data dm_bio_prison dm_crypt nouveau rtsx_pci_sdmmc mmc_core mxm_wmi crct10dif_pclmul ttm crc32_pclmul crc32c_intel i915 ghash_clmulni_intel i2c_algo_bit serio_raw nvme drm_kms_helper cec xhci_pci nvme _core rtsx_pci xhci_pci_renesas drm xhci_hcd wmi video pinctrl_cannonlake pinctrl_intel xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn uinput ---[ end trace f8d47e4aa6724df4 ]--- RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Discussion at https://lore.kernel.org/xen-devel/20201205082839.ts3ju6yta46cgwjn@Air-de-Roger/T Cc: sta...@vger.kernel.org #v5.9+ (for 5.9 it's easier to revert the original commit directly) Sig
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
On Sunday, December 6th, 2020 at 1:39 AM, James Park
wrote:
> Create drm_basic_types.h to define types previously defined by drm.h.
>
> Use DRM_FOURCC_STANDALONE to include drm_fourcc.h, replacing drm.h
> dependency with drm_basic_types.h.
This approach looks better to me than the other alternatives.
> This will allow Mesa to port code to Windows more easily.
>
> Signed-off-by: James Park
> ---
> include/uapi/drm/drm.h | 14 ++
> include/uapi/drm/drm_basic_types.h | 52
> ++
> include/uapi/drm/drm_fourcc.h | 4 +++
> 3 files changed, 58 insertions(+), 12 deletions(-)
> create mode 100644 include/uapi/drm/drm_basic_types.h
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 808b48a..a7f38fc 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -36,32 +36,22 @@
> #ifndef _DRM_H_
> #define _DRM_H_
>
> +#include "drm_basic_types.h"
> +
> #if defined(__KERNEL__)
>
> -#include
> #include
> typedef unsigned int drm_handle_t;
>
> #elif defined(__linux__)
>
> -#include
> #include
> typedef unsigned int drm_handle_t;
>
> #else /* One of the BSDs */
>
> -#include
> #include
> #include
> -typedef int8_t __s8;
> -typedef uint8_t __u8;
> -typedef int16_t __s16;
> -typedef uint16_t __u16;
> -typedef int32_t __s32;
> -typedef uint32_t __u32;
> -typedef int64_t __s64;
> -typedef uint64_t __u64;
> -typedef size_t __kernel_size_t;
> typedef unsigned long drm_handle_t;
>
> #endif
> diff --git a/include/uapi/drm/drm_basic_types.h
> b/include/uapi/drm/drm_basic_types.h
> new file mode 100644
> index 000..b3c00bb
> --- /dev/null
> +++ b/include/uapi/drm/drm_basic_types.h
> @@ -0,0 +1,52 @@
> +/*
> + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> + * All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _DRM_BASIC_TYPES_H_
> +#define _DRM_BASIC_TYPES_H_
> +
> +#if defined(__KERNEL__)
> +
> +#include
> +
> +#elif defined(__linux__)
Nit: these two #ifs can be combined together.
> +#include
> +
> +#else /* One of the BSDs */
Maybe replace with /* Not Linux */?
> +#include
> +typedef int8_t __s8;
> +typedef uint8_t __u8;
> +typedef int16_t __s16;
> +typedef uint16_t __u16;
> +typedef int32_t __s32;
> +typedef uint32_t __u32;
> +typedef int64_t __s64;
> +typedef uint64_t __u64;
> +typedef size_t __kernel_size_t;
> +
> +#endif
> +
> +#endif
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#ifdef DRM_FOURCC_STANDALONE
> +#include "drm_basic_types.h"
> +#else
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
> --
> 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
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 9:57 AM, James Park wrote: > I could adjust the block to look like this: > > #ifdef DRM_FOURCC_STANDALONE > #if defined(__linux__) > #include > #else > #include > typedef uint32_t __u32; > typedef uint64_t __u64; > #endif > #else > #include "drm.h" > #endif This approach still breaks on BSDs when DRM_FOURCC_STANDALONE is defined and drm.h is included afterwards. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Hi
Am 07.12.20 um 10:29 schrieb tiantao (H):
在 2020/12/7 17:22, Thomas Zimmermann 写道:
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committing the
Just to be sure: I don't need to add a changlog to this individual
patch, right?
You should. It's supposed to be good style to add a changelog for each
patch and also highlight the series' overall changes in the cover letter.
Best regards
Thomas
patch. Your cover letter for the series already does this correctly.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks for all these updates.
Thank you for your constant help with the review code and your careful
guidance!
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private
*priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct
drm_connector *connector)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
On Monday, December 7th, 2020 at 10:55 AM, James Park wrote: > I'd noticed the #if could be combined, but they weren't in drm,h when > they could have been, so I didn't want to depart from the existing > pattern. I see. The original code really needed the two branches and drm_basic_types.h doesn't. But let's see what others think. > I think "One of the BSDs" is more informative than "Not Linux" if > that statement is still true. Given the aversion to making drm.h > robust to Windows, I don't think we want to imply compatibility that > isn't there. Well, drm_basic_types.h would be included on Windows as well from drm_fourcc.h, right? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 11:00 AM, James Park wrote: > Not to make too big a deal of it, but the idea was that if you went > out of your way to define DRM_FOURCC_STANDALONE in your code base, > that you would also go through the pain of removing drm.h includes > elsewhere. It's too annoying of an implication to > document/communicate, so I'm happier with the other > DRM_FOURCC_STANDALONE solution that pulls the basic types into a > common header. In my compositors I'd like to globally define DRM_FOURCC_STANDALONE (to make sure I don't miss any #define) but I still may include drm.h in the same files as well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 kurmi...@libero.it changed: What|Removed |Added CC||kurmi...@libero.it --- Comment #19 from kurmi...@libero.it --- I confirm that the bug is not fixed in 5.9.12. https://github.com/systemd/systemd/issues/17826 As Poettering pointed out, actual_brightness is read-only and reports the brightness currently in effect, while brightness is writable and reports the value set by userspace. Not only the actual brightness is in a different range that breaks systemd backlight restoring service at startup, but on my device its value is also fixed on the same value while it should reflect the correct level on brightness changes. Brightness at the maximum: /sys/class/backlight/amdgpu_bl0/actual_brightness > 249 /sys/class/backlight/amdgpu_bl0/brightness > 255 /sys/class/backlight/amdgpu_bl0/max_brightness > 255 Brightness at the minimum: /sys/class/backlight/amdgpu_bl0/actual_brightness > 249 /sys/class/backlight/amdgpu_bl0/brightness > 2 /sys/class/backlight/amdgpu_bl0/max_brightness > 255 -- 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] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
On Monday, December 7th, 2020 at 11:05 AM, James Park
wrote:
> The original code blocks in drm.h look identical to me. I see:
>
> #include
> #include
> typedef unsigned int drm_handle_t;
Hmm. Actually you're completely right, it turns out it's necessary to
duplicate the branches like this to make `make headers_install` work
properly. See 00c9672606f7 ("drm: Untangle __KERNEL__ guards").
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 7 Dec 2020 01:08:58 -0800 James Park wrote: > I'm not completely sure what you're saying, but doesn't drm_base_types.h > (now drm_basic_types.h) make things robust to header order? The patch is in > another email. You can also see it here: > https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18 If that is robust (I don't know if it is, I haven't checked), then why do you have #ifdef DRM_FOURCC_STANDALONE in it at all? Like Simon said: On Mon, 07 Dec 2020 10:02:36 + Simon Ser wrote: > In my compositors I'd like to globally define DRM_FOURCC_STANDALONE > (to make sure I don't miss any #define) but I still may include drm.h > in the same files as well. If any project #defines it globally, then what good does checking for it do? Why not assume that everyone will always want what DRM_FOURCC_STANDALONE would bring? Thanks, pq > > Thanks, > James > > On Mon, Dec 7, 2020 at 12:51 AM Pekka Paalanen wrote: > > > On Fri, 4 Dec 2020 11:07:41 -0800 > > James Park wrote: > > > > > I could adjust the block to look like this: > > > > > > #ifdef DRM_FOURCC_STANDALONE > > > #if defined(__linux__) > > > #include > > > #else > > > #include > > > typedef uint32_t __u32; > > > typedef uint64_t __u64; > > > #endif > > > #else > > > #include "drm.h" > > > #endif > > > > > > Alternatively, I could create a new common header to be included from > > both > > > drm.h and drm_fourcc.h, drm_base_types.h or something like that: > > > > > > #ifdef DRM_FOURCC_STANDALONE > > > #include "drm_base_types.h" > > > #else > > > #include "drm.h" > > > #endif > > > > Hi, > > > > my point is, any solution relying on DRM_FOURCC_STANDALONE will fail > > sometimes, because there is no reason why userspace would *not* #define > > DRM_FOURCC_STANDALONE. Hence, #ifdef DRM_FOURCC_STANDALONE is > > completely moot, you have to make the headers work in any include > > order when DRM_FOURCC_STANDALONE is defined anyway. > > > > > > Thanks. > > pq > > > > > On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote: > > > > > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen > > wrote: > > > > > > > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park < > > james.p...@lagfreegames.com> > > > > wrote: > > > > > > > > > > > > > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't > > > > > > > intentional, right? Should I put all the integer types, or just > > the > > > > > > > ones that are used in that file? > > > > > > > > > > > > Yeah that trailing _ just slipped in. And I'd just do the types > > > > > > already used. I don't think anything else than __u32 (for drm > > fourcc) > > > > > > and __u64 (for drm modifier) is needed. > > > > > > > > > > Hi, > > > > > > > > > > can that create conflicts if userspace first includes drm_fourcc.h > > and > > > > > then drm.h? > > > > > > > > > > I would find it natural to userspace have generic headers including > > > > > drm_fourcc.h and then DRM-specific C-files including drm.h as well > > > > > (through libdrm headers). I think Weston might already do this. > > > > > > > > > > The generic userspace (weston) header would obviously #define > > > > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as > > well. > > > > > > > > Hm yes that would break. I guess we could just include the linux types > > > > header for this. And I guess on windows you'd need to have that from > > > > somewhere. Or we just require that users of the standalone header pull > > > > the right header or defines in first? > > > > -Daniel > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch > > > > > > > > pgpn8FF_3CXto.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] arm: dts: sc7180: Add support for gpu fuse
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678f1e..8cae3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -675,6 +675,11 @@
reg = <0x25b 0x1>;
bits = <1 3>;
};
+
+ gpu_speed_bin: gpu_speed_bin@1d2 {
+ reg = <0x1d2 0x2>;
+ bits = <5 8>;
+ };
};
sdhc_1: sdhci@7c4000 {
@@ -1907,52 +1912,69 @@
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-82500 {
+ opp-hz = /bits/ 64 <82500>;
+ opp-level =
;
+ opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x04>;
+ };
+
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level =
;
opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x07>;
};
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level =
;
opp-peak-kBps = <7216000>;
+ opp-supported-hw = <0x07>;
};
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level =
;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level =
;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level =
;
opp-peak-kBps = <1804000>;
+ opp-supported-hw = <0x07>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/msm: Add speed-bin support to a618 gpu
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes from v2:
1. Made the changes a6xx specific to save space.
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 74 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 1306618..6304578 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,10 +10,13 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
+const u32 a618_speedbins[] = {0, 169, 174};
+
static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1208,6 +1211,10 @@ static void a6xx_destroy(struct msm_gpu *gpu)
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_gpu);
+
+ if (a6xx_gpu->opp_table)
+ dev_pm_opp_put_supported_hw(a6xx_gpu->opp_table);
+
kfree(a6xx_gpu);
}
@@ -1264,6 +1271,67 @@ static uint32_t a6xx_get_rptr(struct msm_gpu *gpu,
struct msm_ringbuffer *ring)
return ring->memptrs->rptr = gpu_read(gpu, REG_A6XX_CP_RB_RPTR);
}
+static u32 fuse_to_supp_hw(struct device *dev, u32 revn, u32 fuse)
+{
+ int i;
+
+ if (revn == 618) {
+ for (i = 0; i < ARRAY_SIZE(a618_speedbins); i++) {
+ if (fuse == a618_speedbins[i])
+ return (1 << i);
+ }
+ }
+
+ DRM_DEV_ERROR(dev,
+ "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware",
+ fuse);
+ return ~0U;
+}
+
+static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu,
+ u32 revn)
+{
+
+ struct opp_table *opp_table;
+ struct nvmem_cell *cell;
+ u32 supp_hw = ~0U;
+ void *buf;
+
+ cell = nvmem_cell_get(dev, "speed_bin");
+ /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+ if (PTR_ERR(cell) == -ENOENT)
+ return 0;
+ else if (IS_ERR(cell)) {
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ buf = nvmem_cell_read(cell, NULL);
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf));
+
+ kfree(buf);
+ nvmem_cell_put(cell);
+
+done:
+ opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1);
+ if (IS_ERR(opp_table))
+ return PTR_ERR(opp_table);
+
+ a6xx_gpu->opp_table = opp_table;
+ return 0;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1325,6 +1393,12 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu);
+ ret = a6xx_set_supported_hw(&pdev->dev, a6xx_gpu, info->revn);
+ if (ret) {
+ a6xx_destroy(&(a6xx_gpu->base.base));
+ return ERR_PTR(ret);
+ }
+
ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index e793d32..ce0610c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -33,6 +33,8 @@ struct a6xx_gpu {
void *llc_slice;
void *htw_llc_slice;
bool have_mmu500;
+
+ struct opp_table *opp_table;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 7 Dec 2020 12:35:14 +0200 Pekka Paalanen wrote: > On Mon, 7 Dec 2020 01:08:58 -0800 > James Park wrote: > > > I'm not completely sure what you're saying, but doesn't drm_base_types.h > > (now drm_basic_types.h) make things robust to header order? The patch is in > > another email. You can also see it here: > > https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18 > > > > If that is robust (I don't know if it is, I haven't checked), then why > do you have #ifdef DRM_FOURCC_STANDALONE in it at all? > > Like Simon said: > > On Mon, 07 Dec 2020 10:02:36 + > Simon Ser wrote: > > > In my compositors I'd like to globally define DRM_FOURCC_STANDALONE > > (to make sure I don't miss any #define) but I still may include drm.h > > in the same files as well. > > If any project #defines it globally, then what good does checking for > it do? Why not assume that everyone will always want what > DRM_FOURCC_STANDALONE would bring? Sorry! Now I got it. DRM_FOURCC_STANDALONE is a promise that the user is not relying on drm_foucc.h to pull in drm.h. Nothing else. That's fine. But then, the code in the header should be literally #ifndef DRM_FOURCC_STANDALONE #include "drm.h" #endif without an #else branch. Thanks, pq pgpp2cgFtEs0v.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen wrote: > But then, the code in the header should be literally > > #ifndef DRM_FOURCC_STANDALONE > #include "drm.h" > #endif > > without an #else branch. As long as there is a #include "drm_basic_types.h" right before (drm_fourcc.h needs __u32 and __u64), I believe this can work too indeed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 11:49 AM, James Park
wrote:
> That would work, but that's kind of an annoying requirement. I would
> prefer the header to be self-sufficient.
I don't want to make it more confusing than before, but here Pekka (I
think) suggests to replace this:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..5eb07a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#ifdef DRM_FOURCC_STANDALONE
+#include "drm_basic_types.h"
+#else
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
With this:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..5eb07a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#include "drm_basic_types.h"
+
+#ifndef DRM_FOURCC_STANDALONE
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
That wouldn't change whether the header is self-sufficient or not,
would it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole
approach here isn't correct.
See even when the job has been completed or canceled we still want to
restart the timer.
The reason for this is that the timer is then not restarted for the
current job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole
device was hot plugged and we return -ENODEV here. E.g. what Andrey
has been working on.
We discussed this with Luben off line a few days ago but came to a
conclusion that for the next job the timer restart in
drm_sched_job_begin should do the work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts
the timeout in case the hardware was idle before.
The function should probably be renamed to drm_sched_job_pushed()
because it doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32
+
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct
drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence
*etnaviv_sched_run_job(struct drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job
*sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct
drm_sched_job
+ *sched_job)
{
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *g
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 07 Dec 2020 10:53:49 +
Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park
> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before, but here Pekka (I
> think) suggests to replace this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#ifdef DRM_FOURCC_STANDALONE
> +#include "drm_basic_types.h"
> +#else
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> With this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#include "drm_basic_types.h"
> +
> +#ifndef DRM_FOURCC_STANDALONE
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> That wouldn't change whether the header is self-sufficient or not,
> would it?
Exactly this.
This communicates properly that DRM_FOURCC_STANDALONE only affects
whether drm.h gets pulled in or not, and there are no other effects.
This also makes testing better: when you unconditionally include
drm_basic_types.h, you are more likely to catch breakage there.
For functionality, it makes no difference. Whether userspace does
#include "drm.h"
#define DRM_FOURCC_STANDALONE
#include "drm_fourcc.h"
or
#define DRM_FOURCC_STANDALONE
#include "drm_fourcc.h"
#include "drm.h"
the result must always be good.
Thanks,
pq
pgphVJGEKyyFU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 113/162] drm/i915: Create stolen memory region from local memory
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: CQ Tang
>
> Add "REGION_STOLEN" device info to dg1, create stolen memory
> region from upper portion of local device memory, starting
> from DSMBASE.
>
> The memory region is marked with "is_devmem=true".
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Chris P Wilson
> Cc: Balestrieri, Francesco
> Cc: Niranjana Vishwanathapura
> Cc: Venkata S Dhanalakota
> Cc: Neel Desai
> Cc: Matthew Brost
> Cc: Sudeep Dutt
> Signed-off-by: CQ Tang
> Cc: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 7 +++
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 56 +-
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> drivers/gpu/drm/i915/intel_memory_region.c | 5 ++
> drivers/gpu/drm/i915/intel_memory_region.h | 2 +-
> 7 files changed, 71 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index 71c07e1f6f26..b2fd2bc862c0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -111,8 +111,8 @@ int i915_gem_object_lmem_pread(struct drm_i915_gem_object
> *obj,
> return ret;
> }
>
> -static int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> -const struct drm_i915_gem_pwrite *arg)
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *arg)
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct intel_runtime_pm *rpm = &i915->runtime_pm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> index e11e0545e39c..c59aa6c014c7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> @@ -11,9 +11,16 @@
> struct drm_i915_private;
> struct drm_i915_gem_object;
> struct intel_memory_region;
> +struct drm_i915_gem_pread;
> +struct drm_i915_gem_pwrite;
>
> extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
>
> +int i915_gem_object_lmem_pread(struct drm_i915_gem_object *obj,
> +const struct drm_i915_gem_pread *args);
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *args);
> +
> void __iomem *
> i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
> unsigned long n,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 0ddf48e472a0..633745336f40 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -10,6 +10,7 @@
> #include
> #include
>
> +#include "gem/i915_gem_lmem.h"
> #include "gem/i915_gem_region.h"
> #include "i915_drv.h"
> #include "i915_gem_stolen.h"
> @@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
> }
> }
>
> + /*
> + * With device local memory, we don't need to check the address range,
> + * this is device memory physical address, could overlap with system
> + * memory.
> + */
> + if (HAS_LMEM(i915))
> + return 0;
> +
> /*
>* Verify that nothing else uses this physical address. Stolen
>* memory should be reserved by the BIOS and hidden from the
> @@ -607,7 +616,7 @@ static void i915_gem_object_put_pages_stolen(struct
> drm_i915_gem_object *obj,
> kfree(pages);
> }
>
> -static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
> +static struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
Making driver specific ops non-const seems suspicious...
> .name = "i915_gem_object_stolen",
> .get_pages = i915_gem_object_get_pages_stolen,
> .put_pages = i915_gem_object_put_pages_stolen,
> @@ -716,7 +725,19 @@ i915_gem_object_create_stolen(struct drm_i915_private
> *i915,
>
> static int init_stolen(struct intel_memory_region *mem)
> {
> - intel_memory_region_set_name(mem, "stolen");
> + if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM)
> + intel_memory_region_set_name(mem, "stolen-system");
> + else
> + intel_memory_region_set_name(mem, "stolen-local");
> +
> + if (HAS_LMEM(mem->i915)) {
> + i915_gem_object_stolen_ops.pread = i915_gem_object_lmem_pread;
> + i915_gem_object_stolen_ops.pwrite = i915_gem_object_lmem_pwrite;
...and AFAICT this modifies the ops for all devices, including the
integrated GPU, if any of the devices HAS_LMEM().
BR,
Jani.
> + if (!io_mapping_init_wc(&mem->iomap,
> + mem->io_start,
> +
Re: [PATCH] drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
On Fri, Dec 04, 2020 at 02:12:21PM +0100, Enrico Weigelt, metux IT consult wrote: VIRTIO itself has no dependencies and therefore can easily be just select'ed, instead of depending on it. The current depends on causes any others trying to select VIRTIO to fail like this: drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618:symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8:symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER It seems that having both 'depends on' as well as 'select' on the same symbol sends us into big trouble, and Kconfig can't break up the circular dependency (note that in the tested configuration, neither I2C, FB or DRM are enabled at all). Perhaps we could consider this a bug in Kconfig, but the trouble can easily be circumvented by changing 'depends on' into 'select'. DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that option will only show up if the user already enabled virtio in the config. This change didn't cause any changes in the .config after menuconfig run, so we should be completely safe here. Signed-off-by: Enrico Weigelt, metux IT consult Ok for me. Thank you. Reviewed-by: Anthoine Bourgeois --- drivers/gpu/drm/virtio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index b925b8b1da16..51ec7c3240c9 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO && VIRTIO_MENU && MMU + depends on DRM && VIRTIO_MENU && MMU + select VIRTIO select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER select VIRTIO_DMA_SHARED_BUFFER -- 2.11.0 ___ 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
Re: [PATCH v3 07/13] video: fbdev: mmp: Fix kernel-doc warning for lcd_spi_write
Am 06.12.20 um 20:02 schrieb Sam Ravnborg: Add missing parameter and drop parameter that is not present Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Andrzej Hajda Cc: Bartlomiej Zolnierkiewicz Acked-by: Thomas Zimmermann --- drivers/video/fbdev/mmp/hw/mmp_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/mmp/hw/mmp_spi.c b/drivers/video/fbdev/mmp/hw/mmp_spi.c index 1911a47769b6..16401eb95c6c 100644 --- a/drivers/video/fbdev/mmp/hw/mmp_spi.c +++ b/drivers/video/fbdev/mmp/hw/mmp_spi.c @@ -17,8 +17,8 @@ /** * spi_write - write command to the SPI port + * @spi: the SPI device. * @data: can be 8/16/32-bit, MSB justified data to write. - * @len: data length. * * Wait bus transfer complete IRQ. * The caller is expected to perform the necessary locking. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/13] video: fbdev: wmt_ge_rops: Fix function not declared warnings
Am 06.12.20 um 20:02 schrieb Sam Ravnborg: Include own header to fix "function not declared" warnings. Signed-off-by: Sam Ravnborg Cc: Tony Prisk Cc: linux-arm-ker...@lists.infradead.org Acked-by: Thomas Zimmermann --- drivers/video/fbdev/wmt_ge_rops.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/wmt_ge_rops.c b/drivers/video/fbdev/wmt_ge_rops.c index 2445cfe617a9..42255d27a1db 100644 --- a/drivers/video/fbdev/wmt_ge_rops.c +++ b/drivers/video/fbdev/wmt_ge_rops.c @@ -11,6 +11,7 @@ #include #include #include "core/fb_draw.h" +#include "wmt_ge_rops.h" #define GE_COMMAND_OFF 0x00 #define GE_DEPTH_OFF 0x04 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/13] video: fbdev: goldfishfb: Fix defined but not used warning
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The goldfish_fb_acpi_match table is only used with ACPI enabled.
Ifdef it out unless it is needed.
This is a similar fix to what other acpi drivers do.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/goldfishfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 9c83ec3f8e1f..2b885cd046fe 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -305,11 +305,13 @@ static const struct of_device_id goldfish_fb_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
+#ifdef CONFIG_ACPI
static const struct acpi_device_id goldfish_fb_acpi_match[] = {
{ "GFSH0004", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, goldfish_fb_acpi_match);
+#endif
static struct platform_driver goldfish_fb_driver = {
.probe = goldfish_fb_probe,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver
Hi,
On 05/12/2020 20:15, Sam Ravnborg wrote:
> Hi Neil,
>
>> +
>> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
>> +{
>> +struct khadas_ts050_panel *khadas_ts050;
>> +int err;
>> +
>> +dsi->lanes = 4;
>> +dsi->format = MIPI_DSI_FMT_RGB888;
>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>> + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
>> +
>> +khadas_ts050 = devm_kzalloc(&dsi->dev, sizeof(*khadas_ts050),
>> +GFP_KERNEL);
>> +if (!khadas_ts050)
>> +return -ENOMEM;
>> +
>> +mipi_dsi_set_drvdata(dsi, khadas_ts050);
>> +khadas_ts050->link = dsi;
>> +
>> +err = khadas_ts050_panel_add(khadas_ts050);
>> +if (err < 0)
>> +return err;
>> +
>> +return mipi_dsi_attach(dsi);
>> +}
>
> If mipi_dsi_attach() failes then da a drm_panel_remove() like this:
>
> ret = mipi_dsi_attach(dsi);
> if (ret)
> drm_panel_remove(&khadas_ts050->base);
>
> return ret;
>
> This is again something several panels gets wrong.
>
> With this fixed:
> Reviewed-by: Sam Ravnborg
>
> I assume you will fix it while applying.
Sure, thanks !
Neil
>
> Sam
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/13] video: fbdev: gbefb: Fix set but not used warning
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The variable "x" was set but never used.
Drop the redundant assignments.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/gbefb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 31270a8986e8..c5b99a4861e8 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -198,7 +198,7 @@ static void gbe_reset(void)
static void gbe_turn_off(void)
{
int i;
- unsigned int val, x, y, vpixen_off;
+ unsigned int val, y, vpixen_off;
gbe_turned_on = 0;
@@ -249,7 +249,6 @@ static void gbe_turn_off(void)
for (i = 0; i < 10; i++) {
val = gbe->vt_xy;
- x = GET_GBE_FIELD(VT_XY, X, val);
y = GET_GBE_FIELD(VT_XY, Y, val);
if (y < vpixen_off)
break;
@@ -260,7 +259,6 @@ static void gbe_turn_off(void)
"gbefb: wait for vpixen_off timed out\n");
for (i = 0; i < 1; i++) {
val = gbe->vt_xy;
- x = GET_GBE_FIELD(VT_XY, X, val);
y = GET_GBE_FIELD(VT_XY, Y, val);
if (y > vpixen_off)
break;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/13] video: fbdev: efifb: Fix set but not used warning for screen_pitch
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
screen_pitch was asssigned a value which was never used.
Drop it to fix the warning
Signed-off-by: Sam Ravnborg
Cc: Peter Jones
Cc: linux-fb...@vger.kernel.org
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index e57c00824965..b80ba3d2a9b8 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -139,7 +139,7 @@ static bool efifb_bgrt_sanity_check(struct screen_info *si,
u32 bmp_width)
static void efifb_show_boot_graphics(struct fb_info *info)
{
- u32 bmp_width, bmp_height, bmp_pitch, screen_pitch, dst_x, y, src_y;
+ u32 bmp_width, bmp_height, bmp_pitch, dst_x, y, src_y;
struct screen_info *si = &screen_info;
struct bmp_file_header *file_header;
struct bmp_dib_header *dib_header;
@@ -193,7 +193,6 @@ static void efifb_show_boot_graphics(struct fb_info *info)
bmp_width = dib_header->width;
bmp_height = abs(dib_header->height);
bmp_pitch = round_up(3 * bmp_width, 4);
- screen_pitch = si->lfb_linelength;
if ((file_header->bitmap_offset + bmp_pitch * bmp_height) >
bgrt_image_size)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/13] video: fbdev: controlfb: Fix set but not used warnings
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The controlfb driver has a number of dummy defines for IO operations.
They were introduced in commit a07a63b0e24d
("video: fbdev: controlfb: add COMPILE_TEST support").
The write variants did not use their value parameter in the
dummy versions, resulting in set but not used warnings.
Fix this by adding "(void)val" to silence the compiler.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: "Gustavo A. R. Silva"
Cc: Michael Ellerman
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/controlfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 2df56bd303d2..509311471d51 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -64,9 +64,9 @@
#undef in_le32
#undef out_le32
#define in_8(addr)0
-#define out_8(addr, val)
+#define out_8(addr, val) (void)(val)
#define in_le32(addr) 0
-#define out_le32(addr, val)
+#define out_le32(addr, val)(void)(val)
#define pgprot_cached_wthru(prot) (prot)
#else
static void invalid_vram_cache(void __force *addr)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/13] video: fbdev: sis: Drop useless call to SiS_GetResInfo()
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Coverity reported:
Useless call (USELESS_CALL) side_effect_free: Calling
SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its
return value, which is ignored.
And this is correct - so drop the call.
Signed-off-by: Sam Ravnborg
Reported-by: Colin Ian King
Addresses-Coverity: ("Useless call")
Cc: Colin Ian King
Cc: Thomas Winischhofer
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/sis/init.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index b77ea1a8825a..b568c646a76c 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -2659,7 +2659,6 @@ SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned
short ModeNo,
if(SiS_Pr->UseCustomMode) {
infoflag = SiS_Pr->CInfoFlag;
} else {
- SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
if(ModeNo > 0x13) {
infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/8] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Suggested-by: Dave Stevenson
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..112c09873eb4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- drm_atomic_helper_connector_tv_reset(connector);
+
+ if (connector->state)
+ drm_atomic_helper_connector_tv_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/8] drm/vc4: hdmi: Create a custom connector state
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 112c09873eb4..862c93708e9a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/8] drm/vc4: hdmi: Store pixel frequency in the connector state
Hi
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 862c93708e9a..c1667cfe37db 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
Has (mode->flags & DRM_MODE_FLAG_DBLCLK) been lost? I cannot find it any
longer. The code in atomic_check() looks significantly different.
Best regards
Thomas
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -824,6 +846,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] drm/vc4: Pass the atomic state to encoder hooks
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
This becomes relevant in patch 5, I guess? If so
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
Re: [PATCH v4 6/8] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 9 -
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c1667cfe37db..795fd23c8f58 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi->variant->reset(vc4_hdmi);
if (vc4_hdmi->variant->phy_init)
- vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
+ vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
HDMI_READ(HDMI_SCHEDULER_CONTROL) |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index bca6943de884..6cc5b6652cca 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_hdmi_encoder, base.base);
}
-struct drm_display_mode;
-
struct vc4_hdmi;
struct vc4_hdmi_register;
+struct vc4_hdmi_connector_state;
enum vc4_hdmi_phy_channel {
PHY_LANE_0 = 0,
@@ -82,7 +81,7 @@ struct vc4_hdmi_variant {
/* Callback to initialize the PHY according to the mode */
Rather 'according to the connector state'? OTOH these comments don't
seem to add any information. They might just be removed. :)
The patch in general is
Acked-by: Thomas Zimmermann
void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-struct drm_display_mode *mode);
+struct vc4_hdmi_connector_state *vc4_conn_state);
/* Callback to disable the PHY */
void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
drm_connector_state *conn_state)
}
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 057796b54c51..36535480f8e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -127,7 +127,8 @@
#define OSCILLATOR_FREQUENCY 5400
-void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode *mode)
+void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
/* PHY should be in reset, like
* vc4_hdmi_encoder_disable() does.
@@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
}
-void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode *mode)
+void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
const struct phy_lane_settings *chan0_settings, *chan1_settings,
*chan2_settings, *clock_settings;
const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
- unsigned long long pixel_freq = mode->clock * 1000;
+ unsigned long long pixel_freq = conn_state->pixel_rate;
unsigned long long vco_freq;
unsigned char word_sel;
u8 vco_sel, vco_div;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
From: Colin Ian King
Currently there is a null pointer check for hdmi_phy that implies it
may be null, however a dev_err messages dereferences this potential null
pointer. Avoid a null pointer dereference by only emitting the dev_err
message if hdmi_phy is non-null. It is a moot point if the error message
needs to be printed at all, but since this is a relatively new piece of
code it may be useful to keep the message in for the moment in case there
are unforseen errors that need to be reported.
Addresses-Coverity: ("Dereference after null check")
Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file")
Signed-off-by: Colin Ian King
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index c5c61f5a9ea0..5184054783c7 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -84,8 +84,9 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy *hdmi_phy)
hdmi_phy->conf->hdmi_phy_disable_tmds)
return &mtk_hdmi_phy_dev_ops;
- dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
- return NULL;
+ if (hdmi_phy)
+ dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
+ return NULL;
}
static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: add legacy support for using degamma for gamma
On Sat, Dec 05, 2020 at 12:35:25AM +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
> > We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> > be used to handle legacy gamma-set ioctl.
> > drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> > CTM and DEGAMMA_LUT. This works fine on HW where we have either:
> >
> > degamma -> ctm -> gamma -> out
> >
> > or
> >
> > ctm -> gamma -> out
> >
> > However, if the HW has gamma table before ctm, the atomic property
> > should be DEGAMMA_LUT, and thus we have:
> >
> > degamma -> ctm -> out
> >
> > This is fine for userspace which sets gamma table using the properties,
> > as the userspace can check for the existence of gamma & degamma, but the
> > legacy gamma-set ioctl does not work.
> >
> > This patch fixes the issue by changing
> > drm_atomic_helper_legacy_gamma_set() so that GAMMA_LUT will be used if
> > it exists, and DEGAMMA_LUT will be used as a fallback.
> >
> > Signed-off-by: Tomi Valkeinen
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
> > drivers/gpu/drm/drm_color_mgmt.c| 4
> > include/drm/drm_crtc.h | 3 +++
> > 3 files changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ba1507036f26..fe59c8ea42a9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3512,6 +3512,10 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> > * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> > * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> > for
> > * how the atomic color management and gamma tables work.
> > + *
> > + * This function uses the GAMMA_LUT or DEGAMMA_LUT property for the gamma
> > table.
> > + * GAMMA_LUT property is used if it exists, and DEGAMMA_LUT property is
> > used as
> > + * a fallback.
> > */
> > int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >u16 *red, u16 *green, u16 *blue,
> > @@ -3525,6 +3529,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > struct drm_color_lut *blob_data;
> > int i, ret = 0;
> > bool replaced;
> > + bool use_degamma;
> > +
> > + if (!crtc->has_gamma_prop && !crtc->has_degamma_prop)
> > + return -ENODEV;
> > +
> > + use_degamma = !crtc->has_gamma_prop;
> >
> > state = drm_atomic_state_alloc(crtc->dev);
> > if (!state)
> > @@ -3554,10 +3564,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > goto fail;
> > }
> >
> > - /* Reset DEGAMMA_LUT and CTM properties. */
> > - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > + /* Set GAMMA/DEGAMMA_LUT and reset DEGAMMA/GAMMA_LUT and CTM */
> > + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
> > + use_degamma ? blob : NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> > + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
> > + use_degamma ? NULL : blob);
> > crtc_state->color_mgmt_changed |= replaced;
> >
> > ret = drm_atomic_commit(state);
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 3bcabc2f6e0e..956e59d5f6a7 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -176,6 +176,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >degamma_lut_size);
> > }
> >
> > + crtc->has_degamma_prop = !!degamma_lut_size;
> > +
> > if (has_ctm)
> > drm_object_attach_property(&crtc->base,
> >config->ctm_property, 0);
> > @@ -187,6 +189,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >config->gamma_lut_size_property,
> >gamma_lut_size);
> > }
> > +
> > + crtc->has_gamma_prop = !!gamma_lut_size;
> > }
> > EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index ba839e5e357d..9e1f06047e3d 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -1084,6 +1084,9 @@ struct drm_crtc {
> > */
> > uint16_t *gamma_store;
> >
> > + bool has_gamma_prop;
> > + bool has_degamma_prop;
>
> We could use a bitfield to save a bit of memory. Apart from that, the
> patch looks good to me.
Or we could just check if the crtc has the relevant prop or not.
>
> Reviewed-by: Laurent Pinchart
>
> > +
> >
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole approach
here isn't correct.
See even when the job has been completed or canceled we still want to
restart the timer.
The reason for this is that the timer is then not restarted for the current
job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole device was
hot plugged and we return -ENODEV here. E.g. what Andrey has been working on.
We discussed this with Luben off line a few days ago but came to a conclusion
that for the next job the timer restart in drm_sched_job_begin should do the
work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts the
timeout in case the hardware was idle before.
drm_sched_job_begin only adds the job to ring mirror list and rearms the timer,
I don't see how it is related to whether the HW was idle before ?
Andrey
The function should probably be renamed to drm_sched_job_pushed() because it
doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
*s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct
drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_
[PATCH] drm/ttm: cleanup BO size handling
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->size is the original size of the BO in arbitrary
units, usually bytes.
bo->mem.num_pages is the size in number of pages in the
resource domain of bo->mem.mem_type.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +--
drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
drivers/gpu/drm/radeon/radeon_object.c| 13
drivers/gpu/drm/radeon/radeon_object.h| 4 +--
drivers/gpu/drm/radeon/radeon_prime.c | 4 +--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 33 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++--
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++--
include/drm/ttm/ttm_bo_api.h | 6 ++--
include/drm/ttm/ttm_resource.h| 1 -
36 files changed, 82 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e5919efca870..c4c93f19d273 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
case TTM_PL_TT:
sgt = drm_prime_pages_to_sg(obj->dev,
bo->tbo.ttm->pages,
- bo->tbo.num_pages);
+ bo->tbo.ttm->num_pages);
if (IS_ERR(sgt))
return sgt;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 056cb87d09ea..52bcd1b5582f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
- if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
+ if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..381ecc4788d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
if (r < 0)
return r;
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index ed47cbac4f75..176ed3615151 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(struct amdgpu_bo
*bo)
static inline unsigned long amdgpu_bo_size(struct amdgpu_bo *bo)
{
- return bo->tbo.num_pages << PAGE_SHIFT;
+ return bo->tbo.size;
}
static inline unsigned amdgpu_bo_ngpu_pages(struct amdgpu_bo *bo)
{
- return (bo->tbo.num_pages << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
+ return bo->tbo.size / AMDGPU_GPU_PAGE_SIZE;
}
static inline unsigned amdgpu_bo_gpu_page_align
Re: [PATCH v3 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
On Mon, 07 Dec 2020 11:20:55 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qxp/qm Display Processing Unit. > > Signed-off-by: Liu Ying > --- > Note that this depends on the 'two cell binding' clock patch set which has > already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h > won't be found. > > v2->v3: > * No change. > > v1->v2: > * Fix yamllint warnings. > * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the > display controller subsystem spec does say that they exist. > * Use new dt binding way to add clocks in the example. > * Trivial tweaks for the example. > > .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 > + > 1 file changed, 416 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
