[PATCH 1/2] drm: sun4i/dsi: factor out DSI PHY poweron and poweroff
Factor out PHY poweron and poweroff sequences from sun6i_dsi_encoder_enable
and sun6i_dsi_encoder_disable.This leaves nothing to be be done in
sun6i_dsi_encoder_disable, so get rid of that. Also remove
drm_panel_ as these would be invoked the
modeset helpers.
Signed-off-by: Brandon Cheo Fusi
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 64 --
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 4 ++
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 760ff05ea..4dc92109e 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -713,7 +713,7 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
return 0;
}
-static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
+void sun6i_dsi_phy_power_on(const struct drm_encoder *encoder)
{
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
@@ -768,43 +768,12 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
phy_set_mode(dsi->dphy, PHY_MODE_MIPI_DPHY);
phy_configure(dsi->dphy, &opts);
phy_power_on(dsi->dphy);
-
- if (dsi->panel)
- drm_panel_prepare(dsi->panel);
-
- /*
-* FIXME: This should be moved after the switch to HS mode.
-*
-* Unfortunately, once in HS mode, it seems like we're not
-* able to send DCS commands anymore, which would prevent any
-* panel to send any DCS command as part as their enable
-* method, which is quite common.
-*
-* I haven't seen any artifact due to that sub-optimal
-* ordering on the panels I've tested it with, so I guess this
-* will do for now, until that IP is better understood.
-*/
- if (dsi->panel)
- drm_panel_enable(dsi->panel);
-
- sun6i_dsi_start(dsi, DSI_START_HSC);
-
- udelay(1000);
-
- sun6i_dsi_start(dsi, DSI_START_HSD);
}
-static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
+void sun6i_dsi_phy_power_off(const struct drm_encoder *encoder)
{
struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
- DRM_DEBUG_DRIVER("Disabling DSI output\n");
-
- if (dsi->panel) {
- drm_panel_disable(dsi->panel);
- drm_panel_unprepare(dsi->panel);
- }
-
phy_power_off(dsi->dphy);
phy_exit(dsi->dphy);
@@ -813,6 +782,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder
*encoder)
regulator_disable(dsi->regulator);
}
+static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder, struct
drm_atomic_state *old_state)
+{
+ struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
+
+ DRM_DEBUG_DRIVER("Enabling DSI output\n");
+
+ sun6i_dsi_start(dsi, DSI_START_HSC);
+
+ udelay(1000);
+
+ sun6i_dsi_start(dsi, DSI_START_HSD);
+
+ /*
+* NOTE
+*
+* Unfortunately, once in HS mode, it seems like we're not
+* able to send DCS commands anymore, which would prevent any
+* panel to send any DCS command as part as their enable
+* method, which is quite common.
+*
+* So maybe panels/bridges should send any init DCS commands in their
+* prepare/pre_enable methods? This should work as the DSI PHY is active
+* before those hooks are called.
+*
+* This will do for now, until that IP is better understood.
+*/
+}
+
static int sun6i_dsi_get_modes(struct drm_connector *connector)
{
struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
@@ -843,7 +840,6 @@ static const struct drm_connector_funcs
sun6i_dsi_connector_funcs = {
};
static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
- .disable= sun6i_dsi_encoder_disable,
.enable = sun6i_dsi_encoder_enable,
};
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index f1ddefe0f..a0b541f48 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -40,6 +40,10 @@ struct sun6i_dsi {
const struct sun6i_dsi_variant *variant;
};
+void sun6i_dsi_phy_power_on(const struct drm_encoder *encoder);
+
+void sun6i_dsi_phy_power_off(const struct drm_encoder *encoder);
+
static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
{
return container_of(host, struct sun6i_dsi, host);
--
2.30.2
[PATCH 0/2] drm: sun4i/dsi: allow modeset helpers to manage display
This change moves DSI PHY poweron/off from the encoder to the TCON. As a consequence enabling or disabling the DSI sink can be left to the modeset helpers, and bridge support easily introduced without touching the drm_encoder.bridge_chain or converting the encoder to a drm_bridge. Brandon Cheo Fusi (2): drm: sun4i/dsi: factor out DSI PHY poweron and poweroff drm: sun4i: tie DSI PHY Poweron/off to crtc enable/disable drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +++- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 64 -- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 4 ++ 3 files changed, 43 insertions(+), 35 deletions(-) -- 2.30.2
[PATCH 2/2] drm: sun4i: tie DSI PHY Poweron/off to crtc enable/disable
Poweron/off the DSI PHY when the crtc is enabled/disabled. This allows the
modeset
helpers to manage the DSI sink while preserving the old
drm_panel_
and drm_panel_ sequences.
Signed-off-by: Brandon Cheo Fusi
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 523a6d787..6f50dc66a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -190,7 +190,7 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
const struct drm_encoder *encoder,
bool enabled)
{
- bool is_lvds = false;
+ bool is_lvds = false, is_dsi = false;
int channel;
switch (encoder->encoder_type) {
@@ -198,6 +198,8 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
is_lvds = true;
fallthrough;
case DRM_MODE_ENCODER_DSI:
+ is_dsi = true;
+ fallthrough;
case DRM_MODE_ENCODER_NONE:
channel = 0;
break;
@@ -221,6 +223,12 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
sun4i_tcon_lvds_set_status(tcon, encoder, true);
sun4i_tcon_channel_set_status(tcon, channel, enabled);
+
+ if (is_dsi) {
+ /* turn DSI phy on or off */
+ (enabled) ? sun6i_dsi_phy_power_on(encoder)
+ : sun6i_dsi_phy_power_off(encoder);
+ }
}
void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable)
--
2.30.2
Re: RFC: DSI/DRM multiplexer bridge
Am Donnerstag, 6. April 2023, 11:55:52 CEST schrieb Jagan Teki: > [Replying the Daniel thread since he included bridge maintainers] > > On Thu, Apr 6, 2023 at 2:07 PM Daniel Vetter wrote: > > Adding the usual bridge maintainer/review folks since this looks tricky. > > -Daniel > > > > On Thu, 6 Apr 2023 at 10:33, Alexander Stein > > > > wrote: > > > Hi Jagan, > > > > > > thanks for your reply. > > > > > > Am Mittwoch, 5. April 2023, 16:39:07 CEST schrieb Jagan Teki: > > > > On Wed, Apr 5, 2023 at 7:39 PM Alexander Stein > > > > > > > > wrote: > > > > > Hi, > > > > > > > > > > my platform has a DIP switch controlled multiplexer for MIPI DSI > > > > > output > > > > > signals. One output has a TI SN65DSI84 (LVDS) and the other output > > > > > has a > > > > > TI > > > > > SN65DSI86 (eDP) attached to it. The Multiplexer status can be read > > > > > back > > > > > from a GPIO. The GPIO is also IRQ capable, so it would be possible > > > > > to > > > > > support hotplug additionally later on. > > > > > > > > I have this requirement a year back [1] but my design has i.mx8mq DSI > > > > outputs to SN65DSI84(LVDS) and ADV7533 (HDMI) and GPIO has muxed as > > > > IRQ in order to find the bridge selection. (not confused with HDMI > > > > HPD). > > > > > > Looks quite similar. This platform can be used using imx8mq, imx8mm or > > > im8xmn. That mentioned GPIO is also not the HDMI HPD, but connected to > > > a DIP switch on the mainboard to be changed manually. > > So, you need to manually adjust the switch and boot the required > output and the state of the output depends on the set switch gpios > isn't it? do you need to set any gpio so that the required output will > select? That's correct. There is no GPIO I need to set by software for the outputs (despite the enable GPIO on the DSI-to-X bridges, but this is handled in their appropriate drivers). > > > > > My initial idea was to create a DRM multiplexer bridge driver which > > > > > (depending on the input GPIO) allows only one output to be enabled. > > > > > Unfortunately ti- sn65dsi86.c driver expects a DSI host on remote > > > > > node 0 > > > > > (see ti_sn_attach_host and ti_sn_bridge_parse_dsi_host), so it does > > > > > not > > > > > work. ti-sn65dsi83.c just requires a drm_bridge. > > > > > > > > Yes, we need to have a finite amount of pipeline changes. assuming > > > > that your mux bridge sits between DSI to Output interfaces the > > > > proposed mux bridge selects which pipeline. > > > > > > My setup looks like this, but the switch is a different one than yours. > > > > > > | => SN54DSI86 => DP Connector > > > > > > DSI Host => display-switch => | > > > > > > | => SN65DSI83 => Panel-Simple > > This looks correct to me, as I designed the similar one. > > > > > > What is the best approach for this? I currently see two approaches: > > > > > * Create an explicit DSI/DRM multiplexer bridge driver which > > > > > registers > > > > > itself as DSI host > > > > > * Create a DRM multiplexer bridge (only). But this needs to remove > > > > > the DSI > > > > > device registration from ti-sn65dsi86.c > > > > > > > > Based on my experience, having a muxed bridge between in and out would > > > > be proper in order to satisfy the pipeline as well as the design. That > > > > mux bridge has to be a normal bridge doesn't aware of DSI or any other > > > > interface like one of the submissions has done in the recent mailing > > > > list. [2] Things would be complicated when we switch the outputs but > > > > we still use normal static switching of outputs in a proper way. > > > > > > > > > I am aware that DSI support is suboptimal, so I'm not sure which > > > > > approach > > > > > on the TI bridge drivers is the correct one and needs to be > > > > > considered as > > > > > given. Any ideas? > > > > > > > > I did implement some complicated things of switching outputs at > > > > runtime but the idea of the switching pipelines would be similar if > > > > you want to implement it in a normal static way. Here are some details > > > > and a demo of how those been worked. [3] [4] > > > > > > Thanks for the links. From what I read in those discussions dynamically > > > (re)building the bridge chains it not correct/acceptable. Instead two > > > bridges shall be created, but only one connector at the end shall be > > > enabled. This> > > > > would look like this: > > >switched-bridge > > > > > > ++ +-+ > > > > > > | drm_bridge-|- next_bridge -- | LVDS bridge |- connector > > > | > > > || +-+ > > > > > > in -|| > > > > > > || +-+ > > > | > > > | drm_bridge-|- next_bridge -- | eDP bridge |- connector > > > > > > ++ +-+ > > > > > > ^ > > > > > > DIP s
Re: [RFC 1/2] drm: Add fdinfo memory stats
Hi Rob,
On Thu, 6 Apr 2023 14:59:16 -0700
Rob Clark wrote:
> From: Rob Clark
>
> Add a helper to dump memory stats to fdinfo. For the things the drm
> core isn't aware of, use a callback.
>
> Signed-off-by: Rob Clark
> ---
> Documentation/gpu/drm-usage-stats.rst | 21 +++
> drivers/gpu/drm/drm_file.c| 79 +++
> include/drm/drm_file.h| 10
> 3 files changed, 110 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b46327356e80..56e3c95b6e0a 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -105,6 +105,27 @@ object belong to this client, in the respective memory
> region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-shared-memory: [KiB|MiB]
> +
> +The total size of buffers that are shared with another file (ie. have more
> +than a single handle).
> +
> +- drm-private-memory: [KiB|MiB]
> +
> +The total size of buffers that are not shared with another file.
> +
> +- drm-resident-memory: [KiB|MiB]
> +
> +The total size of buffers that are resident in system memory.
> +
> +- drm-purgeable-memory: [KiB|MiB]
> +
> +The total size of buffers that are purgable.
> +
> +- drm-active-memory: [KiB|MiB]
> +
> +The total size of buffers that are active on one or more rings.
> +
> - drm-cycles-
>
> Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index a51ff8cee049..21911d6ff38d 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -868,6 +869,84 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void print_size(struct drm_printer *p, const char *stat, size_t sz)
> +{
> + const char *units[] = {"B", "KiB", "MiB", "GiB"};
> + unsigned u;
> +
> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> + if (sz < SZ_1K)
> + break;
> + sz /= SZ_1K;
> + }
> +
> + drm_printf(p, "%s:\t%lu %s\n", stat, sz, units[u]);
> +}
> +
> +/**
> + * drm_print_memory_stats - Helper to print standard fdinfo memory stats
> + * @file: the DRM file
> + * @p: the printer to print output to
> + * @status: callback to get driver tracked object status
> + *
> + * Helper to iterate over GEM objects with a handle allocated in the
> specified
> + * file. The optional status callback can return additional object state
> which
> + * determines which stats the object is counted against. The callback is
> called
> + * under table_lock. Racing against object status change is "harmless", and
> the
> + * callback can expect to not race against object destroy.
> + */
> +void drm_print_memory_stats(struct drm_file *file, struct drm_printer *p,
> + enum drm_gem_object_status (*status)(struct
> drm_gem_object *))
Nit: status() returning an 'enum drm_gem_object_status' makes it look
like it can only return one of the DRM_GEM_OBJECT_* flag, when it can
actually be a combination of flags. Should we make it return an u32
instead? At the very least this should be clarified in the function doc.
> +{
> + struct drm_gem_object *obj;
> + struct {
> + size_t shared;
> + size_t private;
> + size_t resident;
> + size_t purgeable;
> + size_t active;
> + } size = {0};
> + int id;
> +
> + spin_lock(&file->table_lock);
> + idr_for_each_entry (&file->object_idr, obj, id) {
> + enum drm_gem_object_status s = 0;
> +
> + if (status)
> + s = status(obj);
> +
> + if (obj->handle_count > 1) {
> + size.shared += obj->size;
> + } else {
> + size.private += obj->size;
> + }
> +
> + if (s & DRM_GEM_OBJECT_RESIDENT) {
> + size.resident += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_PURGEABLE)
> + size.purgeable += obj->size;
> + }
> + spin_unlock(&file->table_lock);
> +
> + print_size(p, "drm-shared-memory", size.shared);
> + print_size(p, "drm-private-memory", size.private);
> +
> + if (status) {
> + print_size(p, "drm-resident-memory", size.resident);
> + print_size(p, "drm-purgeable-memory", size.purgeable);
> + print_size(p, "drm-active-
Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
Hi Thomas,
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Generic implementations of fb_pgprotect() and fb_is_primary_device()
> have been in the source code for a long time. Prepare the header file
> to make use of them.
>
> Improve the code by using an inline function for fb_pgprotect()
> and by removing include statements. The default mode set by
> fb_pgprotect() is now writecombine, which is what most platforms
> want.
>
> Symbols are protected by preprocessor guards. Architectures that
> provide a symbol need to define a preprocessor token of the same
> name and value. Otherwise the header file will provide a generic
> implementation. This pattern has been taken from .
>
> v2:
> * use writecombine mappings by default (Arnd)
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- a/include/asm-generic/fb.h
> +++ b/include/asm-generic/fb.h
> @@ -1,13 +1,32 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> +
> #ifndef __ASM_GENERIC_FB_H_
> #define __ASM_GENERIC_FB_H_
> -#include
>
> -#define fb_pgprotect(...) do {} while (0)
> +/*
> + * Only include this header file from your architecture's .
> + */
> +
> +#include
> +
> +struct fb_info;
> +struct file;
> +
> +#ifndef fb_pgprotect
> +#define fb_pgprotect fb_pgprotect
> +static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> + unsigned long off)
Does this affect any noMMU platforms that relied on fb_pgprotect()
doing nothing before?
Perhaps the body below should be protected by "#ifdef CONFIG_MMU"?
> +{
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
Shouldn't this use the pgprot_val() wrapper?
> +}
> +#endif
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
Re: [PATCH v2 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Merge all variants of fb_pgprotect() into a single function body.
> There are two different cases for MMU systems. For non-MMU systems,
> the function body will be empty. No functional changes, but this
> will help with the switch to .
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
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
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
+ val = lsdc_crtc_rreg32(ldev, LSDC_CRTC0_CFG_REG, index);
+ /* clear old dma step settings */
+ val &= ~CFG_DMA_STEP_MASK;
+
+ if (descp->chip == CHIP_LS7A2000) {
+ /*
+* Using large dma step as much as possible,
+* for improve hardware DMA efficiency.
+*/
+ if (width_in_bytes % 256 == 0)
+ val |= LSDC_DMA_STEP_256_BYTES;
+ else if (width_in_bytes % 128 == 0)
+ val |= LSDC_DMA_STEP_128_BYTES;
+ else if (width_in_bytes % 64 == 0)
+ val |= LSDC_DMA_STEP_64_BYTES;
+ else /* width_in_bytes % 32 == 0 */
+ val |= LSDC_DMA_STEP_32_BYTES;
+ }
+
+ clk_func->update(pixpll, &priv_state->pparms);
+
Without knowing the hardware, the clk_func abstraction seems quite
arbitrary and unnecessary. It should be introduced when there is a
use-case for it.
The clk_func is necessary, clk_func->update() will eventually call
ls7a1000_pixpll_param_update()
to generate pixel clock frequency required by the display device. There
is a abstract because different
bridges chip/SoC variants has the different register to operate, either
because the register offset changed
or the arrangement of specific bits field changed.
For the point view of the hardware, the PLL hardware belong to the
bridge chip.
There is a clock tree which wrangler all of the PLL hardware, sub-device
may partially share the hardware PLL.
The abstraction is used to suppress hardware variants which may change over
time.
For ls7a1000, there is user manual document about the clock tree and PLL,
see[1][2][3]
[1]
https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanual-EN#description-of-clock-function
[2]
https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanual-EN#section-pll-pix-0-configuration-register
[3]
https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanual-EN#configuration-method-of-pll
Re: [PATCH v2 08/19] arch/m68k: Implement with generic helpers
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> v2:
> * provide empty fb_pgprotect() on non-MMU systems
>
> Signed-off-by: Thomas Zimmermann
> Cc: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
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
Re: [PATCH] drm/vkms: add module parameter to set background color
Hi Maíra,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Ma-ra-Canal/drm-vkms-add-module-parameter-to-set-background-color/20230407-012233
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230406172002.124456-1-mcanal%40igalia.com
patch subject: [PATCH] drm/vkms: add module parameter to set background color
config: i386-randconfig-m031-20230403
(https://download.01.org/0day-ci/archive/20230408/202304082018.pxawwhse-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Link: https://lore.kernel.org/r/202304082018.pxawwhse-...@intel.com/
smatch warnings:
drivers/gpu/drm/vkms/vkms_composer.c:93 blend() warn: right shifting more than
type allows 32 vs 32
vim +93 drivers/gpu/drm/vkms/vkms_composer.c
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
82 static void blend(struct vkms_device *vkms_dev,
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
83 struct vkms_writeback_job *wb,
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
84 struct vkms_crtc_state *crtc_state,
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
85 u32 *crc32, struct line_buffer *stage_buffer,
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
86 struct line_buffer *output_buffer, size_t row_size)
39cba5cf8c2c23 drivers/gpu/drm/vkms/vkms_composer.c Melissa Wen 2020-08-25
87 {
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
88 struct vkms_plane_state **plane = crtc_state->active_planes;
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
89 u32 n_active_planes = crtc_state->num_active_planes;
39cba5cf8c2c23 drivers/gpu/drm/vkms/vkms_composer.c Melissa Wen 2020-08-25
90
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
91 const struct pixel_argb_u16 background_color = {
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
92 .a = 0x,
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
@93 .r = (*vkms_dev->config->background_color >> 32) & 0x,
This shift always results in zero.
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
94 .g = (*vkms_dev->config->background_color >> 16) & 0x,
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
95 .b = *vkms_dev->config->background_color & 0x,
d725068207852d drivers/gpu/drm/vkms/vkms_composer.c Maíra Canal 2023-04-06
96 };
32a1648aca4409 drivers/gpu/drm/vkms/vkms_composer.c Melissa Wen 2021-04-24
97
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
98 size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
39cba5cf8c2c23 drivers/gpu/drm/vkms/vkms_composer.c Melissa Wen 2020-08-25
99
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
100 for (size_t y = 0; y < crtc_y_limit; y++) {
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
101 fill_background(&background_color, output_buffer);
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
102
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
103 /* The active planes are composed associatively in z-order. */
bc0d7fdefec62e drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
104 for (size_t i = 0; i < n_active_planes; i++) {
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
105 if (!check_y_limit(plane[i]->frame_info, y))
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
106 continue;
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
107
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
108 plane[i]->plane_read(stage_buffer,
plane[i]->frame_info, y);
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
109 pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
8ba1648567e289 drivers/gpu/drm/vkms/vkms_composer.c Igor Torrente 2022-09-05
110 outp
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
--- /dev/null
+++ b/drivers/gpu/drm/loongson/lsdc_drv.c
+static const struct lsdc_desc dc_in_ls7a1000 = {
+ .chip = CHIP_LS7A1000,
+ .num_of_crtc = LSDC_NUM_CRTC,
+ .max_pixel_clk = 20,
+ .max_width = 2048,
+ .max_height = 2048,
+ .num_of_hw_cursor = 1,
+ .hw_cursor_w = 32,
+ .hw_cursor_h = 32,
+ .pitch_align = 256,
+ .mc_bits = 40,
+ .has_vblank_counter = false,
+ .has_scan_pos = true,
+ .has_builtin_i2c = true,
+ .has_vram = true,
+ .has_hpd_reg = false,
+ .is_soc = false,
+};
+
+static const struct lsdc_desc dc_in_ls7a2000 = {
+ .chip = CHIP_LS7A2000,
+ .num_of_crtc = LSDC_NUM_CRTC,
+ .max_pixel_clk = 35,
+ .max_width = 4096,
+ .max_height = 4096,
+ .num_of_hw_cursor = 2,
+ .hw_cursor_w = 64,
+ .hw_cursor_h = 64,
+ .pitch_align = 64,
+ .mc_bits = 40, /* support 48, but use 40 for backward compatibility */
+ .has_vblank_counter = true,
+ .has_scan_pos = true,
+ .has_builtin_i2c = true,
+ .has_vram = true,
+ .has_hpd_reg = true,
+ .is_soc = false,
+};
+
Roughly a quarter of the above are identical. It might be better to
drop them for now and re-introduce as needed with future code.
My initial intent here is to give a skeleton of our hardware features to
reviewers,
Not only for gearing the control, but also for easier the reviewing process.
Without this, other part of this patch may looks questionable again.
We could remove all of the features look up key in the struct lsdc_desc,
leave the .chip member there only. Hard coded everything else according
to the chip only.
But the code looks ugly by doing that way. We want weaken the
If loongson SoC is introduced, the identical will decrease.
It's OK, I could drop as much as possible at next version.
+const char *chip_to_str(enum loongson_chip_family chip)
+{
+ if (chip == CHIP_LS7A2000)
+ return "LS7A2000";
+
+ if (chip == CHIP_LS7A1000)
+ return "LS7A1000";
+
If it were me, I would add the name into the lsdc_desc.
Agree, this is acceptable. Will be changed at the next version.
Re: [PATCH v2] drm/vkms: add module parameter to set background color
Hi, On Monday, April 10th, 2023 at 19:50, Melissa Wen wrote: > On 04/10, Simon Ser wrote: > > > I think this should be a KMS property instead of a module parameter. > > Is there a reason why this patch uses a module parameter? It breaks > > user-space expectations. > > a KMS property is what we have on vkms TODO [1] and the module parameter > was Maíra's first step to open a discussion for this property [2]. > AFAIK, we would need to create the KMS property first, but it seems > there isn't an userspace case/need to support this API change. > Do you know any valid use cases to support a bkg color property? There have been previous attempts for msm [1] and i915 [2]. >From user-space PoV, a KMS property would be useful, for instance to render single color background images. I can type some user-space code if that helps. If this is a module parameter instead of a KMS property, what purpose does this achieve? What is the use-case? Just trying to understand the motivation here. Thanks, Simon [1]: https://lore.kernel.org/dri-devel/20221028225952.160-1-quic_jessz...@quicinc.com/ [2]: https://lore.kernel.org/dri-devel/20190930224707.14904-1-matthew.d.ro...@intel.com/
Re: [Intel-gfx] [PATCH v4 1/5] drm/i915: Throttle for ringspace prior to taking the timeline mutex
On 08.03.2023 10:41, Andi Shyti wrote:
From: Chris Wilson
Before taking exclusive ownership of the ring for emitting the request,
wait for space in the ring to become available. This allows others to
take the timeline->mutex to make forward progresses while userspace is
blocked.
In particular, this allows regular clients to issue requests on the
kernel context, potentially filling the ring, but allow the higher
priority heartbeats and pulses to still be submitted without being
blocked by the less critical work.
Signed-off-by: Chris Wilson
Cc: Maciej Patelczyk
Cc: sta...@vger.kernel.org
Signed-off-by: Andi Shyti
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_context.c | 41 +
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/i915_request.c | 3 ++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b89..59cd612a23561 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -626,6 +626,47 @@ bool intel_context_revoke(struct intel_context *ce)
return ret;
}
+int intel_context_throttle(const struct intel_context *ce)
+{
+ const struct intel_ring *ring = ce->ring;
+ const struct intel_timeline *tl = ce->timeline;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (READ_ONCE(ring->space) >= SZ_1K)
+ return 0;
+
+ rcu_read_lock();
+ list_for_each_entry_reverse(rq, &tl->requests, link) {
+ if (__i915_request_is_complete(rq))
+ break;
+
+ if (rq->ring != ring)
+ continue;
+
+ /* Wait until there will be enough space following that rq */
+ if (__intel_ring_space(rq->postfix,
+ ring->emit,
+ ring->size) < ring->size / 2) {
+ if (i915_request_get_rcu(rq)) {
+ rcu_read_unlock();
+
+ if (i915_request_wait(rq,
+ I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0)
+ err = -EINTR;
+
+ rcu_read_lock();
+ i915_request_put(rq);
+ }
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return err;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f43..f919a66cebf5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -226,6 +226,8 @@ static inline void intel_context_exit(struct intel_context
*ce)
ce->ops->exit(ce);
}
+int intel_context_throttle(const struct intel_context *ce);
+
static inline struct intel_context *intel_context_get(struct intel_context
*ce)
{
kref_get(&ce->ref);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 630a732aaecca..72aed544f8714 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1034,6 +1034,9 @@ i915_request_create(struct intel_context *ce)
struct i915_request *rq;
struct intel_timeline *tl;
+ if (intel_context_throttle(ce))
+ return ERR_PTR(-EINTR);
+
tl = intel_context_timeline_lock(ce);
if (IS_ERR(tl))
return ERR_CAST(tl);
Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans
The point is that this not only requires some work in the drm_scheduler, but rather it then makes only little sense to use the drm_scheduler in the first place. The whole point of the drm_scheduler is to provide dma_fence implementation for the submitted jobs. We also have dependency handling, but as Daniel and I said this can be easily extracted into a separate object/component. Regards, Christian. Am 07.04.23 um 02:20 schrieb Zeng, Oak: So this series basically go with option 2. The part that option2 makes me uncomfortable is, dma-fence doesn't work for long running workload, why we generate it in the first place? As long as dma-fence is generated, it will become a source of confusion in the future. It doesn't matter how much you annotate it/document it. So if we decide to go with option2, the bottom line is, don't generate dma-fence for long running workload during job submission. This requires some rework in drm scheduler. The cleanest solution to me is option3. Dma-fence is a very old technology. When it was created, no gpu support page fault. Obviously this is not a good technology for modern gpu with page fault support. I think the best way is to create a new scheduler and dependency tracking mechanism works for both page fault enabled and page fault disabled context. I think this matches what Christian said below. Maybe nobody think this is easy? Thanks, Oak -Original Message- From: Brost, Matthew Sent: April 5, 2023 2:53 PM To: Zeng, Oak Cc: Christian König ; Vetter, Daniel ; Thomas Hellström ; dri-devel@lists.freedesktop.org; intel- x...@lists.freedesktop.org; robdcl...@chromium.org; airl...@linux.ie; l...@asahilina.net; boris.brezil...@collabora.com; faith.ekstr...@collabora.com Subject: Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans On Wed, Apr 05, 2023 at 12:06:53PM -0600, Zeng, Oak wrote: Hi, Using dma-fence for completion/dependency tracking for long-run workload(more precisely on-demand paging/page fault enabled workload) can cause deadlock. This seems the significant issue here. Other issues such as the drm scheduler completion order implication etc are minors which can be solve inside the framework of drm scheduler. We need to evaluate below paths: 1) still use drm scheduler for job submission, and use dma-fence for job completion waiting/dependency tracking. This is solution proposed in this series. Annotate dma-fence for long-run workload: user can still wait dma-fence for job completion but can't wait dma-fence while holding any memory management locks. We still use dma-fence for dependency tracking. But it is just very easily run into deadlock when on-demand paging is in the picture. The annotation helps us to detect deadlock but not solve deadlock problems. Seems *not* a complete solution: It is almost impossible to completely avoid dependency deadlock in complex runtime environment No one can wait on LR fence, so it is impossible to deadlock. The annotations enforce this. Literally this is only for flow controling the ring / hold pending jobs in in the DRM schedule list. 2) Still use drm scheduler but not use dma-fence for completion signaling and dependency tracking. This way we still get some free functions (reset, err handling ring flow control as Matt said)from drm scheduler, but push the dependency/completion tracking completely to user space using techniques such as user space fence. User space doesn't have chance to wait fence while holding a kernel memory management lock, thus the dma-fence deadlock issue is solved. We use user space fence for syncs. 3) Completely discard drm scheduler and dma-fence for long-run workload. Use user queue/doorbell for super fast submission, directly interact with fw scheduler. Use user fence for completion/dependency tracking. This is a hard no from me, I want 1 submission path in Xe. Either we use the DRM scheduler or we don't. Matt Thanks, Oak -Original Message- From: Christian König Sent: April 5, 2023 3:30 AM To: Brost, Matthew ; Zeng, Oak Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; robdcl...@chromium.org; thomas.hellst...@linux.intel.com; airl...@linux.ie; l...@asahilina.net; boris.brezil...@collabora.com; faith.ekstr...@collabora.com Subject: Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans Am 04.04.23 um 20:08 schrieb Matthew Brost: On Tue, Apr 04, 2023 at 12:02:03PM -0600, Zeng, Oak wrote: Hi Matt, Thomas, Some very bold out of box thinking in this area: 1. so you want to use drm scheduler and dma-fence for long running workload. Why you want to do this in the first place? What is the benefit? Drm scheduler is pretty much a software scheduler. Modern gpu has scheduler built at fw/hw level, as you said below for intel this is Guc. Can xe driver just directly submit job to Guc, bypassing drm scheduler? If we did that now we have 2 paths for dependency track, fl
Re: [PATCH 2/2] drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for reading IOR state
Hi Lyude,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lyude-Paul/drm-nouveau-kms-Add-INHERIT-ioctl-to-nvkm-nvif-for-reading-IOR-state/20230408-062329
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230407222133.1425969-2-lyude%40redhat.com
patch subject: [PATCH 2/2] drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for
reading IOR state
config: csky-randconfig-m031-20230409
(https://download.01.org/0day-ci/archive/20230409/202304091929.sr0cfhln-...@intel.com/config)
compiler: csky-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Link: https://lore.kernel.org/r/202304091929.sr0cfhln-...@intel.com/
New smatch warnings:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2518 nv50_display_read_hw_or_state()
error: uninitialized symbol 'head_idx'.
vim +/head_idx +2518 drivers/gpu/drm/nouveau/dispnv50/disp.c
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2477 static inline void
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2478 nv50_display_read_hw_or_state(struct drm_device *dev, struct nv50_disp
*disp,
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2479struct nouveau_encoder *outp)
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2480 {
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2481 struct drm_crtc *crtc;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2482 struct drm_connector_list_iter conn_iter;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2483 struct drm_connector *conn;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2484 struct nv50_head_atom *armh;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2485 const u32 encoder_mask = drm_encoder_mask(&outp->base.base);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2486 bool found_conn = false, found_head = false;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2487 u8 proto;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2488 int head_idx;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2489 int ret;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2490
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2491 switch (outp->dcb->type) {
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2492 case DCB_OUTPUT_TMDS:
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2493 ret = nvif_outp_inherit_tmds(&outp->outp, &proto);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2494 break;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2495 case DCB_OUTPUT_DP:
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2496 ret = nvif_outp_inherit_dp(&outp->outp, &proto);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2497 break;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2498 case DCB_OUTPUT_LVDS:
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2499 ret = nvif_outp_inherit_lvds(&outp->outp, &proto);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2500 break;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2501 case DCB_OUTPUT_ANALOG:
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2502 ret = nvif_outp_inherit_rgb_crt(&outp->outp, &proto);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2503 break;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2504 default:
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2505 drm_dbg_kms(dev, "Readback for %s not implemented yet,
skipping\n",
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2506 outp->base.base.name);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2507 drm_WARN_ON(dev, true);
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c Lyude Paul 2023-04-07
2508 return;
a3d963915cf6f2 drivers/gpu/drm/nouveau/dispnv50/disp.c
Re: [PATCH] fbdev: Don't spam dmesg on bad userspace ioctl input
Hi Michel,
On Wed, Apr 5, 2023 at 10:50 AM Michel Dänzer
wrote:
> On 4/4/23 14:36, Daniel Vetter wrote:
> > There's a few reasons the kernel should not spam dmesg on bad
> > userspace ioctl input:
> > - at warning level it results in CI false positives
> > - it allows userspace to drown dmesg output, potentially hiding real
> > issues.
> >
> > None of the other generic EINVAL checks report in the
> > FBIOPUT_VSCREENINFO ioctl do this, so it's also inconsistent.
> >
> > I guess the intent of the patch which introduced this warning was that
> > the drivers ->fb_check_var routine should fail in that case. Reality
> > is that there's too many fbdev drivers and not enough people
> > maintaining them by far, and so over the past few years we've simply
> > handled all these validation gaps by tighning the checks in the core,
> > because that's realistically really all that will ever happen.
> >
> > Reported-by: syzbot+20dcf81733d43ddff...@syzkaller.appspotmail.com
> > Link:
> > https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb00bf06cefc
> > Fixes: 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")
> > Cc: Helge Deller
> > Cc: Geert Uytterhoeven
> > Cc: sta...@vger.kernel.org # v5.4+
> > Cc: Daniel Vetter
> > Cc: Javier Martinez Canillas
> > Cc: Thomas Zimmermann
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/video/fbdev/core/fbmem.c | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 875541ff185b..9757f4bcdf57 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1021,10 +1021,6 @@ fb_set_var(struct fb_info *info, struct
> > fb_var_screeninfo *var)
> > /* verify that virtual resolution >= physical resolution */
> > if (var->xres_virtual < var->xres ||
> > var->yres_virtual < var->yres) {
> > - pr_warn("WARNING: fbcon: Driver '%s' missed to adjust virtual
> > screen size (%ux%u vs. %ux%u)\n",
> > - info->fix.id,
> > - var->xres_virtual, var->yres_virtual,
> > - var->xres, var->yres);
> > return -EINVAL;
> > }
> >
>
> Make it pr_warn_once? 99.9...% of the benefit, without spam.
Except that it should be pr_warn_once_per_fb_info, which requires
a flag in fb_info.
If fb_info.fbops wasn't const, we could also nuke
info->fbops->check_var() ;-)
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
Re: [PATCH 1/2] drm/i915: constify pointers to hwmon_channel_info
On Fri, 07 Apr 2023, Krzysztof Kozlowski wrote:
> Statically allocated array of pointed to hwmon_channel_info can be made
> const for safety.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> This depends on hwmon core patch:
> https://lore.kernel.org/all/20230406203103.3011503-2-krzysztof.kozlow...@linaro.org/
>
> Therefore I propose this should also go via hwmon tree.
Thanks for doing this, I couldn't be bothered to follow through with it
[1].
Acked-by: Jani Nikula
[1] https://lore.kernel.org/r/20230309082841.400118-1-jani.nik...@intel.com
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: linux-hw...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 596dd2c07010..87b527a54272 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -267,7 +267,7 @@ static const struct attribute_group *hwm_groups[] = {
> NULL
> };
>
> -static const struct hwmon_channel_info *hwm_info[] = {
> +static const struct hwmon_channel_info * const hwm_info[] = {
> HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
> HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
> HWMON_P_CRIT),
> HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
> @@ -275,7 +275,7 @@ static const struct hwmon_channel_info *hwm_info[] = {
> NULL
> };
>
> -static const struct hwmon_channel_info *hwm_gt_info[] = {
> +static const struct hwmon_channel_info * const hwm_gt_info[] = {
> HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
> NULL
> };
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH RESEND v2 0/2] panel-simple: Add InnoLux G070ACE-L01 support
On Mon, Mar 13, 2023 at 08:50:15AM +0100, richard.leit...@linux.dev wrote: > This series adds support for the InnoLux G070ACE-L01 7" 800x480 TFT LCD > panel with WLED backlight. Friendly reminder for this small series 😉 > > Signed-off-by: Richard Leitner > --- > Richard Leitner (2): > dt-bindings: display: simple: add support for InnoLux G070ACE-L01 > drm/panel: simple: Add InnoLux G070ACE-L01 > > .../bindings/display/panel/panel-simple.yaml | 2 ++ > drivers/gpu/drm/panel/panel-simple.c | 35 > ++ > 2 files changed, 37 insertions(+) > --- > base-commit: c0b67534c95c537f7a506a06b98e5e85d72e2b7d > change-id: 20230201-innolux-g070ace-fda21c89efe2 > > Best regards, > -- > Richard Leitner >
Re: linux-next: build warning after merge of the drm tree
Hi Stephen,
On Tue, Apr 11, 2023 at 04:02:36PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/i915/gt/uc/intel_guc.h:274: warning: Function parameter or
> member 'dbgfs_node' not described in 'intel_guc'
>
> Introduced by commit
>
> 70b5ffb393f3 ("drm/i915/gt: Create per-gt debugfs files")
that's mine to take... will fix it!
Thanks!
Andi
Re: [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> When swapping out, we will split multi-order pages both in order to
> move them to the swap-cache and to be able to return memory to the
> swap cache as soon as possible on a page-by-page basis.
> Reduce the page max order to the system PMD size, as we can then be nicer
> to the system and avoid splitting gigantic pages.
>
> Looking forward to when we might be able to swap out PMD size folios
> without splitting, this will also be a benefit.
>
> v2:
> - Include all orders up to the PMD size (Christian König)
> v3:
> - Avoid compilation errors for architectures with special PFN_SHIFTs
>
> Signed-off-by: Thomas Hellström
> Reviewed-by: Christian König
Apparently this fails on ppc build testing. Please supply build fix asap
(or I guess we need to revert). I'm kinda not clear why this only showed
up when I merged the drm-misc-next pr into drm-next ...
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index dfce896c4bae..18c342a919a2 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -47,6 +47,11 @@
>
> #include "ttm_module.h"
>
> +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> +/* Some architectures have a weird PMD_SHIFT */
> +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER :
> MAX_ORDER)
> +
> /**
> * struct ttm_pool_dma - Helper object for coherent DMA mappings
> *
> @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
>
> static atomic_long_t allocated_pages;
>
> -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> -static struct ttm_pool_type global_uncached[MAX_ORDER];
> +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
>
> -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
>
> static spinlock_t shrinker_lock;
> static struct list_head shrinker_list;
> @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt
> *tt,
> else
> gfp_flags |= GFP_HIGHUSER;
>
> - for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> + for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
>num_pages;
>order = min_t(unsigned int, order, __fls(num_pages))) {
> struct ttm_pool_type *pt;
> @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
> *dev,
>
> if (use_dma_alloc) {
> for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> - for (j = 0; j < MAX_ORDER; ++j)
> + for (j = 0; j < TTM_DIM_ORDER; ++j)
> ttm_pool_type_init(&pool->caching[i].orders[j],
> pool, i, j);
> }
> @@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
>
> if (pool->use_dma_alloc) {
> for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> - for (j = 0; j < MAX_ORDER; ++j)
> + for (j = 0; j < TTM_DIM_ORDER; ++j)
> ttm_pool_type_fini(&pool->caching[i].orders[j]);
> }
>
> @@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
> unsigned int i;
>
> seq_puts(m, "\t ");
> - for (i = 0; i < MAX_ORDER; ++i)
> + for (i = 0; i < TTM_DIM_ORDER; ++i)
> seq_printf(m, " ---%2u---", i);
> seq_puts(m, "\n");
> }
> @@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type
> *pt,
> {
> unsigned int i;
>
> - for (i = 0; i < MAX_ORDER; ++i)
> + for (i = 0; i < TTM_DIM_ORDER; ++i)
> seq_printf(m, " %8u", ttm_pool_type_count(&pt[i]));
> seq_puts(m, "\n");
> }
> @@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> {
> unsigned int i;
>
> + BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
> + BUILD_BUG_ON(TTM_DIM_ORDER < 1);
> +
> if (!page_pool_size)
> page_pool_size = num_pages;
>
> spin_lock_init(&shrinker_lock);
> INIT_LIST_HEAD(&shrinker_list);
>
> - for (i = 0; i < MAX_ORDER; ++i) {
> + for (i = 0; i < TTM_DIM_ORDER; ++i) {
> ttm_pool_type_init(&global_write_combined[i], NULL,
> ttm_write_combined, i);
> ttm_pool_type_init(&global_uncached[i], NULL, ttm_uncached, i);
> @@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
> {
> unsigned int i;
>
> - for (i =
Re: linux-next: build failure after merge of the driver-core tree
On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/linkage.h:7,
> from include/linux/kernel.h:17,
> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> include/linux/export.h:27:22: error: passing argument 1 of 'class_create'
> from incompatible pointer type [-Werror=incompatible-pointer-types]
>27 | #define THIS_MODULE (&__this_module)
> | ~^~~
> | |
> | struct module *
> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro
> 'THIS_MODULE'
> 544 | mqc_dev_class = class_create(THIS_MODULE,
> MHI_QAIC_CTRL_DRIVER_NAME);
> | ^~~
> In file included from include/linux/device.h:31,
> from include/linux/mhi.h:9,
> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> include/linux/device/class.h:229:54: note: expected 'const char *' but
> argument is of type 'struct module *'
> 229 | struct class * __must_check class_create(const char *name);
> | ^~~~
> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to
> function 'class_create'
> 544 | mqc_dev_class = class_create(THIS_MODULE,
> MHI_QAIC_CTRL_DRIVER_NAME);
> | ^~~~
> include/linux/device/class.h:229:29: note: declared here
> 229 | struct class * __must_check class_create(const char *name);
> | ^~~~
>
> Caused by commit
>
> 1aaba11da9aa ("driver core: class: remove module * from class_create()")
>
> interacting with commit
>
> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>
> from the drm tree.
>
> I have applied the following merge fix patch for today.
>
> From: Stephen Rothwell
> Date: Tue, 11 Apr 2023 14:16:57 +1000
> Subject: [PATCH] fixup for "driver core: class: remove module * from
> class_create()"
>
> interacting with "accel/qaic: Add mhi_qaic_cntl"
>
> Signed-off-by: Stephen Rothwell
Thanks for the fixup. Since Dave is out I've made a note about this in my
handover mail so it won't get lost in the drm-next merge window pull. I
don't think we need any other coordination than mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).
-Daniel
> ---
> drivers/accel/qaic/mhi_qaic_ctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/accel/qaic/mhi_qaic_ctrl.c
> b/drivers/accel/qaic/mhi_qaic_ctrl.c
> index 0c7e571f1f12..96db1580c72d 100644
> --- a/drivers/accel/qaic/mhi_qaic_ctrl.c
> +++ b/drivers/accel/qaic/mhi_qaic_ctrl.c
> @@ -541,7 +541,7 @@ int mhi_qaic_ctrl_init(void)
> return ret;
>
> mqc_dev_major = ret;
> - mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> + mqc_dev_class = class_create(MHI_QAIC_CTRL_DRIVER_NAME);
> if (IS_ERR(mqc_dev_class)) {
> ret = PTR_ERR(mqc_dev_class);
> goto unregister_chrdev;
> --
> 2.39.2
>
> --
> Cheers,
> Stephen Rothwell
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [git pull] habanalabs for drm-next-6.4
On Mon, Apr 10, 2023 at 03:46:37PM +0300, Oded Gabbay wrote: > Hi Dave, Daniel. > > An additional pull request for 6.4. > > Mostly bug fixes and cleanups. > > Full details are in the signed tag. > > Thanks, > Oded > > The following changes since commit 4d877b1a6e855d1c8685fa0e27ad7a521b31b6ca: > > Merge tag 'drm-intel-next-2023-04-06' of > git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-04-06 > 16:31:33 +0200) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git > tags/drm-habanalabs-next-2023-04-10 > > for you to fetch changes up to 56499c461589634f2c89ffbd9cfb78268191d349: > > accel/habanalabs: add missing error flow in hl_sysfs_init() (2023-04-08 > 10:44:23 +0300) Pulled, thanks > > > This tag contains additional habanalabs driver changes for v6.4: > > - uAPI changes: > - Add a definition of a new Gaudi2 server type. This is used by userspace > to know what is the connectivity between the accelerators inside the > server > > - New features and improvements: > - speedup h/w queues test in Gaudi2 to reduce device initialization times. > > - Firmware related fixes: > - Fixes to the handshake protocol during f/w initialization. > - Sync f/w events interrupt in hard reset to avoid warning message. > - Improvements to extraction of the firmware version. > > - Misc bug fixes and code cleanups. Notable fixes are: > - Multiple fixes for interrupt handling in Gaudi2. > - Unmap mapped memory in case TLB invalidation fails. > > > Cai Huoqing (1): > accel/habanalabs: Remove redundant pci_clear_master > > Dafna Hirschfeld (2): > accel/habanalabs: check return value of add_va_block_locked > accel/habanalabs: improvements to FW ver extraction > > Dani Liberman (2): > accel/habanalabs: fix access error clear event > accel/habanalabs: fix handling of arc farm sei event > > Koby Elbaz (3): > accel/habanalabs: unmap mapped memory when TLB inv fails > accel/habanalabs: change COMMS warning messages to error level > accel/habanalabs: don't wait for STS_OK after sending COMMS WFE > > Moti Haimovski (1): > accel/habanalabs: speedup h/w queues test in Gaudi2 > > Oded Gabbay (1): > accel/habanalabs/uapi: new Gaudi2 server type > > Ofir Bitton (5): > accel/habanalabs: fix HBM MMU interrupt handling > accel/habanalabs: print raw binning masks in debug level > accel/habanalabs: fix wrong reset and event flags > accel/habanalabs: fixes for unexpected error interrupt > accel/habanalabs: remove Gaudi1 multi MSI code > > Tal Cohen (4): > accel/habanalabs: print event type when device is disabled > accel/habanalabs: remove duplicated disable pci msg > accel/habanalabs: send disable pci when compute ctx is active > accel/habanalabs: sync f/w events interrupt in hard reset > > Tomer Tayar (3): > accel/habanalabs: remove completion from abnormal interrupt work name > accel/habanalabs: fix events mask of decoder abnormal interrupts > accel/habanalabs: add missing error flow in hl_sysfs_init() > > drivers/accel/habanalabs/common/command_buffer.c | 15 +- > drivers/accel/habanalabs/common/decoder.c | 40 ++- > drivers/accel/habanalabs/common/device.c | 54 ++-- > drivers/accel/habanalabs/common/firmware_if.c | 17 +- > drivers/accel/habanalabs/common/habanalabs.h | 14 +- > drivers/accel/habanalabs/common/irq.c | 11 +- > drivers/accel/habanalabs/common/memory.c | 11 +- > drivers/accel/habanalabs/common/mmu/mmu.c | 8 +- > drivers/accel/habanalabs/common/pci/pci.c | 2 - > drivers/accel/habanalabs/common/sysfs.c| 6 +- > drivers/accel/habanalabs/gaudi/gaudi.c | 86 + > drivers/accel/habanalabs/gaudi/gaudiP.h| 15 - > drivers/accel/habanalabs/gaudi2/gaudi2.c | 347 > +++-- > drivers/accel/habanalabs/gaudi2/gaudi2P.h | 17 + > drivers/accel/habanalabs/goya/goya.c | 1 + > .../include/gaudi2/asic_reg/gaudi2_regs.h | 4 +- > include/uapi/drm/habanalabs_accel.h| 3 +- > 17 files changed, 382 insertions(+), 269 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 0/8] Enable DSI and ADV7535 on RZ/G2{L, LC} and RZ/V2L platforms
This patch series aims to Enable DSI by linking with ADV7535 on SMARC EVK
based on RZ/G2{L, LC} and RZ/V2L platforms.
patch#1 and #2 depend upon the binding patch [1]
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230406171324.837247-1-biju.das...@bp.renesas.com/
patch #4 depend upon the binding patch [2]
[2]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20230406171324.837247-2-biju.das...@bp.renesas.com/
Biju Das (8):
arm64: dts: renesas: r9a07g044: Add fcpvd node
arm64: dts: renesas: r9a07g054: Add fcpvd node
arm64: dts: renesas: r9a07g044: Add vspd node
arm64: dts: renesas: r9a07g054: Add vspd node
arm64: dts: renesas: r9a07g044: Add DSI node
arm64: dts: renesas: r9a07g054: Add DSI node
arm64: dts: renesas: rzg2l-smarc: Link DSI with ADV7535
arm64: dts: renesas: rzg2lc-smarc: Link DSI with ADV7535
arch/arm64/boot/dts/renesas/r9a07g044.dtsi| 53 +
arch/arm64/boot/dts/renesas/r9a07g054.dtsi| 54 +
arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 79 +++
arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi | 79 +++
4 files changed, 265 insertions(+)
--
2.25.1
[PATCH v2 1/8] arm64: dts: renesas: r9a07g044: Add fcpvd node
Add fcpvd node to RZ/G2L SoC DTSI.
Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
---
v1->v2:
* Added Rb tag from Geert.
---
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
index 487536696d90..e90c517077ab 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
@@ -618,6 +618,18 @@ sbc: spi@1006 {
status = "disabled";
};
+ fcpvd: fcp@1088 {
+ compatible = "renesas,r9a07g044-fcpvd",
+"renesas,fcpv";
+ reg = <0 0x1088 0 0x1>;
+ clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G044_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_LCDC_RESET_N>;
+ };
+
cpg: clock-controller@1101 {
compatible = "renesas,r9a07g044-cpg";
reg = <0 0x1101 0 0x1>;
--
2.25.1
[PATCH 2/2] drm: Spelling s/randevouz/rendez-vouz/
Fix a misspelling of "rendez-vouz". Signed-off-by: Geert Uytterhoeven --- include/drm/task_barrier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h index 217c1cf21c1ab7d5..59ead429acb2afb0 100644 --- a/include/drm/task_barrier.h +++ b/include/drm/task_barrier.h @@ -24,7 +24,7 @@ #include /* - * Reusable 2 PHASE task barrier (randevouz point) implementation for N tasks. + * Reusable 2 PHASE task barrier (rendez-vouz point) implementation for N tasks. * Based on the Little book of semaphores - https://greenteapress.com/wp/semaphores/ */ -- 2.34.1
[PATCH 1/2] drm: Spelling s/sempahore/semaphore/
Fix misspellings of "semaphore". Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/radeon/cik.c| 2 +- drivers/gpu/drm/radeon/r600.c | 2 +- include/drm/task_barrier.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 630a732aaecca8fb..0bb368a5dd0bb107 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1220,7 +1220,7 @@ emit_semaphore_wait(struct i915_request *to, /* * If this or its dependents are waiting on an external fence * that may fail catastrophically, then we want to avoid using -* sempahores as they bypass the fence signaling metadata, and we +* semaphores as they bypass the fence signaling metadata, and we * lose the fence->error propagation. */ if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 5819737c21c678d3..5d6b81a6578ef2ba 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -3603,7 +3603,7 @@ void cik_fence_compute_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index dd78fc4994024815..34457e51035278fb 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -2918,7 +2918,7 @@ void r600_fence_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h index 087e3f649c52f02d..217c1cf21c1ab7d5 100644 --- a/include/drm/task_barrier.h +++ b/include/drm/task_barrier.h @@ -25,7 +25,7 @@ /* * Reusable 2 PHASE task barrier (randevouz point) implementation for N tasks. - * Based on the Little book of sempahores - https://greenteapress.com/wp/semaphores/ + * Based on the Little book of semaphores - https://greenteapress.com/wp/semaphores/ */ -- 2.34.1
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
+static enum drm_mode_status
+lsdc_mode_config_mode_valid(struct drm_device *ddev,
+ const struct drm_display_mode *mode)
+{
+ struct lsdc_device *ldev = to_lsdc(ddev);
+ const struct drm_format_info *info =
drm_format_info(DRM_FORMAT_XRGB);
Short-term hard coding a format is fine, but there should be a comment
describing why.
Because our driver only support DRM_FORMAT_XRGB frame buffer currently.
After carry out the IGT test, I found this function may not sufficient
anymore.
+ u64 min_pitch = drm_format_info_min_pitch(info, 0, mode->hdisplay);
+ u64 fb_size = min_pitch * mode->vdisplay;
+
+ if (fb_size * 3 > ldev->vram_size) {
Why are we using 3 here? Please add an inline comment.
Originally lsdc_mode_config_mode_valid() is copy from drm_gem_vram_helper.c
with the observation that there no need for the compute of the number of
pages in
the terms of PAGE_SIZE.
The '3' here is a experience number, it intend to restrict single
allocation overlarge.
In my opinion, it stand for one frame buffer plus another two dumb
buffer allocation
when running the running pageflip test(from the libdrm modetest).
Therefore, the kernel space drm driver should guarantee at least 3 times
frame buffer
allocation to the user-space. Otherwise, the pageflip test can not even
being able to run.
While when testing this driver with IGT, I found the dumb_buffer test
of IGT will try to
create a very large dumb buffer, as large as 256MB in my case.
Currently our driver could not satisfy such a large allocation,
I test it with drm/radeon driver on LoongArch and X86-64, redeon can not
even passing it.
The restriction put in here is not effective anymore, because it is too
late.
I'm think we should put the restriction in the lsdc_dumb_create() function.
We will revise our driver at next version.
Great thanks for your valuable reviews.
Re: [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4
On Mon, Apr 10, 2023 at 07:50:50AM -0700, Rob Clark wrote: > Hi Dave, > > This is the main pull for v6.4, see below for description. A bit big > this time because of (1) generated header updates and (2) dpu hw > catelog rework which split the increasingly unwieldy > big-giant-file-of-tables into per-SoC files. But those are mainly > mechanical churn. > > The following changes since commit e752ab11dcb48353727ea26eefd740155e028865: > > Merge remote-tracking branch 'drm/drm-next' into msm-next > (2023-03-20 10:31:25 -0700) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2023-04-10 > > for you to fetch changes up to ac7e7c9c65ecfb1fcc99de91cfd6b17a8d4cb9c1: > > drm/msm/dpu: drop unused macros from hw catalog (2023-04-07 03:54:50 +0300) Pulled, thanks. Two comments below. > > > main pull request for v6.4 > > Core Display: > > * Bugfixes for error handling during probe > * rework UBWC decoder programming > * prepare_commit cleanup > * bindings for SM8550 (MDSS, DPU), SM8450 (DP) > * timeout calculation fixup > * atomic: use drm_crtc_next_vblank_start() instead of our own > custom thing to calculate the start of next vblank > > DP: > == > * interrupts cleanup > > DPU: > === > * DSPP sub-block flush on sc7280 > * support AR30 in addition to XR30 format > * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes > * Split the HW catalog into individual per-SoC files > > DSI: > === > * rework DSI instance ID detection on obscure platforms > > GPU: > === > * uapi C++ compatibility fix > * a6xx: More robust gdsc reset > * a3xx and a4xx devfreq support > * update generated headers > * various cleanups and fixes > * GPU and GEM updates to avoid allocations which could trigger > reclaim (shrinker) in fence signaling path dim complained about a pile of commits without 2nd eyes, and it was mostly this. I think especially for these tricky locking/reclaim issues having a bus factor > 1 would be really good. I'll try and brush of my anotations, hopefully we can have a bit more cross-driver discussions and reviews going here, iirc when Boris did the timed_out annotations for panfrost he didn't fix all the splats, so that's perfect candidate to help push the remaining work. > * dma-fence deadline hint support and wait-boost > * a640 speedbin support > * a650 speedbin support > > > Abhinav Kumar (3): > MAINTAINERS: Update the URI for MSM DRM bugs > drm/msm/dpu: log the multirect_index in _dpu_crtc_blend_setup_pipe > drm/msm/dpu: remove unused dpu_plane_validate_multirect_v2 function > > Adam Skladowski (1): > drm: msm: adreno: Disable preemption on Adreno 510 > > Akhil P Oommen (3): > drm/msm/a6xx: Vote for cx gdsc from gpu driver > drm/msm/a6xx: Remove cx gdsc polling using 'reset' > drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse > > Arnd Bergmann (1): > drm/msm/a6xx: add CONFIG_PM dependency > > Colin Ian King (2): > drm/msm/mdss: Fix spelling mistake "Unuspported" -> "Unsupported" > drm/msm/dp: Fix spelling mistake "Capabiity" -> "Capability" > > Danylo Piliaiev (1): > drm/msm: Rename drm_msm_gem_submit_reloc::or in C++ code > > Dmitry Baryshkov (67): > drm/msm/adreno: stall translation on fault for all GPU families > drm/msm/adreno: split a6xx fault handler into generic and a6xx parts > drm/msm/a5xx: add devcoredump support to the fault handler > drm/msm/mdss: convert UBWC setup to use match data > drm/msm/mdss: add data for sc8180xp > drm/msm/mdss: add the sdm845 data for completeness > drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg) > drm/msm/dpu: move SSPP allocation to the RM > drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c > drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout > drm/msm/dpu: move pipe_hw to dpu_plane_state > drm/msm/dpu: drop dpu_plane_pipe function > drm/msm/dpu: introduce struct dpu_sw_pipe > drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks > drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() > drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill > drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress > drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg > drm/msm/dpu: rename dpu_hw_sspp_cfg to dpu_sw_pipe_cfg > drm/msm/dpu: drop src_split and multirect check from > dpu_crtc_atomic_check > drm/msm/dpu: don't use unsupported blend stages > drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check() > drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check() > drm/msm/dpu: rewrite plane's QoS-related functions to take >
Re: [PATCH v3 28/65] clk: renesas: r9a06g032: Add a determine_rate hook
CC Gareth, Hervé, Miquel, Ralph
On Tue, Apr 4, 2023 at 2:44 PM Maxime Ripard wrote:
> The Renesas r9a06g032 bitselect clock implements a mux with a set_parent
> hook, but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock. However, the most likely candidate to
> trigger that parent change is a call to clk_set_rate(), with
> determine_rate() figuring out which parent is the best suited for a
> given rate.
>
> The other trigger would be a call to clk_set_parent(), but it's far less
> used, and it doesn't look like there's any obvious user for that clock.
>
> So, the set_parent hook is effectively unused, possibly because of an
> oversight. However, it could also be an explicit decision by the
> original author to avoid any reparenting but through an explicit call to
> clk_set_parent().
>
> The latter case would be equivalent to setting the flag
> CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
> to __clk_mux_determine_rate(). Indeed, if no determine_rate
> implementation is provided, clk_round_rate() (through
> clk_core_round_rate_nolock()) will call itself on the parent if
> CLK_SET_RATE_PARENT is set, and will not change the clock rate
> otherwise. __clk_mux_determine_rate() has the exact same behavior when
> CLK_SET_RATE_NO_REPARENT is set.
>
> And if it was an oversight, then we are at least explicit about our
> behavior now and it can be further refined down the line.
>
> Signed-off-by: Maxime Ripard
LGTM, so
Reviewed-by: Geert Uytterhoeven
But I do not have the hardware.
> --- a/drivers/clk/renesas/r9a06g032-clocks.c
> +++ b/drivers/clk/renesas/r9a06g032-clocks.c
> @@ -1121,6 +1121,7 @@ static int r9a06g032_clk_mux_set_parent(struct clk_hw
> *hw, u8 index)
> }
>
> static const struct clk_ops clk_bitselect_ops = {
> + .determine_rate = __clk_mux_determine_rate,
> .get_parent = r9a06g032_clk_mux_get_parent,
> .set_parent = r9a06g032_clk_mux_set_parent,
> };
> @@ -1145,7 +1146,7 @@ r9a06g032_register_bitsel(struct r9a06g032_priv *clocks,
>
> init.name = desc->name;
> init.ops = &clk_bitselect_ops;
> - init.flags = CLK_SET_RATE_PARENT;
> + init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT;
> init.parent_names = names;
> init.num_parents = 2;
>
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
Re: [PATCH v3 1/2] drm/mediatek: Add mdp_rdma get format function
On Thu, Mar 30, 2023 at 11:26:13AM +0800, Nancy.Lin wrote:
> Add mdp_rdma get_format and get_num_formats function.
>
> Signed-off-by: Nancy.Lin
The mtk get_formats stuff seems like a lot of midlayering for not much
reasons? Is that really needed?
Just a drive-by questions I had while merging the pr.
-Daniel
> ---
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 +++
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 24
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 0d28b2e2069c..17b169530beb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -152,4 +152,7 @@ void mtk_mdp_rdma_start(struct device *dev, struct
> cmdq_pkt *cmdq_pkt);
> void mtk_mdp_rdma_stop(struct device *dev, struct cmdq_pkt *cmdq_pkt);
> void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
>struct cmdq_pkt *cmdq_pkt);
> +const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
> +size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
> +
> #endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index eecfa98ff52e..e06db6e56b5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -62,6 +62,20 @@
> #define RDMA_CSC_FULL709_TO_RGB 5
> #define RDMA_CSC_BT601_TO_RGB6
>
> +static const u32 formats[] = {
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_YUYV,
> +};
> +
> enum rdma_format {
> RDMA_INPUT_FORMAT_RGB565 = 0,
> RDMA_INPUT_FORMAT_RGB888 = 1,
> @@ -219,6 +233,16 @@ void mtk_mdp_rdma_config(struct device *dev, struct
> mtk_mdp_rdma_cfg *cfg,
> MDP_RDMA_MF_CLIP_SIZE, FLD_MF_CLIP_H);
> }
>
> +const u32 *mtk_mdp_rdma_get_formats(struct device *dev)
> +{
> + return formats;
> +}
> +
> +size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
> +{
> + return ARRAY_SIZE(formats);
> +}
> +
> int mtk_mdp_rdma_clk_enable(struct device *dev)
> {
> struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
> --
> 2.18.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [GIT PULL] mediatek drm next for 6.4
On Mon, Apr 10, 2023 at 11:30:05PM +, Chun-Kuang Hu wrote: > Hi, Dave & Daniel: > > This includes: > > 1. Add support for 10-bit overlays > 2. Add MediaTek SoC DRM (vdosys1) support for mt8195 > 3. Change mmsys compatible for mt8195 mediatek-drm > 4. Only trigger DRM HPD events if bridge is attached > 5. Change the aux retries times when receiving AUX_DEFER > > Regards, > Chun-Kuang. > > The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6: > > Linux 6.3-rc1 (2023-03-05 14:52:03 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git > tags/mediatek-drm-next-6.4 > > for you to fetch changes up to 9243d70e05c5989f84f840612965f96b524da925: > > drm/mediatek: dp: Change the aux retries times when receiving AUX_DEFER > (2023-04-03 16:49:49 +) Pulled, thanks > > > Mediatek DRM Next for Linux 6.4 > > 1. Add support for 10-bit overlays > 2. Add MediaTek SoC DRM (vdosys1) support for mt8195 > 3. Change mmsys compatible for mt8195 mediatek-drm > 4. Only trigger DRM HPD events if bridge is attached > 5. Change the aux retries times when receiving AUX_DEFER > > > Alexandre Mergnat (1): > dt-bindings: display: mediatek: clean unnecessary item > > Chen-Yu Tsai (1): > drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached > > Jason-JH.Lin (1): > drm/mediatek: Change mmsys compatible for mt8195 mediatek-drm > > Justin Green (3): > drm/mediatek: Refactor pixel format logic > drm/mediatek: Add support for AR30 and BA30 overlays > drm/mediatek: Enable AR30 and BA30 overlays on MT8195 > > Nancy.Lin (9): > dt-bindings: mediatek: add ethdr definition for mt8195 > drm/mediatek: Add ETHDR support for MT8195 > drm/mediatek: Add ovl_adaptor support for MT8195 > drm/mediatek: Add dma dev get function > drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support > drm/mediatek: Add drm ovl_adaptor sub driver for MT8195 > drm/mediatek: Add mediatek-drm of vdosys1 support for MT8195 > drm/mediatek: Add mdp_rdma get format function > drm/mediatek: Add ovl_adaptor get format function > > Nathan Lu (1): > drm/mediatek: Add mediatek-drm of vdosys0 support for mt8188 > > Xinlei Lee (1): > drm/mediatek: dp: Change the aux retries times when receiving AUX_DEFER > > .../bindings/display/mediatek/mediatek,ccorr.yaml | 5 +- > .../bindings/display/mediatek/mediatek,ethdr.yaml | 182 +++ > drivers/gpu/drm/mediatek/Makefile | 2 + > drivers/gpu/drm/mediatek/mtk_disp_drv.h| 35 ++ > drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 94 > drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c| 547 > + > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 38 ++ > drivers/gpu/drm/mediatek/mtk_dp.c | 15 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 89 +++- > drivers/gpu/drm/mediatek/mtk_drm_crtc.h| 6 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 135 +++-- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 78 ++- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 475 ++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 30 +- > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 24 +- > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 3 +- > drivers/gpu/drm/mediatek/mtk_ethdr.c | 370 ++ > drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 + > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c| 24 + > 19 files changed, 1858 insertions(+), 319 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2] drm/vkms: add module parameter to set background color
On Tue, Apr 11, 2023 at 08:58:16AM +, Simon Ser wrote: > Hi, > > On Monday, April 10th, 2023 at 19:50, Melissa Wen wrote: > > > On 04/10, Simon Ser wrote: > > > > > I think this should be a KMS property instead of a module parameter. > > > Is there a reason why this patch uses a module parameter? It breaks > > > user-space expectations. > > > > a KMS property is what we have on vkms TODO [1] and the module parameter > > was Maíra's first step to open a discussion for this property [2]. > > AFAIK, we would need to create the KMS property first, but it seems > > there isn't an userspace case/need to support this API change. > > Do you know any valid use cases to support a bkg color property? > > There have been previous attempts for msm [1] and i915 [2]. > > From user-space PoV, a KMS property would be useful, for instance to > render single color background images. I can type some user-space code > if that helps. Yeah the hold-up thus far was that no one ever came up with an actually useful use in a compositor for this. Everyone seems happy with black, but maybe with proper color rendering this is changing :-) > If this is a module parameter instead of a KMS property, what purpose > does this achieve? What is the use-case? Just trying to understand the > motivation here. Just a step to get things going, occasionally that's needed ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: linux-next: build failure after merge of the driver-core tree
On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/linux/linkage.h:7,
> > from include/linux/kernel.h:17,
> > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > include/linux/export.h:27:22: error: passing argument 1 of 'class_create'
> > from incompatible pointer type [-Werror=incompatible-pointer-types]
> >27 | #define THIS_MODULE (&__this_module)
> > | ~^~~
> > | |
> > | struct module *
> > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro
> > 'THIS_MODULE'
> > 544 | mqc_dev_class = class_create(THIS_MODULE,
> > MHI_QAIC_CTRL_DRIVER_NAME);
> > | ^~~
> > In file included from include/linux/device.h:31,
> > from include/linux/mhi.h:9,
> > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > include/linux/device/class.h:229:54: note: expected 'const char *' but
> > argument is of type 'struct module *'
> > 229 | struct class * __must_check class_create(const char *name);
> > | ^~~~
> > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to
> > function 'class_create'
> > 544 | mqc_dev_class = class_create(THIS_MODULE,
> > MHI_QAIC_CTRL_DRIVER_NAME);
> > | ^~~~
> > include/linux/device/class.h:229:29: note: declared here
> > 229 | struct class * __must_check class_create(const char *name);
> > | ^~~~
> >
> > Caused by commit
> >
> > 1aaba11da9aa ("driver core: class: remove module * from class_create()")
> >
> > interacting with commit
> >
> > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> >
> > from the drm tree.
> >
> > I have applied the following merge fix patch for today.
> >
> > From: Stephen Rothwell
> > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > Subject: [PATCH] fixup for "driver core: class: remove module * from
> > class_create()"
> >
> > interacting with "accel/qaic: Add mhi_qaic_cntl"
> >
> > Signed-off-by: Stephen Rothwell
>
> Thanks for the fixup. Since Dave is out I've made a note about this in my
> handover mail so it won't get lost in the drm-next merge window pull. I
> don't think we need any other coordination than mention it in each pull to
> Linus, topic tree seems overkill for this. Plus there's no way I can
> untangle the drm tree anyway :-).
Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the merge/build issue go away
for you? That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)
thanks,
greg k-h
Re: [PATCH v2 1/2] drm: Add fdinfo memory stats
On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Add a helper to dump memory stats to fdinfo. For the things the drm
> core isn't aware of, use a callback.
>
> v2: Fix typos, change size units to match docs, use div_u64
>
> Signed-off-by: Rob Clark
> Reviewed-by: Emil Velikov
Uh can't we wire this up by default? Having this as a per-driver opt-in
sounds like we'll get maximally fragmented drm fd_info, and since that's
uapi I don't think that's any good at all.
I think it's time we have
- drm_fd_info
- rolled out to all drivers in their fops
- with feature checks as appropriate
- push the driver-specific things into a drm_driver callback
And I guess start peopling giving a hard time for making things needless
driver-specifict ... there's really no reason at all this is not
consistent across drivers.
-Daniel
> ---
> Documentation/gpu/drm-usage-stats.rst | 21 +++
> drivers/gpu/drm/drm_file.c| 79 +++
> include/drm/drm_file.h| 10
> 3 files changed, 110 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b46327356e80..b5e7802532ed 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -105,6 +105,27 @@ object belong to this client, in the respective memory
> region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-shared-memory: [KiB|MiB]
> +
> +The total size of buffers that are shared with another file (ie. have more
> +than a single handle).
> +
> +- drm-private-memory: [KiB|MiB]
> +
> +The total size of buffers that are not shared with another file.
> +
> +- drm-resident-memory: [KiB|MiB]
> +
> +The total size of buffers that are resident in system memory.
> +
> +- drm-purgeable-memory: [KiB|MiB]
> +
> +The total size of buffers that are purgeable.
> +
> +- drm-active-memory: [KiB|MiB]
> +
> +The total size of buffers that are active on one or more rings.
> +
> - drm-cycles-
>
> Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index a51ff8cee049..085b01842a87 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -868,6 +869,84 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void print_size(struct drm_printer *p, const char *stat, size_t sz)
> +{
> + const char *units[] = {"", " KiB", " MiB"};
> + unsigned u;
> +
> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> + if (sz < SZ_1K)
> + break;
> + sz = div_u64(sz, SZ_1K);
> + }
> +
> + drm_printf(p, "%s:\t%zu%s\n", stat, sz, units[u]);
> +}
> +
> +/**
> + * drm_print_memory_stats - Helper to print standard fdinfo memory stats
> + * @file: the DRM file
> + * @p: the printer to print output to
> + * @status: callback to get driver tracked object status
> + *
> + * Helper to iterate over GEM objects with a handle allocated in the
> specified
> + * file. The optional status callback can return additional object state
> which
> + * determines which stats the object is counted against. The callback is
> called
> + * under table_lock. Racing against object status change is "harmless", and
> the
> + * callback can expect to not race against object destruction.
> + */
> +void drm_print_memory_stats(struct drm_file *file, struct drm_printer *p,
> + enum drm_gem_object_status (*status)(struct
> drm_gem_object *))
> +{
> + struct drm_gem_object *obj;
> + struct {
> + size_t shared;
> + size_t private;
> + size_t resident;
> + size_t purgeable;
> + size_t active;
> + } size = {0};
> + int id;
> +
> + spin_lock(&file->table_lock);
> + idr_for_each_entry (&file->object_idr, obj, id) {
> + enum drm_gem_object_status s = 0;
> +
> + if (status)
> + s = status(obj);
> +
> + if (obj->handle_count > 1) {
> + size.shared += obj->size;
> + } else {
> + size.private += obj->size;
> + }
> +
> + if (s & DRM_GEM_OBJECT_RESIDENT) {
> + size.resident += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
> + }
> +
> + if (s & DRM_GEM_OBJECT_PURGEABLE)
> + size.purgeable += obj->size;
> + }
> +
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
+static const struct dev_pm_ops lsdc_pm_ops = {
+ .suspend = lsdc_pm_suspend,
+ .resume = lsdc_pm_resume,
+ .freeze = lsdc_pm_freeze,
+ .thaw = lsdc_pm_thaw,
+ .poweroff = lsdc_pm_freeze,
+ .restore = lsdc_pm_resume,
+};
+
The above section (and functions) should probably be wrapped in a
CONFIG_PM_SLEEP block.
I agree with you.
I see imx-drm has this guard, but it's for embedded platform.
But I also see drm/ast and drm/radeon also didn't add this.
Maybe S3/S4 support is mandatory for PC platform?
Coding this way to force the kernel to enable PM_SLEEP option, otherwise
there a pile of driver won't get compiled.
At lease drm/ast and drm/radeon is usable on LoongArch/Mips/X86-64 platform.
Re: [PATCH v5 4/4] drm/msm/dpu: use CTL_SC7280_MASK for sm8450's ctl_0
On 11/04/2023 03:57, Abhinav Kumar wrote:
On 4/7/2023 5:27 PM, Dmitry Baryshkov wrote:
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d ("drm/msm/dpu: add support
for SM8450") had all (relevant at that time) bit spelled individually.
Then commit 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog"),
despite being a mismerge, correctly changed all other CTL entries to use
CTL_SC7280_MASK, except CTL_0.
While the current BLOCK_SOC_MASK style is not ideal (and while we are
working on a better scheme), let's follow its usage as a least minimal
surprise. For example, sc8280xp, a close associate of sm8450, also uses
CTL_SC7280_MASK.
Signed-off-by: Dmitry Baryshkov
---
Although I dont totally agree with this, but because sc8280xp also uses
the same, I am fine.
Reviewed-by: Abhinav Kumar
But either we need to work on a better scheme or expand the macros but
not duplicate these for the next chipset which gets added.
Yes. I'm also holding the rest of MASK renaming patches for now.
I'd like to the following major items finalized and merged (probably a
goal for 6.5):
- INTF_TE restructure
- QSEED3/4 refactoring
- Proper support for active CTLs (wip), removing the need for
DPU_CTL_SPLIT_DISPLAY on sm8150+
- Pending platforms (2 from 6.x, one from 5.x, hopefully one from 4.x
too, 3.x if possible). Hopefully this will also include more platforms
from recent DPU generations (8.x, 9.x)
- Ideally: also sort out max SSPP line widths for VIG vs DMA
I think that after this we can return to the question of platform
similarities and differences.
Anyway, with the current msm-next + this patchset we should have a
catalog which one can expand without fearing about conflicts or
incorrect data duplication.
--
With best wishes
Dmitry
[PATCH v2 1/2] drm: Spelling s/sempahore/semaphore/
Fix misspellings of "semaphore". Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/radeon/cik.c| 2 +- drivers/gpu/drm/radeon/r600.c | 2 +- include/drm/task_barrier.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 630a732aaecca8fb..0bb368a5dd0bb107 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1220,7 +1220,7 @@ emit_semaphore_wait(struct i915_request *to, /* * If this or its dependents are waiting on an external fence * that may fail catastrophically, then we want to avoid using -* sempahores as they bypass the fence signaling metadata, and we +* semaphores as they bypass the fence signaling metadata, and we * lose the fence->error propagation. */ if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 5819737c21c678d3..5d6b81a6578ef2ba 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -3603,7 +3603,7 @@ void cik_fence_compute_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index dd78fc4994024815..34457e51035278fb 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -2918,7 +2918,7 @@ void r600_fence_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h index 087e3f649c52f02d..217c1cf21c1ab7d5 100644 --- a/include/drm/task_barrier.h +++ b/include/drm/task_barrier.h @@ -25,7 +25,7 @@ /* * Reusable 2 PHASE task barrier (randevouz point) implementation for N tasks. - * Based on the Little book of sempahores - https://greenteapress.com/wp/semaphores/ + * Based on the Little book of semaphores - https://greenteapress.com/wp/semaphores/ */ -- 2.34.1
[PATCH v2 2/2] drm: Spelling s/randevouz/rendez-vous/
Fix a misspelling of "rendez-vous". Signed-off-by: Geert Uytterhoeven --- v2: - s/vouz/vous/. --- include/drm/task_barrier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h index 217c1cf21c1ab7d5..f6e6ed52968133d2 100644 --- a/include/drm/task_barrier.h +++ b/include/drm/task_barrier.h @@ -24,7 +24,7 @@ #include /* - * Reusable 2 PHASE task barrier (randevouz point) implementation for N tasks. + * Reusable 2 PHASE task barrier (rendez-vous point) implementation for N tasks. * Based on the Little book of semaphores - https://greenteapress.com/wp/semaphores/ */ -- 2.34.1
Re: [PATCH 2/2] drm: Spelling s/randevouz/rendez-vouz/
Hi Marc,
On Tue, Apr 11, 2023 at 12:49 PM Marc Dionne wrote:
> On Tue, Apr 11, 2023 at 7:44 AM Geert Uytterhoeven
> wrote:
> >
> > Fix a misspelling of "rendez-vouz".
> >
> > Signed-off-by: Geert Uytterhoeven
> > --- a/include/drm/task_barrier.h
> > +++ b/include/drm/task_barrier.h
> > @@ -24,7 +24,7 @@
> > #include
> >
> > /*
> > - * Reusable 2 PHASE task barrier (randevouz point) implementation for N
> > tasks.
> > + * Reusable 2 PHASE task barrier (rendez-vouz point) implementation for N
> > tasks.
> > * Based on the Little book of semaphores -
> > https://greenteapress.com/wp/semaphores/
> > */
> >
> > --
> > 2.34.1
>
> Sorry for the drive by comment, but shouldn't this be "rendez-vous"
> (with an 's' rather than a 'z')?
Yes it should. Thanks!
/me hides in a brown paper bag, under a rock...
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
Re: [PATCH v5 3/3] drm/virtio: Support sync objects
Hi Dmitry,
On Sun, 9 Apr 2023 at 13:40, Dmitry Osipenko
wrote:
> +static void virtio_gpu_free_syncobjs(struct drm_syncobj **syncobjs,
> +uint32_t nr_syncobjs)
> +{
> + uint32_t i = nr_syncobjs;
> +
> + while (i--) {
> + if (syncobjs[i])
> + drm_syncobj_put(syncobjs[i]);
> + }
> +
> + kvfree(syncobjs);
> +}
> +
> +static void virtio_gpu_reset_syncobjs(struct drm_syncobj **syncobjs,
> + uint32_t nr_syncobjs)
> +{
> + uint32_t i;
> +
> + for (i = 0; i < nr_syncobjs; i++) {
> + if (syncobjs[i])
> + drm_syncobj_replace_fence(syncobjs[i], NULL);
> + }
> +}
> +
Can I bribe you (with cookies) about dropping the NULL checks above?
They're dead code and rather misleading IMHO.
> +static void
> +virtio_gpu_free_post_deps(struct virtio_gpu_submit_post_dep *post_deps,
> + uint32_t nr_syncobjs)
> +{
> + uint32_t i = nr_syncobjs;
> +
> + while (i--) {
> + kfree(post_deps[i].chain);
> + drm_syncobj_put(post_deps[i].syncobj);
> + }
> +
> + kvfree(post_deps);
> +}
> +
> +static int virtio_gpu_parse_post_deps(struct virtio_gpu_submit *submit)
> +{
> + struct drm_virtgpu_execbuffer *exbuf = submit->exbuf;
> + struct drm_virtgpu_execbuffer_syncobj syncobj_desc;
> + struct virtio_gpu_submit_post_dep *post_deps;
> + u32 num_out_syncobjs = exbuf->num_out_syncobjs;
> + size_t syncobj_stride = exbuf->syncobj_stride;
> + int ret = 0, i;
> +
> + if (!num_out_syncobjs)
> + return 0;
> +
> + post_deps = kvcalloc(num_out_syncobjs, sizeof(*post_deps),
> GFP_KERNEL);
> + if (!post_deps)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_out_syncobjs; i++) {
> + uint64_t address = exbuf->out_syncobjs + i * syncobj_stride;
> +
For my own education: what's the specifics/requirements behind the
stride? is there a use-case for the stride to vary across in/out
syncobj?
Off the top of my head: userspace could have an array of larger
structs, each embedding an syncobj. Thus passing the stride, the
kernel will fetch/update them in-place w/o caring about the other
data.
Or perhaps there is another trick that userspace utilises the stride for?
> + if (copy_from_user(&syncobj_desc,
> + u64_to_user_ptr(address),
> + min(syncobj_stride,
> sizeof(syncobj_desc {
> + ret = -EFAULT;
> + break;
> + }
> +
We seem to be parsing garbage(?) stack data in the syncobj_stride <
sizeof(syncobj_desc) case.
Zeroing/reseting the syncobj_desc on each iteration is one approach -
be that fully or in part. Alternatively we could error out on
syncobj_stride < sizeof(syncobj_desc).
> + post_deps[i].point = syncobj_desc.point;
> +
> + if (syncobj_desc.flags) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (syncobj_desc.point) {
> + post_deps[i].chain = dma_fence_chain_alloc();
> + if (!post_deps[i].chain) {
> + ret = -ENOMEM;
> + break;
> + }
> + }
> +
> + post_deps[i].syncobj = drm_syncobj_find(submit->file,
> + syncobj_desc.handle);
> + if (!post_deps[i].syncobj) {
> + ret = -EINVAL;
I think we want a kfree(chain) here. Otherwise we'll leak it, right?
> + break;
> + }
> + }
> +
> + if (ret) {
> + virtio_gpu_free_post_deps(post_deps, i);
> + return ret;
> + }
> +
> + submit->num_out_syncobjs = num_out_syncobjs;
> + submit->post_deps = post_deps;
> +
> + return 0;
> +}
> +
With the two issues in virtio_gpu_parse_post_deps() addressed, the series is:
Reviewed-by; Emil Velikov
HTH
Emil
[PATCH v7 00/17] Add RCar DU lib support
The DU controller on RZ/G2L LCDC is similar to R-Car as it is
connected to VSPD. RCar DU lib is created for sharing kms, vsp and encoder
driver code between both RCar and RZ/G2L alike SoCs.
Tested this patch series on RZ/{G2M, G2L, G2LC} and RZ/V2L platforms.
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
v5->v6:
* Merged DU lib and RZ/G2L du driver in same patch series
* Rebased to latest drm-misc.
* Merged patch#1 to RZ/G2L Driver patch.
* Updated KConfig dependency from ARCH_RENESAS->ARCH_RZG2L.
* Optimized rzg2l_du_output_name() by removing unsupported outputs.
v4->v5:
* Added Rb tag from Rob for binding patch.
* Started using RCar DU libs(kms, vsp and encoder)
* Started using rcar_du_device, rcar_du_write, rcar_du_crtc,
rcar_du_format_info and rcar_du_encoder.
v3->v4:
* Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
* started using same compatible for RZ/G2{L,LC}
* Removed rzg2l_du_group.h and struct rzg2l_du_group
* Renamed __rzg2l_du_group_start_stop->rzg2l_du_start_stop
* Removed rzg2l_du_group_restart
* Updated rzg2l_du_crtc_set_display_timing
* Removed mode_valid callback.
* Updated rzg2l_du_crtc_create() parameters
* Updated compatible
* Removed RZG2L_DU_MAX_GROUPS
V2->v3:
* Added new bindings for RZ/G2L DU
* Removed indirection and created new DRM driver based on R-Car DU
v1->v2:
* Based on [1], all references to 'rzg2l_lcdc' replaced with 'rzg2l_du'
* Updated commit description for bindings
* Removed LCDC references from bindings
* Changed clock name from du.0->aclk from bindings
* Changed reset name from du.0->du from bindings
* Replaced crtc_helper_funcs->rcar_crtc_helper_funcs
* Updated macro DRM_RZG2L_LCDC->DRM_RZG2L_DU
* Replaced rzg2l-lcdc-drm->rzg2l-du-drm
* Added forward declaration for struct reset_control
[1]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220312084205.31462-2-biju.das...@bp.renesas.com/
RFC->v1:
* Changed minItems->maxItems for renesas,vsps.
* Added RZ/G2L LCDC driver with special handling for CRTC reusing
most of RCar DU code
* Fixed the comments for num_rpf from rpf's->RPFs/ and vsp->VSP.
RFC:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-18-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-12-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-13-biju.das...@bp.renesas.com/
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220112174612.10773-19-biju.das...@bp.renesas.com/
Biju Das (17):
drm: rcar-du: Add encoder lib support
drm: rcar-du: Add kms lib support
drm: rcar-du: Add vsp lib support
drm: rcar-du: Move rcar_du_vsp_atomic_begin()
drm: rcar-du: Move rcar_du_vsp_atomic_flush()
drm: rcar-du: Move rcar_du_vsp_{map,unmap}_fb()
drm: rcar-du: Move rcar_du_dumb_create()
drm: rcar-du: Move rcar_du_gem_prime_import_sg_table()
drm: rcar-du: Add rcar_du_lib_vsp_init()
drm: rcar-du: Move rcar_du_vsp_plane_prepare_fb()
drm: rcar-du: Move rcar_du_vsp_plane_cleanup_fb()
drm: rcar-du: Move rcar_du_vsp_plane_atomic_update()
drm: rcar-du: Add rcar_du_lib_fb_create()
drm: rcar-du: Add rcar_du_lib_mode_cfg_helper_get()
drm: rcar-du: Move rcar_du_encoders_init()
drm: rcar-du: Move rcar_du_properties_init()
drm: rcar-du: Add rcar_du_lib_vsps_init()
drivers/gpu/drm/rcar-du/Kconfig | 10 +
drivers/gpu/drm/rcar-du/Makefile | 4 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 117 +--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 14 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c | 138
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h | 30 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 694 +---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 29 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 744 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 61 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 407 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 26 +-
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 436 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 76 ++
14 files changed, 1515 insertions(+), 1271 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
--
2.25.1
[PATCH v7 01/17] drm: rcar-du: Add encoder lib support
Add RCar DU encoder lib support by moving rcar_du_encoder_count_ports()
and rcar_du_encoder_funcs to the lib file and added rcar_du_lib_encoder_init()
to share the common code between RCar and RZ/G2L DU encoder drivers.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v5->v6:
* Updated rcar_du_encoder_init() to take care of DSI outputs.
v2->v5:
* No change
v1->v2:
* Rebased on drm-misc-next and DU-next.
* Fixed the warning reported by bot.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/Kconfig | 5 +
drivers/gpu/drm/rcar-du/Makefile | 2 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 117 +--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 14 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c | 138 ++
drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h | 30
6 files changed, 180 insertions(+), 126 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 53c356aed5d5..07a922cc3504 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -80,3 +80,8 @@ config DRM_RCAR_WRITEBACK
bool
default y if ARM64
depends on DRM_RCAR_DU
+
+config DRM_RCAR_LIB
+ bool
+ default y
+ depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index b8f2c82651d9..479c8eebba5a 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -6,6 +6,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_kms.o \
rcar_du_plane.o \
+rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o
+
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 7ecec7b04a8d..b9b5a31c3cb5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -2,7 +2,7 @@
/*
* R-Car Display Unit Encoder
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2023 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
@@ -10,128 +10,17 @@
#include
#include
-#include
-#include
-#include
-
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
-#include "rcar_lvds.h"
/*
-
* Encoder
*/
-static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
-{
- struct device_node *ports;
- struct device_node *port;
- unsigned int num_ports = 0;
-
- ports = of_get_child_by_name(node, "ports");
- if (!ports)
- ports = of_node_get(node);
-
- for_each_child_of_node(ports, port) {
- if (of_node_name_eq(port, "port"))
- num_ports++;
- }
-
- of_node_put(ports);
-
- return num_ports;
-}
-
-static const struct drm_encoder_funcs rcar_du_encoder_funcs = {
-};
-
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_output output,
struct device_node *enc_node)
{
- struct rcar_du_encoder *renc;
- struct drm_connector *connector;
- struct drm_bridge *bridge;
- int ret;
-
- /*
-* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
-* DT node has a single port, assume that it describes a panel and
-* create a panel bridge.
-*/
- if ((output == RCAR_DU_OUTPUT_DPAD0 ||
-output == RCAR_DU_OUTPUT_DPAD1) &&
- rcar_du_encoder_count_ports(enc_node) == 1) {
- struct drm_panel *panel = of_drm_find_panel(enc_node);
-
- if (IS_ERR(panel))
- return PTR_ERR(panel);
-
- bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
-
DRM_MODE_CONNECTOR_DPI);
- if (IS_ERR(bridge))
- return PTR_ERR(bridge);
- } else {
- bridge = of_drm_find_bridge(enc_node);
- if (!bridge)
- return -EPROBE_DEFER;
-
- if (output == RCAR_DU_OUTPUT_LVDS0 ||
- output == RCAR_DU_OUTPUT_LVDS1)
- rcdu->lvds[output - RCAR_DU_OUTPUT_LVDS0] = bridge;
-
- if (output == RCAR_DU_OUTPUT_DSI0 ||
- output == RCAR_DU_OUTPUT_DSI1)
- rcdu->dsi[output - RCAR_DU_OUTPUT_DSI0] = bridge;
- }
-
[PATCH v7 02/17] drm: rcar-du: Add kms lib support
Add RCar DU kms lib support for sharing the common code between
RCar and RZ/G2L DU KMS drivers by moving rcar_du_format_infos
table and rcar_du_format_infos() to the lib file.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/Makefile | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 320 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 16 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 335 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 27 ++
5 files changed, 366 insertions(+), 335 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 479c8eebba5a..3ce410300334 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -6,7 +6,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_kms.o \
rcar_du_plane.o \
-rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o \
+ rcar_du_kms_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index adfb36b0e815..3141d447e979 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -32,326 +32,6 @@
#include "rcar_du_vsp.h"
#include "rcar_du_writeback.h"
-/*
-
- * Format helpers
- */
-
-static const struct rcar_du_format_info rcar_du_format_infos[] = {
- {
- .fourcc = DRM_FORMAT_RGB565,
- .v4l2 = V4L2_PIX_FMT_RGB565,
- .bpp = 16,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_ARGB1555,
- .v4l2 = V4L2_PIX_FMT_ARGB555,
- .bpp = 16,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_XRGB1555,
- .v4l2 = V4L2_PIX_FMT_XRGB555,
- .bpp = 16,
- .planes = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_XRGB,
- .v4l2 = V4L2_PIX_FMT_XBGR32,
- .bpp = 32,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_RGB888,
- }, {
- .fourcc = DRM_FORMAT_ARGB,
- .v4l2 = V4L2_PIX_FMT_ABGR32,
- .bpp = 32,
- .planes = 1,
- .hsub = 1,
- .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
- .edf = PnDDCR4_EDF_ARGB,
- }, {
- .fourcc = DRM_FORMAT_UYVY,
- .v4l2 = V4L2_PIX_FMT_UYVY,
- .bpp = 16,
- .planes = 1,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_YUYV,
- .v4l2 = V4L2_PIX_FMT_YUYV,
- .bpp = 16,
- .planes = 1,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV12,
- .v4l2 = V4L2_PIX_FMT_NV12M,
- .bpp = 12,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV21,
- .v4l2 = V4L2_PIX_FMT_NV21M,
- .bpp = 12,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- }, {
- .fourcc = DRM_FORMAT_NV16,
- .v4l2 = V4L2_PIX_FMT_NV16M,
- .bpp = 16,
- .planes = 2,
- .hsub = 2,
- .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
- .edf = PnDDCR4_EDF_NONE,
- },
- /*
-* The following formats are not supported on Gen2 and thus have no
-* associated .pnmr or .edf settings.
-*/
-
[PATCH v7 03/17] drm: rcar-du: Add vsp lib support
Add RCar DU vsp lib support by moving rcar_du_vsp_disable()
to the lib file so that same function can be used by both
RCar and RZ/G2L DU VSP drivers.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/Kconfig | 5 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 4 ++--
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 17 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 19 +++
6 files changed, 44 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 07a922cc3504..373568a23655 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -85,3 +85,8 @@ config DRM_RCAR_LIB
bool
default y
depends on DRM_RCAR_DU
+
+config DRM_RCAR_VSP_LIB
+ bool
+ default y
+ depends on DRM_RCAR_VSP
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 3ce410300334..8fc924cf37a7 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -10,6 +10,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o \
rcar_du_kms_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_VSP_LIB) += rcar_du_vsp_lib.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 45c05d0ffc70..3dab5fc822cf 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,11 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
}
-void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
-{
- vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
-}
-
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
{
vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 67630f0b6599..8fbfa86c93e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -12,6 +12,8 @@
#include
+#include "rcar_du_vsp_lib.h"
+
struct drm_framebuffer;
struct rcar_du_format_info;
struct rcar_du_vsp;
@@ -59,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
@@ -74,7 +75,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
new file mode 100644
index ..374707b9cc12
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * R-Car Display Unit VSP-Based Compositor Lib
+ *
+ * Copyright (C) 2015-2023 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ */
+
+#include
+
+#include "rcar_du_drv.h"
+
+void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
+{
+ vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
new file mode 100644
index ..55b026f20c46
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * R-Car Display Unit VSP-Based Compositor Lib
+ *
+ * Copyright (C) 2015-2023 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ */
+
+#ifndef __RCAR_DU_VSP_LIB_H__
+#define __RCAR_DU_VSP_LIB_H__
+
+#ifdef
[PATCH v7 04/17] drm: rcar-du: Move rcar_du_vsp_atomic_begin()
Move rcar_du_vsp_atomic_begin() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 2 ++
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 3dab5fc822cf..66ada10fccd4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,11 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
}
-void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
-{
- vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
-}
-
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
{
struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 8fbfa86c93e0..83a2f3e85860 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -61,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
struct sg_table sg_tables[3]);
@@ -75,7 +74,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index 374707b9cc12..a69e0842c98c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -15,3 +15,8 @@ void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
}
+
+void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
+{
+ vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index 55b026f20c46..e0077e832d01 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -12,8 +12,10 @@
#ifdef CONFIG_DRM_RCAR_VSP
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
+void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
+static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v7 05/17] drm: rcar-du: Move rcar_du_vsp_atomic_flush()
Move rcar_du_vsp_atomic_flush() to RCar DU vsp lib.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 13 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 14 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 2 ++
4 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 66ada10fccd4..7d9a3bc8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -88,19 +88,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
}
-void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
-{
- struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
- struct rcar_du_crtc_state *state;
-
- state = to_rcar_crtc_state(crtc->crtc.state);
- cfg.crc = state->crc;
-
- rcar_du_writeback_setup(crtc, &cfg.writeback);
-
- vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
-}
-
static const u32 rcar_du_vsp_formats[] = {
DRM_FORMAT_RGB332,
DRM_FORMAT_ARGB,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 83a2f3e85860..b610e6b40304 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -61,7 +61,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
struct sg_table sg_tables[3]);
void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
@@ -74,7 +73,6 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
return -ENXIO;
}
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
-static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
static inline int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp,
struct drm_framebuffer *fb,
struct sg_table sg_tables[3])
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index a69e0842c98c..ecf0801202b7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -10,6 +10,7 @@
#include
#include "rcar_du_drv.h"
+#include "rcar_du_writeback.h"
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
@@ -20,3 +21,16 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
{
vsp1_du_atomic_begin(crtc->vsp->vsp, crtc->vsp_pipe);
}
+
+void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
+{
+ struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
+ struct rcar_du_crtc_state *state;
+
+ state = to_rcar_crtc_state(crtc->crtc.state);
+ cfg.crc = state->crc;
+
+ rcar_du_writeback_setup(crtc, &cfg.writeback);
+
+ vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index e0077e832d01..1506e739f714 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -13,9 +13,11 @@
#ifdef CONFIG_DRM_RCAR_VSP
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
+void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
+static inline void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc) { };
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v7 06/17] drm: rcar-du: Move rcar_du_vsp_{map,unmap}_fb()
Move rcar_du_vsp_{map,unmap}_fb() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 78 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 18 -
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 84 +++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 20 ++
4 files changed, 104 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 7d9a3bc8..d461043c7828 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -11,11 +11,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include
#include
@@ -208,68 +205,6 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, &cfg);
}
-int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3])
-{
- struct rcar_du_device *rcdu = vsp->dev;
- unsigned int i, j;
- int ret;
-
- for (i = 0; i < fb->format->num_planes; ++i) {
- struct drm_gem_dma_object *gem = drm_fb_dma_get_gem_obj(fb, i);
- struct sg_table *sgt = &sg_tables[i];
-
- if (gem->sgt) {
- struct scatterlist *src;
- struct scatterlist *dst;
-
- /*
-* If the GEM buffer has a scatter gather table, it has
-* been imported from a dma-buf and has no physical
-* address as it might not be physically contiguous.
-* Copy the original scatter gather table to map it to
-* the VSP.
-*/
- ret = sg_alloc_table(sgt, gem->sgt->orig_nents,
-GFP_KERNEL);
- if (ret)
- goto fail;
-
- src = gem->sgt->sgl;
- dst = sgt->sgl;
- for (j = 0; j < gem->sgt->orig_nents; ++j) {
- sg_set_page(dst, sg_page(src), src->length,
- src->offset);
- src = sg_next(src);
- dst = sg_next(dst);
- }
- } else {
- ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr,
- gem->dma_addr, gem->base.size);
- if (ret)
- goto fail;
- }
-
- ret = vsp1_du_map_sg(vsp->vsp, sgt);
- if (ret) {
- sg_free_table(sgt);
- goto fail;
- }
- }
-
- return 0;
-
-fail:
- while (i--) {
- struct sg_table *sgt = &sg_tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
-
- return ret;
-}
-
static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -291,19 +226,6 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
return drm_gem_plane_helper_prepare_fb(plane, state);
}
-void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table sg_tables[3])
-{
- unsigned int i;
-
- for (i = 0; i < fb->format->num_planes; ++i) {
- struct sg_table *sgt = &sg_tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
-}
-
static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index b610e6b40304..4022ed014353 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -14,10 +14,7 @@
#include "rcar_du_vsp_lib.h"
-struct drm_framebuffer;
struct rcar_du_format_info;
-struct rcar_du_vsp;
-struct sg_table;
struct rcar_du_vsp_plane {
struct drm_plane plane;
@@ -61,10 +58,6 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
-int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
- struct sg_table
[PATCH v7 07/17] drm: rcar-du: Move rcar_du_dumb_create()
Move rcar_du_dumb_create() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 5
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 28 +++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 7 ++
4 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3141d447e979..4b5511a20313 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -81,27 +81,6 @@ struct drm_gem_object
*rcar_du_gem_prime_import_sg_table(struct drm_device *dev,
return gem_obj;
}
-int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args)
-{
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- unsigned int align;
-
- /*
-* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
-* but the R8A7790 DU seems to require a 128 bytes pitch alignment.
-*/
- if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
- align = 128;
- else
- align = 16 * args->bpp / 8;
-
- args->pitch = roundup(min_pitch, align);
-
- return drm_gem_dma_dumb_create_internal(file, dev, args);
-}
-
static struct drm_framebuffer *
rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index d2d4f34fe557..5490c99947fd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -13,18 +13,13 @@
#include "rcar_du_kms_lib.h"
struct dma_buf_attachment;
-struct drm_file;
struct drm_device;
struct drm_gem_object;
-struct drm_mode_create_dumb;
struct rcar_du_device;
struct sg_table;
int rcar_du_modeset_init(struct rcar_du_device *rcdu);
-int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
-
struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 5921040586fc..e88f753704cd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -7,10 +7,13 @@
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
+#include
#include
+#include
#include
+#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
#include "rcar_du_regs.h"
@@ -333,3 +336,28 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
fourcc)
return NULL;
}
+
+/*
-
+ * Frame buffer
+ */
+
+int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ unsigned int align;
+
+ /*
+* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
+* but the R8A7790 DU seems to require a 128 bytes pitch alignment.
+*/
+ if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
+ align = 128;
+ else
+ align = 16 * args->bpp / 8;
+
+ args->pitch = roundup(min_pitch, align);
+
+ return drm_gem_dma_dumb_create_internal(file, dev, args);
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
index d72069436cac..6e4cfe2ef867 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
@@ -12,6 +12,10 @@
#include
+struct drm_device;
+struct drm_file;
+struct drm_mode_create_dumb;
+
struct rcar_du_format_info {
u32 fourcc;
u32 v4l2;
@@ -24,4 +28,7 @@ struct rcar_du_format_info {
const struct rcar_du_format_info *rcar_du_format_info(u32 fourcc);
+int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args);
+
#endif /* __RCAR_DU_KMS_LIB_H__ */
--
2.25.1
[PATCH v7 08/17] drm: rcar-du: Move rcar_du_gem_prime_import_sg_table()
Move rcar_du_gem_prime_import_sg_table() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 47 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 8
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 46 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 7
4 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4b5511a20313..ae969f640bb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -11,8 +11,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -36,51 +34,6 @@
* Frame buffer
*/
-static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
- .free = drm_gem_dma_object_free,
- .print_info = drm_gem_dma_object_print_info,
- .get_sg_table = drm_gem_dma_object_get_sg_table,
- .vmap = drm_gem_dma_object_vmap,
- .mmap = drm_gem_dma_object_mmap,
- .vm_ops = &drm_gem_dma_vm_ops,
-};
-
-struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt)
-{
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- struct drm_gem_dma_object *dma_obj;
- struct drm_gem_object *gem_obj;
- int ret;
-
- if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
- return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
-
- /* Create a DMA GEM buffer. */
- dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
- if (!dma_obj)
- return ERR_PTR(-ENOMEM);
-
- gem_obj = &dma_obj->base;
- gem_obj->funcs = &rcar_du_gem_funcs;
-
- drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
- dma_obj->map_noncoherent = false;
-
- ret = drm_gem_create_mmap_offset(gem_obj);
- if (ret) {
- drm_gem_object_release(gem_obj);
- kfree(dma_obj);
- return ERR_PTR(ret);
- }
-
- dma_obj->dma_addr = 0;
- dma_obj->sgt = sgt;
-
- return gem_obj;
-}
-
static struct drm_framebuffer *
rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
index 5490c99947fd..02ba7c1c7a70 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h
@@ -12,16 +12,8 @@
#include "rcar_du_kms_lib.h"
-struct dma_buf_attachment;
-struct drm_device;
-struct drm_gem_object;
struct rcar_du_device;
-struct sg_table;
int rcar_du_modeset_init(struct rcar_du_device *rcdu);
-struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
- struct dma_buf_attachment *attach,
- struct sg_table *sgt);
-
#endif /* __RCAR_DU_KMS_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index e88f753704cd..37809d06df89 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
@@ -341,6 +342,51 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
fourcc)
* Frame buffer
*/
+static const struct drm_gem_object_funcs rcar_du_gem_funcs = {
+ .free = drm_gem_dma_object_free,
+ .print_info = drm_gem_dma_object_print_info,
+ .get_sg_table = drm_gem_dma_object_get_sg_table,
+ .vmap = drm_gem_dma_object_vmap,
+ .mmap = drm_gem_dma_object_mmap,
+ .vm_ops = &drm_gem_dma_vm_ops,
+};
+
+struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device
*dev,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sgt)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ struct drm_gem_dma_object *dma_obj;
+ struct drm_gem_object *gem_obj;
+ int ret;
+
+ if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
+ return drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
+
+ /* Create a DMA GEM buffer. */
+ dma_obj = kzalloc(sizeof(*dma_obj), GFP_KERNEL);
+ if (!dma_obj)
+ return ERR_PTR(-ENOMEM);
+
+ gem_obj = &dma_obj->base;
+ gem_obj->funcs = &rcar_du_gem_funcs;
+
+ drm_gem_private_object_init(dev, gem_obj, attach->dmabuf->size);
+ dma_obj->map_noncoherent = false;
+
+
[PATCH v7 09/17] drm: rcar-du: Add rcar_du_lib_vsp_init()
RZ/G2L does not have plane registers as well as it uses different
CRTC. The below functions are SoC specific
* rcar_du_crtc_finish_page_flip()
* __rcar_du_plane_setup
* __rcar_du_plane_atomic_check
All other function can be handled in common code. This patch introduces
rcar_du_lib_vsp_init() to share common_init, vsp_formats and vsp_plane_funcs().
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 203 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 212 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 11 ++
3 files changed, 225 insertions(+), 201 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index d461043c7828..e54a605a1bdf 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
@@ -85,71 +84,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
}
-static const u32 rcar_du_vsp_formats[] = {
- DRM_FORMAT_RGB332,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB1555,
- DRM_FORMAT_XRGB1555,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_BGR888,
- DRM_FORMAT_RGB888,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_UYVY,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_YVYU,
- DRM_FORMAT_NV12,
- DRM_FORMAT_NV21,
- DRM_FORMAT_NV16,
- DRM_FORMAT_NV61,
- DRM_FORMAT_YUV420,
- DRM_FORMAT_YVU420,
- DRM_FORMAT_YUV422,
- DRM_FORMAT_YVU422,
- DRM_FORMAT_YUV444,
- DRM_FORMAT_YVU444,
-};
-
-/*
- * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
- * formats and Y210 & Y212 formats.
- */
-static const u32 rcar_du_vsp_formats_gen4[] = {
- DRM_FORMAT_RGB332,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB1555,
- DRM_FORMAT_XRGB1555,
- DRM_FORMAT_RGB565,
- DRM_FORMAT_BGR888,
- DRM_FORMAT_RGB888,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_RGBX1010102,
- DRM_FORMAT_RGBA1010102,
- DRM_FORMAT_ARGB2101010,
- DRM_FORMAT_UYVY,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_YVYU,
- DRM_FORMAT_NV12,
- DRM_FORMAT_NV21,
- DRM_FORMAT_NV16,
- DRM_FORMAT_NV61,
- DRM_FORMAT_YUV420,
- DRM_FORMAT_YVU420,
- DRM_FORMAT_YUV422,
- DRM_FORMAT_YVU422,
- DRM_FORMAT_YUV444,
- DRM_FORMAT_YVU444,
- DRM_FORMAT_Y210,
- DRM_FORMAT_Y212,
-};
-
static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
{
struct rcar_du_vsp_plane_state *state =
@@ -271,142 +205,9 @@ static const struct drm_plane_helper_funcs
rcar_du_vsp_plane_helper_funcs = {
.atomic_update = rcar_du_vsp_plane_atomic_update,
};
-static struct drm_plane_state *
-rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane *plane)
-{
- struct rcar_du_vsp_plane_state *copy;
-
- if (WARN_ON(!plane->state))
- return NULL;
-
- copy = kzalloc(sizeof(*copy), GFP_KERNEL);
- if (copy == NULL)
- return NULL;
-
- __drm_atomic_helper_plane_duplicate_state(plane, ©->state);
-
- return ©->state;
-}
-
-static void rcar_du_vsp_plane_atomic_destroy_state(struct drm_plane *plane,
- struct drm_plane_state
*state)
-{
- __drm_atomic_helper_plane_destroy_state(state);
- kfree(to_rcar_vsp_plane_state(state));
-}
-
-static void rcar_du_vsp_plane_reset(struct drm_plane *plane)
-{
- struct rcar_du_vsp_plane_state *state;
-
- if (plane->state) {
- rcar_du_vsp_plane_atomic_destroy_state(plane, plane->state);
- plane->state = NULL;
- }
-
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (state == NULL)
- return;
-
- __drm_atomic_helper_plane_reset(plane, &state->state);
-}
-
-static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .reset = rcar_du_vsp_plane_reset,
- .destroy = drm_plane_cleanup,
- .atomic_duplicate_state = rcar_du_vsp_plane_atomic_duplicate_state,
- .atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
-};
-
-static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
-{
- struct rcar_du_vsp *vsp = r
[PATCH v7 10/17] drm: rcar-du: Move rcar_du_vsp_plane_prepare_fb()
Move rcar_du_vsp_plane_prepare_fb() to RCar DU vsp lib so that
both RCar and RZ/G2L DU vsp drivers can share this function.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 21 -
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 21 +
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 8
3 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e54a605a1bdf..3abc5031112e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -139,27 +139,6 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, &cfg);
}
-static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *state)
-{
- struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
- struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
- int ret;
-
- /*
-* There's no need to prepare (and unprepare) the framebuffer when the
-* plane is not visible, as it will not be displayed.
-*/
- if (!state->visible)
- return 0;
-
- ret = rcar_du_vsp_map_fb(vsp, state->fb, rstate->sg_tables);
- if (ret < 0)
- return ret;
-
- return drm_gem_plane_helper_prepare_fb(plane, state);
-}
-
static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index f2d55695f6c1..91259d44efe9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -177,6 +177,27 @@ int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct
drm_framebuffer *fb,
return ret;
}
+int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ int ret;
+
+ /*
+* There's no need to prepare (and unprepare) the framebuffer when the
+* plane is not visible, as it will not be displayed.
+*/
+ if (!state->visible)
+ return 0;
+
+ ret = rcar_du_vsp_map_fb(vsp, state->fb, rstate->sg_tables);
+ if (ret < 0)
+ return ret;
+
+ return drm_gem_plane_helper_prepare_fb(plane, state);
+}
+
void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
struct sg_table sg_tables[3])
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index 2ced23132db2..3d3a7735facd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -25,6 +25,8 @@ void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct
drm_framebuffer *fb,
int rcar_du_lib_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs,
const struct drm_plane_helper_funcs
*rcar_du_vsp_plane_helper_funcs);
+int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+struct drm_plane_state *state);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
@@ -49,6 +51,12 @@ rcar_du_lib_vsp_init(struct rcar_du_vsp *vsp, struct
device_node *np,
{
return -ENXIO;
}
+
+static inline int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return -ENXIO;
+}
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v7 11/17] drm: rcar-du: Move rcar_du_vsp_plane_cleanup_fb()
Move rcar_du_vsp_plane_cleanup_fb() to RCar DU vsp lib so that
it can be shared by both RCar and RZ/G2L DU vsp drivers.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 12
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 7 +++
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 3abc5031112e..d785654e4aa3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -139,18 +139,6 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, &cfg);
}
-static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
-struct drm_plane_state *state)
-{
- struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
- struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
-
- if (!state->visible)
- return;
-
- rcar_du_vsp_unmap_fb(vsp, state->fb, rstate->sg_tables);
-}
-
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index 91259d44efe9..9240c56ec40f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -211,6 +211,18 @@ void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct
drm_framebuffer *fb,
}
}
+void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+
+ if (!state->visible)
+ return;
+
+ rcar_du_vsp_unmap_fb(vsp, state->fb, rstate->sg_tables);
+}
+
static struct drm_plane_state *
rcar_du_vsp_plane_atomic_duplicate_state(struct drm_plane *plane)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
index 3d3a7735facd..efd2bb36c88b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h
@@ -27,6 +27,8 @@ int rcar_du_lib_vsp_init(struct rcar_du_vsp *vsp, struct
device_node *np,
const struct drm_plane_helper_funcs
*rcar_du_vsp_plane_helper_funcs);
int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state);
+void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *state);
#else
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
@@ -57,6 +59,11 @@ static inline int rcar_du_vsp_plane_prepare_fb(struct
drm_plane *plane,
{
return -ENXIO;
}
+
+static inline void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+}
#endif
#endif /* __RCAR_DU_VSP_LIB_H__ */
--
2.25.1
[PATCH v7 12/17] drm: rcar-du: Move rcar_du_vsp_plane_atomic_update()
Move rcar_du_vsp_plane_atomic_update() to RCar DU vsp lib so that
both RCar and RZ/G2L DU vsp drivers can share this function.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 70 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 71 +++
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.h | 7 +++
3 files changed, 78 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index d785654e4aa3..4d14de408de1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -84,61 +84,6 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
}
-static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
-{
- struct rcar_du_vsp_plane_state *state =
- to_rcar_vsp_plane_state(plane->plane.state);
- struct rcar_du_crtc *crtc = to_rcar_crtc(state->state.crtc);
- struct drm_framebuffer *fb = plane->plane.state->fb;
- const struct rcar_du_format_info *format;
- struct vsp1_du_atomic_config cfg = {
- .pixelformat = 0,
- .pitch = fb->pitches[0],
- .alpha = state->state.alpha >> 8,
- .zpos = state->state.zpos,
- };
- u32 fourcc = state->format->fourcc;
- unsigned int i;
-
- cfg.src.left = state->state.src.x1 >> 16;
- cfg.src.top = state->state.src.y1 >> 16;
- cfg.src.width = drm_rect_width(&state->state.src) >> 16;
- cfg.src.height = drm_rect_height(&state->state.src) >> 16;
-
- cfg.dst.left = state->state.dst.x1;
- cfg.dst.top = state->state.dst.y1;
- cfg.dst.width = drm_rect_width(&state->state.dst);
- cfg.dst.height = drm_rect_height(&state->state.dst);
-
- for (i = 0; i < state->format->planes; ++i)
- cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
- + fb->offsets[i];
-
- if (state->state.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE) {
- switch (fourcc) {
- case DRM_FORMAT_ARGB1555:
- fourcc = DRM_FORMAT_XRGB1555;
- break;
-
- case DRM_FORMAT_ARGB:
- fourcc = DRM_FORMAT_XRGB;
- break;
-
- case DRM_FORMAT_ARGB:
- fourcc = DRM_FORMAT_XRGB;
- break;
- }
- }
-
- format = rcar_du_format_info(fourcc);
- cfg.pixelformat = format->v4l2;
-
- cfg.premult = state->state.pixel_blend_mode == DRM_MODE_BLEND_PREMULTI;
-
- vsp1_du_atomic_update(plane->vsp->vsp, crtc->vsp_pipe,
- plane->index, &cfg);
-}
-
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -150,21 +95,6 @@ static int rcar_du_vsp_plane_atomic_check(struct drm_plane
*plane,
&rstate->format);
}
-static void rcar_du_vsp_plane_atomic_update(struct drm_plane *plane,
- struct drm_atomic_state *state)
-{
- struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state, plane);
- struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state, plane);
- struct rcar_du_vsp_plane *rplane = to_rcar_vsp_plane(plane);
- struct rcar_du_crtc *crtc = to_rcar_crtc(old_state->crtc);
-
- if (new_state->visible)
- rcar_du_vsp_plane_setup(rplane);
- else if (old_state->crtc)
- vsp1_du_atomic_update(rplane->vsp->vsp, crtc->vsp_pipe,
- rplane->index, NULL);
-}
-
static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
.prepare_fb = rcar_du_vsp_plane_prepare_fb,
.cleanup_fb = rcar_du_vsp_plane_cleanup_fb,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
index 9240c56ec40f..a8ddf06686cd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c
@@ -25,6 +25,7 @@
#include
#include "rcar_du_drv.h"
+#include "rcar_du_kms.h"
#include "rcar_du_writeback.h"
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
@@ -115,6 +116,61 @@ static const u32 rcar_du_vsp_formats_gen4[] = {
DRM_FORMAT_Y212,
};
+static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
+{
+ struct rcar_du_vsp_plane_state *state =
+ to_rcar_vsp_plane_state(plane->plane.state);
+ struct rcar_
[PATCH v7 13/17] drm: rcar-du: Add rcar_du_lib_fb_create()
Move the common code from rcar_du_fb_create->rcar_du_lib_fb_create,
so that rzg2l_du_fb_create() can reuse the common code.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 64 +
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 69 +++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 4 ++
3 files changed, 74 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ae969f640bb6..74845d8bad9d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -38,69 +38,7 @@ static struct drm_framebuffer *
rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- const struct rcar_du_format_info *format;
- unsigned int chroma_pitch;
- unsigned int max_pitch;
- unsigned int align;
- unsigned int i;
-
- format = rcar_du_format_info(mode_cmd->pixel_format);
- if (format == NULL) {
- dev_dbg(dev->dev, "unsupported pixel format %p4cc\n",
- &mode_cmd->pixel_format);
- return ERR_PTR(-EINVAL);
- }
-
- if (rcdu->info->gen < 3) {
- /*
-* On Gen2 the DU limits the pitch to 4095 pixels and requires
-* buffers to be aligned to a 16 pixels boundary (or 128 bytes
-* on some platforms).
-*/
- unsigned int bpp = format->planes == 1 ? format->bpp / 8 : 1;
-
- max_pitch = 4095 * bpp;
-
- if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
- align = 128;
- else
- align = 16 * bpp;
- } else {
- /*
-* On Gen3 the memory interface is handled by the VSP that
-* limits the pitch to 65535 bytes and has no alignment
-* constraint.
-*/
- max_pitch = 65535;
- align = 1;
- }
-
- if (mode_cmd->pitches[0] & (align - 1) ||
- mode_cmd->pitches[0] > max_pitch) {
- dev_dbg(dev->dev, "invalid pitch value %u\n",
- mode_cmd->pitches[0]);
- return ERR_PTR(-EINVAL);
- }
-
- /*
-* Calculate the chroma plane(s) pitch using the horizontal subsampling
-* factor. For semi-planar formats, the U and V planes are combined, the
-* pitch must thus be doubled.
-*/
- chroma_pitch = mode_cmd->pitches[0] / format->hsub;
- if (format->planes == 2)
- chroma_pitch *= 2;
-
- for (i = 1; i < format->planes; ++i) {
- if (mode_cmd->pitches[i] != chroma_pitch) {
- dev_dbg(dev->dev,
- "luma and chroma pitches are not compatible\n");
- return ERR_PTR(-EINVAL);
- }
- }
-
- return drm_gem_fb_create(dev, file_priv, mode_cmd);
+ return rcar_du_lib_fb_create(dev, file_priv, mode_cmd);
}
/*
-
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 37809d06df89..f092d8e4aa16 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -407,3 +407,72 @@ int rcar_du_dumb_create(struct drm_file *file, struct
drm_device *dev,
return drm_gem_dma_dumb_create_internal(file, dev, args);
}
+
+struct drm_framebuffer *
+rcar_du_lib_fb_create(struct drm_device *dev, struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ const struct rcar_du_format_info *format;
+ unsigned int chroma_pitch;
+ unsigned int max_pitch;
+ unsigned int align;
+ unsigned int i;
+
+ format = rcar_du_format_info(mode_cmd->pixel_format);
+ if (format == NULL) {
+ dev_dbg(dev->dev, "unsupported pixel format %p4cc\n",
+ &mode_cmd->pixel_format);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (rcdu->info->gen < 3) {
+ /*
+* On Gen2 the DU limits the pitch to 4095 pixels and requires
+* buffers to be aligned to a 16 pixels boundary (or 128 bytes
+* on some platforms).
+*/
+ unsigned int bpp = format->planes == 1 ? format->bpp / 8 : 1;
+
+ max_pitch = 4
[PATCH v7 14/17] drm: rcar-du: Add rcar_du_lib_mode_cfg_helper_get()
Add rcar_du_lib_mode_cfg_helper_get() in RCar DU kms lib to get the
pointer to rcar_du_mode_config_helper, so that both rcar_du_atomic_
commit_tail() and rcar_du_mode_config_helper can be reused by
rcar_du_modeset_init() and rzg2l_du_modeset_init().
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 46 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 59 +++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 3 ++
3 files changed, 63 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 74845d8bad9d..b0b40b1cc37d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -7,9 +7,7 @@
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
-#include
#include
-#include
#include
#include
#include
@@ -61,52 +59,10 @@ static int rcar_du_atomic_check(struct drm_device *dev,
return rcar_du_atomic_check_planes(dev, state);
}
-static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
-{
- struct drm_device *dev = old_state->dev;
- struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- struct drm_crtc_state *crtc_state;
- struct drm_crtc *crtc;
- unsigned int i;
-
- /*
-* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured
-* when starting the CRTCs.
-*/
- rcdu->dpad1_source = -1;
-
- for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
- struct rcar_du_crtc_state *rcrtc_state =
- to_rcar_crtc_state(crtc_state);
- struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
-
- if (rcrtc_state->outputs & BIT(RCAR_DU_OUTPUT_DPAD0))
- rcdu->dpad0_source = rcrtc->index;
-
- if (rcrtc_state->outputs & BIT(RCAR_DU_OUTPUT_DPAD1))
- rcdu->dpad1_source = rcrtc->index;
- }
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state,
- DRM_PLANE_COMMIT_ACTIVE_ONLY);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_hw_done(old_state);
- drm_atomic_helper_wait_for_flip_done(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-}
-
/*
-
* Initialization
*/
-static const struct drm_mode_config_helper_funcs rcar_du_mode_config_helper = {
- .atomic_commit_tail = rcar_du_atomic_commit_tail,
-};
-
static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
.atomic_check = rcar_du_atomic_check,
@@ -412,7 +368,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
dev->mode_config.min_height = 0;
dev->mode_config.normalize_zpos = true;
dev->mode_config.funcs = &rcar_du_mode_config_funcs;
- dev->mode_config.helper_private = &rcar_du_mode_config_helper;
+ dev->mode_config.helper_private = rcar_du_lib_mode_cfg_helper_get();
if (rcdu->info->gen < 3) {
dev->mode_config.max_width = 4095;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index f092d8e4aa16..13d033009c9f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -7,6 +7,9 @@
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*/
+#include
+#include
+#include
#include
#include
#include
@@ -476,3 +479,59 @@ rcar_du_lib_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
+
+/*
-
+ * Atomic Check and Update
+ */
+
+static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
+{
+ struct drm_device *dev = old_state->dev;
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ unsigned int i;
+
+ /*
+* Store RGB routing to DPAD0 and DPAD1, the hardware will be configured
+* when starting the CRTCs.
+*/
+ rcdu->dpad1_source = -1;
+
+ for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+ struct rcar_du_crtc_state *rcrtc_state =
+ to_rcar_crtc_state(crtc_state);
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc
[PATCH v7 16/17] drm: rcar-du: Move rcar_du_properties_init()
Move rcar_du_properties_init() to RCar DU kms lib, so that it can be
shared by both RCar and RZ/G2L kms drivers.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 16
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 2 ++
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 94f1602ea707..01ffe36f9d44 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -69,22 +69,6 @@ static const struct drm_mode_config_funcs
rcar_du_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static int rcar_du_properties_init(struct rcar_du_device *rcdu)
-{
- /*
-* The color key is expressed as an RGB888 triplet stored in a 32-bit
-* integer in XRGB format. Bit 24 is used as a flag to disable (0)
-* or enable source color keying (1).
-*/
- rcdu->props.colorkey =
- drm_property_create_range(&rcdu->ddev, 0, "colorkey",
- 0, 0x01ff);
- if (rcdu->props.colorkey == NULL)
- return -ENOMEM;
-
- return 0;
-}
-
static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
{
const struct device_node *np = rcdu->dev->of_node;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 781e666a45a8..438a56c550f2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -637,3 +637,19 @@ int rcar_du_encoders_init(struct rcar_du_device *rcdu,
return num_encoders;
}
+
+int rcar_du_properties_init(struct rcar_du_device *rcdu)
+{
+ /*
+* The color key is expressed as an RGB888 triplet stored in a 32-bit
+* integer in XRGB format. Bit 24 is used as a flag to disable (0)
+* or enable source color keying (1).
+*/
+ rcdu->props.colorkey =
+ drm_property_create_range(&rcdu->ddev, 0, "colorkey",
+ 0, 0x01ff);
+ if (rcdu->props.colorkey == NULL)
+ return -ENOMEM;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
index ace973b80fe6..50e92a19d98c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h
@@ -51,4 +51,6 @@ int rcar_du_encoders_init(struct rcar_du_device *rcdu,
enum rcar_du_output output,
struct device_node *enc_node));
+int rcar_du_properties_init(struct rcar_du_device *rcdu);
+
#endif /* __RCAR_DU_KMS_LIB_H__ */
--
2.25.1
[PATCH v7 15/17] drm: rcar-du: Move rcar_du_encoders_init()
RZ/G2L supports only DSI and DPI. Add rcar_du_encoders_init() to handle
the pointer to du_output_name(), so that we can share du_encoders_init()
between RCar and RZ/G2L kms drivers.
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 92 +--
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 102 ++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 6 ++
3 files changed, 110 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b0b40b1cc37d..94f1602ea707 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -69,95 +69,6 @@ static const struct drm_mode_config_funcs
rcar_du_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu,
-enum rcar_du_output output,
-struct of_endpoint *ep)
-{
- struct device_node *entity;
- int ret;
-
- /* Locate the connected entity and initialize the encoder. */
- entity = of_graph_get_remote_port_parent(ep->local_node);
- if (!entity) {
- dev_dbg(rcdu->dev, "unconnected endpoint %pOF, skipping\n",
- ep->local_node);
- return -ENODEV;
- }
-
- if (!of_device_is_available(entity)) {
- dev_dbg(rcdu->dev,
- "connected entity %pOF is disabled, skipping\n",
- entity);
- of_node_put(entity);
- return -ENODEV;
- }
-
- ret = rcar_du_encoder_init(rcdu, output, entity);
- if (ret && ret != -EPROBE_DEFER && ret != -ENOLINK)
- dev_warn(rcdu->dev,
-"failed to initialize encoder %pOF on output %s (%d),
skipping\n",
-entity, rcar_du_output_name(output), ret);
-
- of_node_put(entity);
-
- return ret;
-}
-
-static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
-{
- struct device_node *np = rcdu->dev->of_node;
- struct device_node *ep_node;
- unsigned int num_encoders = 0;
-
- /*
-* Iterate over the endpoints and create one encoder for each output
-* pipeline.
-*/
- for_each_endpoint_of_node(np, ep_node) {
- enum rcar_du_output output;
- struct of_endpoint ep;
- unsigned int i;
- int ret;
-
- ret = of_graph_parse_endpoint(ep_node, &ep);
- if (ret < 0) {
- of_node_put(ep_node);
- return ret;
- }
-
- /* Find the output route corresponding to the port number. */
- for (i = 0; i < RCAR_DU_OUTPUT_MAX; ++i) {
- if (rcdu->info->routes[i].possible_crtcs &&
- rcdu->info->routes[i].port == ep.port) {
- output = i;
- break;
- }
- }
-
- if (i == RCAR_DU_OUTPUT_MAX) {
- dev_warn(rcdu->dev,
-"port %u references unexisting output,
skipping\n",
-ep.port);
- continue;
- }
-
- /* Process the output pipeline. */
- ret = rcar_du_encoders_init_one(rcdu, output, &ep);
- if (ret < 0) {
- if (ret == -EPROBE_DEFER) {
- of_node_put(ep_node);
- return ret;
- }
-
- continue;
- }
-
- num_encoders++;
- }
-
- return num_encoders;
-}
-
static int rcar_du_properties_init(struct rcar_du_device *rcdu)
{
/*
@@ -457,7 +368,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
}
/* Initialize the encoders. */
- ret = rcar_du_encoders_init(rcdu);
+ ret = rcar_du_encoders_init(rcdu, rcar_du_output_name,
+ rcar_du_encoder_init);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 13d033009c9f..781e666a45a8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+#include
#include
#include "rcar_du_drv.h"
@@ -535,3 +537,103 @@ rcar_du_lib_mode_cfg_helper_get(void)
{
return &rcar_du_mode_config_helper;
}
+
[PATCH v7 17/17] drm: rcar-du: Add rcar_du_lib_vsps_init()
Add rcar_du_lib_vsps_init() to RCar DU kms lib to handle both
rcar_du_vsp_init() and rzg2l_du_vsp_init().
Signed-off-by: Biju Das
---
v6->v7:
* Rebased to drm-tip.
v1->v6:
* Rebased on drm-misc-next and DU-next.
v1:
* Created the lib suggested by Laurent.
Ref:
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220316131100.30685-6-biju.das...@bp.renesas.com/
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 88 +-
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 89 +++
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.h | 5 ++
3 files changed, 95 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 01ffe36f9d44..6f3352a6a264 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -69,92 +69,6 @@ static const struct drm_mode_config_funcs
rcar_du_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
-{
- const struct device_node *np = rcdu->dev->of_node;
- const char *vsps_prop_name = "renesas,vsps";
- struct of_phandle_args args;
- struct {
- struct device_node *np;
- unsigned int crtcs_mask;
- } vsps[RCAR_DU_MAX_VSPS] = { { NULL, }, };
- unsigned int vsps_count = 0;
- unsigned int cells;
- unsigned int i;
- int ret;
-
- /*
-* First parse the DT vsps property to populate the list of VSPs. Each
-* entry contains a pointer to the VSP DT node and a bitmask of the
-* connected DU CRTCs.
-*/
- ret = of_property_count_u32_elems(np, vsps_prop_name);
- if (ret < 0) {
- /* Backward compatibility with old DTBs. */
- vsps_prop_name = "vsps";
- ret = of_property_count_u32_elems(np, vsps_prop_name);
- }
- cells = ret / rcdu->num_crtcs - 1;
- if (cells > 1)
- return -EINVAL;
-
- for (i = 0; i < rcdu->num_crtcs; ++i) {
- unsigned int j;
-
- ret = of_parse_phandle_with_fixed_args(np, vsps_prop_name,
- cells, i, &args);
- if (ret < 0)
- goto error;
-
- /*
-* Add the VSP to the list or update the corresponding existing
-* entry if the VSP has already been added.
-*/
- for (j = 0; j < vsps_count; ++j) {
- if (vsps[j].np == args.np)
- break;
- }
-
- if (j < vsps_count)
- of_node_put(args.np);
- else
- vsps[vsps_count++].np = args.np;
-
- vsps[j].crtcs_mask |= BIT(i);
-
- /*
-* Store the VSP pointer and pipe index in the CRTC. If the
-* second cell of the 'renesas,vsps' specifier isn't present,
-* default to 0 to remain compatible with older DT bindings.
-*/
- rcdu->crtcs[i].vsp = &rcdu->vsps[j];
- rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0;
- }
-
- /*
-* Then initialize all the VSPs from the node pointers and CRTCs bitmask
-* computed previously.
-*/
- for (i = 0; i < vsps_count; ++i) {
- struct rcar_du_vsp *vsp = &rcdu->vsps[i];
-
- vsp->index = i;
- vsp->dev = rcdu;
-
- ret = rcar_du_vsp_init(vsp, vsps[i].np, vsps[i].crtcs_mask);
- if (ret < 0)
- goto error;
- }
-
- return 0;
-
-error:
- for (i = 0; i < ARRAY_SIZE(vsps); ++i)
- of_node_put(vsps[i].np);
-
- return ret;
-}
-
static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
{
const struct device_node *np = rcdu->dev->of_node;
@@ -326,7 +240,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
/* Initialize the compositors. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
- ret = rcar_du_vsps_init(rcdu);
+ ret = rcar_du_lib_vsps_init(rcdu, rcar_du_vsp_init);
if (ret < 0)
return ret;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
index 438a56c550f2..b9949dbd3c33 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c
@@ -653,3 +653,92 @@ int rcar_du_properties_init(struct rcar_du_device *rcdu)
return 0;
}
+
+int rcar_du_lib_vsps_init(struct rcar_du_device *rcdu,
+ int (*rcar_du_vsp_init_fn)(struct rcar_du_vsp *vsp,
+struct device_node *np,
+un
[PATCH v7 1/8] dt-bindings: display: Document Renesas RZ/G2L DU bindings
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timings
− Selecting the polarity of output DCLK, HSYNC, VSYNC, and DE
− Supports Progressive
− Input data format (from VSPD): RGB888, RGB666
− Output data format: same as Input data format
− Supporting Full HD (1920 pixels x 1080 lines) for MIPI-DSI Output
− Supporting WXGA (1280 pixels x 800 lines) for Parallel Output
This patch document DU module found on RZ/G2L LCDC.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
---
v6->v7:
* No change
v5->v6:
* No change.
v4->v5:
* Added Rb tag from Rob.
v3->v4:
* Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
* started using same compatible for RZ/G2{L,LC}
v3: New patch
---
.../bindings/display/renesas,rzg2l-du.yaml| 124 ++
1 file changed, 124 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
new file mode 100644
index ..7626043debd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Display Unit (DU)
+
+maintainers:
+ - Laurent Pinchart
+ - Biju Das
+
+description: |
+ These DT bindings describe the Display Unit embedded in the Renesas RZ/G2L
+ and RZ/V2L SoCs.
+
+properties:
+ compatible:
+enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ The connections to the DU output video ports are modeled using the OF
+ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+ The number of ports and their assignment are model-dependent. Each port
+ shall have a single endpoint.
+
+patternProperties:
+ "^port@[0-1]$":
+$ref: /schemas/graph.yaml#/properties/port
+unevaluatedProperties: false
+
+required:
+ - port@0
+
+unevaluatedProperties: false
+
+ renesas,vsps:
+$ref: "/schemas/types.yaml#/definitions/phandle-array"
+items:
+ items:
+- description: phandle to VSP instance that serves the DU channel
+- description: Channel index identifying the LIF instance in that VSP
+description:
+ A list of phandle and channel index tuples to the VSPs that handle the
+ memory interfaces for the DU channels.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - ports
+ - renesas,vsps
+
+additionalProperties: false
+
+examples:
+ # RZ/G2L DU
+ - |
+#include
+#include
+
+display@1089 {
+compatible = "renesas,r9a07g044-du";
+reg = <0x1089 0x1>;
+interrupts = ;
+clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_D>;
+clock-names = "aclk", "pclk", "vclk";
+resets = <&cpg R9A07G044_LCDC_RESET_N>;
+power-domains = <&cpg>;
+
+renesas,vsps = <&vspd0 0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <&dsi0_in>;
+};
+};
+port@1 {
+reg = <1>;
+endpoint {
+};
+};
+};
+};
+
+...
--
2.25.1
[PATCH v7 0/8] Add RZ/{G2L,G2LC} and RZ/V2L DU support
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from DSI is connected to ADV7535.
Created new CRTC/DRM driver specific to RZ/G2L alike SoCs using RCar DU lib.
This patch series tested on SMARC EVK based on RZ/{G2L,G2LC} and RZ/V2L SoCs.
This patch series depend upon [1]
[1]
https://lore.kernel.org/linux-renesas-soc/2023044235.366042-1-biju.das...@bp.renesas.com/T/#t
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
* Added patch #2 for binding support for RZ/V2L DU
* Added patch #4 for driver support for RZ/V2L DU
* Added patch #5 for SoC DTSI support for RZ/G2L DU
* Added patch #6 for SoC DTSI support for RZ/V2L DU
* Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
* Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
Biju Das (8):
dt-bindings: display: Document Renesas RZ/G2L DU bindings
dt-bindings: display: renesas,rzg2l-du: Document RZ/V2L DU bindings
drm: rcar-du: Add RZ/G2L DU Support
drm: rzg2l-du: Add RZ/V2L DU Support
arm64: dts: renesas: r9a07g044: Add DU node
arm64: dts: renesas: r9a07g054: Add DU node
arm64: dts: renesas: rzg2l-smarc: Enable DU and link with DSI
arm64: dts: renesas: rzg2lc-smarc: Enable DU and link with DSI
.../bindings/display/renesas,rzg2l-du.yaml| 129
arch/arm64/boot/dts/renesas/r9a07g044.dtsi| 14 +
arch/arm64/boot/dts/renesas/r9a07g054.dtsi| 14 +
arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 21 +
arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi | 21 +
drivers/gpu/drm/rcar-du/Kconfig | 17 +-
drivers/gpu/drm/rcar-du/Makefile | 13 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 +
drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c | 716 ++
drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h | 26 +
drivers/gpu/drm/rcar-du/rzg2l_du_drv.c| 197 +
drivers/gpu/drm/rcar-du/rzg2l_du_drv.h| 20 +
drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c| 26 +
drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h| 19 +
drivers/gpu/drm/rcar-du/rzg2l_du_kms.c| 157
drivers/gpu/drm/rcar-du/rzg2l_du_kms.h| 17 +
drivers/gpu/drm/rcar-du/rzg2l_du_regs.h | 67 ++
drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c| 82 ++
drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h| 30 +
19 files changed, 1594 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.h
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.h
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c
create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h
--
2.25.1
[PATCH v7 2/8] dt-bindings: display: renesas, rzg2l-du: Document RZ/V2L DU bindings
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
---
v7:
* New patch.
---
.../devicetree/bindings/display/renesas,rzg2l-du.yaml| 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 7626043debd8..e29ba0145f89 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -16,8 +16,13 @@ description: |
properties:
compatible:
-enum:
- - renesas,r9a07g044-du # RZ/G2{L,LC}
+oneOf:
+ - enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+ - items:
+ - enum:
+ - renesas,r9a07g054-vsp2# RZ/V2L
+ - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
reg:
maxItems: 1
--
2.25.1
[PATCH v7 3/8] drm: rcar-du: Add RZ/G2L DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU). It has DPI/DSI interfaces and supports a maximum resolution of 1080p along with 2 RPFs to support the blending of two picture layers and raster operations (ROPs). The DU module is connected to VSPD. Add support for RZ/G2L DU by creating CRTC/DRM driver specific to RZ/G2L and link with the RCar DU lib for the common code between both RCar and RZ/G2L. Signed-off-by: Biju Das --- v6->v7: * rebased to latest drm-tip. v5->v6: * Updated commit description * Updated Kconfig * Replaced drm_fb_cma_helper->drm_gem_dma_helper * Updated header files. v4->v5: * Started using RCar DU libs(kms, vsp and encoder) * Started using rcar_du_device, rcar_du_write, rcar_du_crtc, rcar_du_format_info and rcar_du_encoder. v3->v4: * Removed rzg2l_du_group.h and struct rzg2l_du_group * Renamed __rzg2l_du_group_start_stop->rzg2l_du_start_stop * Removed rzg2l_du_group_restart * Updated rzg2l_du_crtc_set_display_timing * Removed mode_valid callback. * Updated rzg2l_du_crtc_create() parameters * Updated compatible * Removed RZG2L_DU_MAX_GROUPS v3: * New patch after removing all the indirections and by adding new DRM driver. --- drivers/gpu/drm/rcar-du/Kconfig| 17 +- drivers/gpu/drm/rcar-du/Makefile | 13 + drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 + drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c| 716 + drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h| 26 + drivers/gpu/drm/rcar-du/rzg2l_du_drv.c | 196 ++ drivers/gpu/drm/rcar-du/rzg2l_du_drv.h | 20 + drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c | 26 + drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h | 19 + drivers/gpu/drm/rcar-du/rzg2l_du_kms.c | 157 + drivers/gpu/drm/rcar-du/rzg2l_du_kms.h | 17 + drivers/gpu/drm/rcar-du/rzg2l_du_regs.h| 67 ++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c | 82 +++ drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h | 30 + 14 files changed, 1394 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_encoder.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.c create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_du_vsp.h diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 373568a23655..e786a2aeea9a 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -11,6 +11,18 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. +config DRM_RZG2L_DU + tristate "DRM Support for RZ/G2L Display Unit" + depends on DRM && OF + depends on ARM || ARM64 + depends on ARCH_RZG2L || COMPILE_TEST + select DRM_KMS_HELPER + select DRM_GEM_DMA_HELPER + select VIDEOMODE_HELPERS + help + Choose this option if you have an RZ/G2L chipset. + If M is selected the module will be called rzg2l-du-drm. + config DRM_RCAR_USE_CMM bool "R-Car DU Color Management Module (CMM) Support" depends on DRM_RCAR_DU @@ -71,8 +83,9 @@ config DRM_RZG2L_MIPI_DSI config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM default y if ARM64 - depends on DRM_RCAR_DU + depends on DRM_RCAR_DU || DRM_RZG2L_DU depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m) + depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RZG2L_DU=m) help Enable support to expose the R-Car VSP Compositor as KMS planes. @@ -84,7 +97,7 @@ config DRM_RCAR_WRITEBACK config DRM_RCAR_LIB bool default y - depends on DRM_RCAR_DU + depends on DRM_RCAR_DU || DRM_RZG2L_DU config DRM_RCAR_VSP_LIB bool diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile index 8fc924cf37a7..ca905c526469 100644 --- a/drivers/gpu/drm/rcar-du/Makefile +++ b/drivers/gpu/drm/rcar-du/Makefile @@ -19,4 +19,17 @@ obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o obj-$(CONFIG_DRM_RCAR_MIPI_DSI)+= rcar_mipi_dsi.o +rzg2l-du-drm-y := rzg2l_du_crtc.o \ + rzg2l_du_drv.o \ + rzg2l_du_encoder.o \ + rzg2l_du_kms.o \ + +rzg2l-du-drm-$(CONFIG_DRM_RCAR_LIB) += rcar_du_encoder_lib.o \ + rcar_du_k
[PATCH v7 4/8] drm: rzg2l-du: Add RZ/V2L DU Support
Add support for RZ/V2L DU. The RZ/V2L DU block is identical to
RZ/G2L SoC.
Signed-off-by: Biju Das
---
v7:
* New patch.
---
drivers/gpu/drm/rcar-du/rzg2l_du_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
b/drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
index be9aeccbfdc7..6d7f20e3af39 100644
--- a/drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rzg2l_du_drv.c
@@ -53,6 +53,7 @@ static const struct rcar_du_device_info
rzg2l_du_r9a07g044_info = {
static const struct of_device_id rzg2l_du_of_table[] = {
{ .compatible = "renesas,r9a07g044-du", .data =
&rzg2l_du_r9a07g044_info },
+ { .compatible = "renesas,r9a07g054-du", .data =
&rzg2l_du_r9a07g044_info },
{ /* sentinel */ }
};
--
2.25.1
[PATCH v7 5/8] arm64: dts: renesas: r9a07g044: Add DU node
Add DU node to RZ/G2L SoC DTSI.
Signed-off-by: Biju Das
---
v7:
* New patch.
---
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
index 23bd28dd4d95..003a3711ad56 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
@@ -671,6 +671,20 @@ fcpvd: fcp@1088 {
resets = <&cpg R9A07G044_LCDC_RESET_N>;
};
+ du: display@1089 {
+ compatible = "renesas,r9a07g044-du";
+ reg = <0 0x1089 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G044_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_LCDC_RESET_N>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+ };
+
cpg: clock-controller@1101 {
compatible = "renesas,r9a07g044-cpg";
reg = <0 0x1101 0 0x1>;
--
2.25.1
[PATCH v7 6/8] arm64: dts: renesas: r9a07g054: Add DU node
Add DU node to RZ/V2L SoC DTSI.
Signed-off-by: Biju Das
---
v7:
* New patch.
---
arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
index 244934ce5991..c20bc859331d 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
@@ -677,6 +677,20 @@ fcpvd: fcp@1088 {
resets = <&cpg R9A07G054_LCDC_RESET_N>;
};
+ du: display@1089 {
+ compatible = "renesas,r9a07g054-du";
+ reg = <0 0x1089 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G054_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G054_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G054_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G054_LCDC_RESET_N>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+ };
+
cpg: clock-controller@1101 {
compatible = "renesas,r9a07g054-cpg";
reg = <0 0x1101 0 0x1>;
--
2.25.1
[PATCH v7 7/8] arm64: dts: renesas: rzg2l-smarc: Enable DU and link with DSI
Enable DU and link with DSI on RZ/{G2L,V2L} SMARC EVK.
Signed-off-by: Biju Das
---
arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi | 21
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
b/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
index 2a158a954b2f..cd4f569df5cd 100644
--- a/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg2l-smarc.dtsi
@@ -49,6 +49,7 @@ ports {
port@0 {
reg = <0>;
dsi0_in: endpoint {
+ remote-endpoint = <&du_out_dsi>;
};
};
@@ -62,6 +63,26 @@ dsi0_out: endpoint {
};
};
+&du {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_dsi: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+};
+
&i2c1 {
adv7535: hdmi@3d {
compatible = "adi,adv7535";
--
2.25.1
[PATCH v7 8/8] arm64: dts: renesas: rzg2lc-smarc: Enable DU and link with DSI
Enable DU on RZ/G2LC SMARC EVK by linking with DSI.
Signed-off-by: Biju Das
---
v7:
* New patch.
---
arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi | 21 +++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi
b/arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi
index 6818fd49b2be..a56110b6d0d4 100644
--- a/arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg2lc-smarc.dtsi
@@ -63,6 +63,7 @@ ports {
port@0 {
reg = <0>;
dsi0_in: endpoint {
+ remote-endpoint = <&du_out_dsi>;
};
};
@@ -76,6 +77,26 @@ dsi0_out: endpoint {
};
};
+&du {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_dsi: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+};
+
&i2c1 {
adv7535: hdmi@3d {
compatible = "adi,adv7535";
--
2.25.1
Re: [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
Am 11.04.23 um 11:51 schrieb Daniel Vetter:
On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
Reduce the page max order to the system PMD size, as we can then be nicer
to the system and avoid splitting gigantic pages.
Looking forward to when we might be able to swap out PMD size folios
without splitting, this will also be a benefit.
v2:
- Include all orders up to the PMD size (Christian König)
v3:
- Avoid compilation errors for architectures with special PFN_SHIFTs
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
Apparently this fails on ppc build testing. Please supply build fix asap
(or I guess we need to revert). I'm kinda not clear why this only showed
up when I merged the drm-misc-next pr into drm-next ...
I'm really wondering this as well. It looks like PMD_SHIFT isn't a
constant on this particular platform.
But from what I can find in the upstream 6.2 kernel PMD_SHIFT always
seems to be a constant.
So how exactly can that here break?
Christian.
-Daniel
---
drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index dfce896c4bae..18c342a919a2 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -47,6 +47,11 @@
#include "ttm_module.h"
+#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
+#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
+/* Some architectures have a weird PMD_SHIFT */
+#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER :
MAX_ORDER)
+
/**
* struct ttm_pool_dma - Helper object for coherent DMA mappings
*
@@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
static atomic_long_t allocated_pages;
-static struct ttm_pool_type global_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
static spinlock_t shrinker_lock;
static struct list_head shrinker_list;
@@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
else
gfp_flags |= GFP_HIGHUSER;
- for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
+ for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
num_pages;
order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
@@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
if (use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
+ for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_init(&pool->caching[i].orders[j],
pool, i, j);
}
@@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
if (pool->use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
+ for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_fini(&pool->caching[i].orders[j]);
}
@@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
unsigned int i;
seq_puts(m, "\t ");
- for (i = 0; i < MAX_ORDER; ++i)
+ for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " ---%2u---", i);
seq_puts(m, "\n");
}
@@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type
*pt,
{
unsigned int i;
- for (i = 0; i < MAX_ORDER; ++i)
+ for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " %8u", ttm_pool_type_count(&pt[i]));
seq_puts(m, "\n");
}
@@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
{
unsigned int i;
+ BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
+ BUILD_BUG_ON(TTM_DIM_ORDER < 1);
+
if (!page_pool_size)
page_pool_size = num_pages;
spin_lock_init(&shrinker_lock);
INIT_LIST_HEAD(&shrinker_list);
- for (i = 0; i < MAX_ORDER; ++i) {
+ for (i = 0; i < TTM_DIM_ORDER; ++i) {
ttm_pool_type_init(&global_write_combined[i], NULL,
ttm_write_combined, i);
ttm_pool_type_in
Re: [PATCH v10 2/2] drm: add kms driver for loongson display controller
Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
+++ b/drivers/gpu/drm/loongson/lsdc_drv.h
@@ -0,0 +1,324 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2022 Loongson Corporation
+ *
We're in 2023, update the year across the files?
OK, it just that we started to upstream this driver since 2022.
+struct lsdc_gem {
+ /* @mutex: protect objects list */
+ struct mutex mutex;
+ struct list_head objects;
+};
+
+struct lsdc_device {
+ struct drm_device base;
+ struct ttm_device bdev;
+
+ /* @descp: features description of the DC variant */
+ const struct lsdc_desc *descp;
+
+ struct pci_dev *gpu;
+
+ /* @reglock: protects concurrent access */
+ spinlock_t reglock;
+ void __iomem *reg_base;
+ resource_size_t vram_base;
+ resource_size_t vram_size;
+
+ resource_size_t gtt_size;
+
+ struct lsdc_display_pipe dispipe[LSDC_NUM_CRTC];
+
+ struct lsdc_gem gem;
+
Last time I looked there was no other driver with a list of gem
objects (and a mutex) in its device struct. Are you sure we need this?
Sure, this is absolutely necessary.
Without this I can't see how much buffer object has been created.
where they are(SYETEM, GTT or VRAM) and how much size it the buffer is.
When sharing buffer with other driver, cat /sys/kernel/debug/dri/0/bos
can be used to see that the shared buffer is pinned in the GTT.
Very few drivers use TTM directly and I think you want to use
drm_gem_vram_helper or drm_gem_ttm_helper instead.
We love you reviews, yet...
yet using the TTM is pretty good.
drm_gem_vram_helper is also good for beginners.
We can explicitly specify where to put the bo with TTM,
We also need this to implement the S3 properly.
Thomas also recommend us switch to TTM.
+static int ls7a1000_pixpll_param_update(struct lsdc_pll * const this,
+ struct lsdc_pll_parms const *pin)
+{
+ void __iomem *reg = this->mmio;
+ unsigned int counter = 0;
+ bool locked;
+ u32 val;
+
+ /* Bypass the software configured PLL, using refclk directly */
+ val = readl(reg + 0x4);
+ val &= ~(1 << 8);
+ writel(val, reg + 0x4);
+
There are a lot of magic numbers in this function. Let's define them
properly in the header.
Ok, I will improve this function at the next version.
+/* Helpers for chip detection */
+bool lsdc_is_ls2k2000(void);
+bool lsdc_is_ls2k1000(void);
+unsigned int loongson_cpu_get_prid(u8 *impl, u8 *rev);
Since this revision does pci_devices only, we don't need this detection right?
No, we need it.
In order to get a fine control, we need to know what the host is.
Re: [PATCH v2] drm/vkms: add module parameter to set background color
On 4/11/23 05:58, Simon Ser wrote: Hi, On Monday, April 10th, 2023 at 19:50, Melissa Wen wrote: On 04/10, Simon Ser wrote: I think this should be a KMS property instead of a module parameter. Is there a reason why this patch uses a module parameter? It breaks user-space expectations. a KMS property is what we have on vkms TODO [1] and the module parameter was Maíra's first step to open a discussion for this property [2]. AFAIK, we would need to create the KMS property first, but it seems there isn't an userspace case/need to support this API change. Do you know any valid use cases to support a bkg color property? There have been previous attempts for msm [1] and i915 [2]. From user-space PoV, a KMS property would be useful, for instance to render single color background images. I can type some user-space code if that helps. I believe that, if we have some user-space code, we can push this as a KMS property. If you can provide some user-space code, I can work on the KMS property to back the use case and we can move this forward. If this is a module parameter instead of a KMS property, what purpose does this achieve? What is the use-case? Just trying to understand the motivation here. This was a attempt to start the discussion about the background color property. Without the user-space use case, we cannot move this forward and as I didn't have a user-space use case, I decided to implement it as a module parameter. Best Regards, - Maíra Canal Thanks, Simon [1]: https://lore.kernel.org/dri-devel/20221028225952.160-1-quic_jessz...@quicinc.com/ [2]: https://lore.kernel.org/dri-devel/20190930224707.14904-1-matthew.d.ro...@intel.com/
Re: (subset) [PATCH] drm/vc4: remove unused render_wait variable
On Thu, 06 Apr 2023 11:12:03 -0400, Tom Rix wrote: > smatch reports > drivers/gpu/drm/vc4/vc4_irq.c:60:1: warning: symbol > 'render_wait' was not declared. Should it be static? > > This variable is not used so remove it. > > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH v3 28/65] clk: renesas: r9a06g032: Add a determine_rate hook
Hi Geert & Maxime,
ge...@linux-m68k.org wrote on Tue, 11 Apr 2023 12:27:38 +0200:
> CC Gareth, Hervé, Miquel, Ralph
>
> On Tue, Apr 4, 2023 at 2:44 PM Maxime Ripard wrote:
> > The Renesas r9a06g032 bitselect clock implements a mux with a set_parent
> > hook, but doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since set_parent() is there to, as its name implies,
> > change the parent of a clock. However, the most likely candidate to
> > trigger that parent change is a call to clk_set_rate(), with
> > determine_rate() figuring out which parent is the best suited for a
> > given rate.
> >
> > The other trigger would be a call to clk_set_parent(), but it's far less
> > used, and it doesn't look like there's any obvious user for that clock.
> >
> > So, the set_parent hook is effectively unused, possibly because of an
> > oversight. However, it could also be an explicit decision by the
> > original author to avoid any reparenting but through an explicit call to
> > clk_set_parent().
> >
> > The latter case would be equivalent to setting the flag
> > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
> > to __clk_mux_determine_rate(). Indeed, if no determine_rate
> > implementation is provided, clk_round_rate() (through
> > clk_core_round_rate_nolock()) will call itself on the parent if
> > CLK_SET_RATE_PARENT is set, and will not change the clock rate
> > otherwise. __clk_mux_determine_rate() has the exact same behavior when
> > CLK_SET_RATE_NO_REPARENT is set.
> >
> > And if it was an oversight, then we are at least explicit about our
> > behavior now and it can be further refined down the line.
> >
> > Signed-off-by: Maxime Ripard
>
> LGTM, so
> Reviewed-by: Geert Uytterhoeven
I searched for 'possible callers', I didn't find any places
where this would be used on the consumer side. However, downstream,
there is a rzn1-clock-bitselect.c clock driver which states:
+ * This clock provider handles the case of the RZN1 where you have peripherals
+ * that have two potential clock source and two gates, one for each of the
+ * clock source - the used clock source (for all sub clocks) is selected by a
+ * single bit.
+ * That single bit affects all sub-clocks, and therefore needs to change the
+ * active gate (and turn the others off) and force a recalculation of the
rates.
I don't know how much of this file has been upstreamed (under a
different form) but this might very well be related to the fact that
reparenting in some cases would be a major issue and thus needs to be
avoided unless done on purpose (guessing?).
Maybe Ralph can comment, but for what I understand,
Reviewed-by: Miquel Raynal
> But I do not have the hardware.
>
> > --- a/drivers/clk/renesas/r9a06g032-clocks.c
> > +++ b/drivers/clk/renesas/r9a06g032-clocks.c
> > @@ -1121,6 +1121,7 @@ static int r9a06g032_clk_mux_set_parent(struct clk_hw
> > *hw, u8 index)
> > }
> >
> > static const struct clk_ops clk_bitselect_ops = {
> > + .determine_rate = __clk_mux_determine_rate,
> > .get_parent = r9a06g032_clk_mux_get_parent,
> > .set_parent = r9a06g032_clk_mux_set_parent,
> > };
> > @@ -1145,7 +1146,7 @@ r9a06g032_register_bitsel(struct r9a06g032_priv
> > *clocks,
> >
> > init.name = desc->name;
> > init.ops = &clk_bitselect_ops;
> > - init.flags = CLK_SET_RATE_PARENT;
> > + init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT;
> > init.parent_names = names;
> > init.num_parents = 2;
> >
>
> Gr{oetje,eeting}s,
>
> Geert
>
Thanks,
Miquèl
[PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
Date: Tue, 11 Apr 2023 10:52:48 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “amdgpu_ras_interrupt_dispatch”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “data” behind the null pointer check.
This issue was detected by using the Coccinelle software.
Fixes: c030f2e4166c3f5597c7e7a70bcd9ab383695de4 ("drm/amdgpu: add amdgpu_ras.c
to support ras (v2)")
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 4069bce9479f..a920c7888d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device
*adev,
struct ras_dispatch_if *info)
{
struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
- struct ras_ih_data *data = &obj->ih_data;
+ struct ras_ih_data *data;
if (!obj)
return -EINVAL;
+ data = &obj->ih_data;
if (data->inuse == 0)
return 0;
--
2.40.0
[PATCH 0/5] drm/amd: Adjustments for three function implementations
Date: Tue, 11 Apr 2023 14:36:36 +0200 Some update suggestions were taken into account from static source code analysis. Markus Elfring (5) amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch() display: Move three variable assignments behind condition checks in trigger_hotplug() display: Delete three unnecessary variable initialisations in trigger_hotplug() display: Delete a redundant statement in trigger_hotplug() display: Move an expression into a return statement in dcn201_link_encoder_create() drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++- .../amd/display/dc/dcn201/dcn201_resource.c | 4 +--- 3 files changed, 13 insertions(+), 13 deletions(-) -- 2.40.0
[PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()
Date: Tue, 11 Apr 2023 11:39:02 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “trigger_hotplug”.
Thus avoid the risk for undefined behaviour by moving the assignment
for three local variables behind some condition checks.
This issue was detected by using the Coccinelle software.
Fixes: 6f77b2ac628073f647041a92b36c824ae3aef16e ("drm/amd/display: Add
connector HPD trigger debugfs entry")
Signed-off-by: Markus Elfring
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..b3cfd7dfbb28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1205,10 +1205,10 @@ static ssize_t trigger_hotplug(struct file *f, const
char __user *buf,
size_t size, loff_t
*pos)
{
struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
- struct drm_connector *connector = &aconnector->base;
+ struct drm_connector *connector;
struct dc_link *link = NULL;
- struct drm_device *dev = connector->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
+ struct drm_device *dev;
+ struct amdgpu_device *adev;
enum dc_connection_type new_connection_type = dc_connection_none;
char *wr_buf = NULL;
uint32_t wr_buf_size = 42;
@@ -1253,12 +1253,16 @@ static ssize_t trigger_hotplug(struct file *f, const
char __user *buf,
return -EINVAL;
}
+ connector = &aconnector->base;
+ dev = connector->dev;
+
if (param[0] == 1) {
if (!dc_link_detect_connection_type(aconnector->dc_link,
&new_connection_type) &&
new_connection_type != dc_connection_none)
goto unlock;
+ adev = drm_to_adev(dev);
mutex_lock(&adev->dm.dc_lock);
ret = dc_link_detect(aconnector->dc_link, DETECT_REASON_HPD);
mutex_unlock(&adev->dm.dc_lock);
--
2.40.0
Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:
> This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> restore") - I failed to realize that nasty userspace could set this.
>
> It's not pretty to mix up kernel-internal and userspace uapi flags
> like this, but since the entire fb_var_screeninfo structure is uapi
> we'd need to either add a new parameter to the ->fb_set_par callback
> and fb_set_par() function, which has a _lot_ of users. Or some other
> fairly ugly side-channel int fb_info. Neither is a pretty prospect.
>
> Instead just correct the issue at hand by filtering out this
> kernel-internal flag in the ioctl handling code.
>
> Signed-off-by: Daniel Vetter
> Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
> Cc: Alex Deucher
> Cc: shl...@fastmail.com
> Cc: Michel Dänzer
> Cc: Noralf Trønnes
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v5.7+
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Geert Uytterhoeven
> Cc: Nathan Chancellor
> Cc: Qiujun Huang
> Cc: Peter Rosin
> Cc: linux-fb...@vger.kernel.org
> Cc: Helge Deller
> Cc: Sam Ravnborg
> Cc: Geert Uytterhoeven
> Cc: Samuel Thibault
> Cc: Tetsuo Handa
> Cc: Shigeru Yoshida
An Ack on this (or a better idea) would be great, so I can stuff it into
-fixes.
Thanks, Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 875541ff185b..3fd95a79e4c3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> case FBIOPUT_VSCREENINFO:
> if (copy_from_user(&var, argp, sizeof(var)))
> return -EFAULT;
> + /* only for kernel-internal use */
> + var.activate &= ~FB_ACTIVATE_KD_TEXT;
> console_lock();
> lock_fb_info(info);
> ret = fbcon_modechange_possible(info, &var);
> --
> 2.40.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > When swapping out, we will split multi-order pages both in order to
> > > move them to the swap-cache and to be able to return memory to the
> > > swap cache as soon as possible on a page-by-page basis.
> > > Reduce the page max order to the system PMD size, as we can then be nicer
> > > to the system and avoid splitting gigantic pages.
> > >
> > > Looking forward to when we might be able to swap out PMD size folios
> > > without splitting, this will also be a benefit.
> > >
> > > v2:
> > > - Include all orders up to the PMD size (Christian König)
> > > v3:
> > > - Avoid compilation errors for architectures with special PFN_SHIFTs
> > >
> > > Signed-off-by: Thomas Hellström
> > > Reviewed-by: Christian König
> > Apparently this fails on ppc build testing. Please supply build fix asap
> > (or I guess we need to revert). I'm kinda not clear why this only showed
> > up when I merged the drm-misc-next pr into drm-next ...
>
> I'm really wondering this as well. It looks like PMD_SHIFT isn't a constant
> on this particular platform.
>
> But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
> to be a constant.
>
> So how exactly can that here break?
There's some in-flight patches to rework MAX_ORDER and other things in
linux-next, maybe it's recent? If you check out linux-next then you need
to reapply the patch (since sfr reverted it).
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
> > > 1 file changed, 19 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> > > b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index dfce896c4bae..18c342a919a2 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -47,6 +47,11 @@
> > > #include "ttm_module.h"
> > > +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > > +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> > > +/* Some architectures have a weird PMD_SHIFT */
> > > +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER :
> > > MAX_ORDER)
> > > +
> > > /**
> > >* struct ttm_pool_dma - Helper object for coherent DMA mappings
> > >*
> > > @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
> > > static atomic_long_t allocated_pages;
> > > -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
> > > -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
> > > static spinlock_t shrinker_lock;
> > > static struct list_head shrinker_list;
> > > @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct
> > > ttm_tt *tt,
> > > else
> > > gfp_flags |= GFP_HIGHUSER;
> > > - for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > > + for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
> > >num_pages;
> > >order = min_t(unsigned int, order, __fls(num_pages))) {
> > > struct ttm_pool_type *pt;
> > > @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct
> > > device *dev,
> > > if (use_dma_alloc) {
> > > for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > - for (j = 0; j < MAX_ORDER; ++j)
> > > + for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >
> > > ttm_pool_type_init(&pool->caching[i].orders[j],
> > > pool, i, j);
> > > }
> > > @@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > > if (pool->use_dma_alloc) {
> > > for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > - for (j = 0; j < MAX_ORDER; ++j)
> > > + for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >
> > > ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > > }
> > > @@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file
> > > *m)
> > > unsigned int i;
> > > seq_puts(m, "\t ");
> > > - for (i = 0; i < MAX_ORDER; ++i)
> > > + for (i = 0; i < TTM_DIM_ORDER; ++i)
> > > seq_printf(m, " ---%2u---", i);
> > > seq_puts(m, "\n");
> > > }
> > > @@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct
> > > ttm_pool_type *pt,
> >
[PATCH 3/5] drm/amd/display: Delete three unnecessary variable initialisations in trigger_hotplug()
Date: Tue, 11 Apr 2023 12:34:42 +0200
The variables “link”, “wr_buf” and “ret” will eventually be set
to appropriate values a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index b3cfd7dfbb28..a37d23a13d7b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1206,16 +1206,16 @@ static ssize_t trigger_hotplug(struct file *f, const
char __user *buf,
{
struct amdgpu_dm_connector *aconnector = file_inode(f)->i_private;
struct drm_connector *connector;
- struct dc_link *link = NULL;
+ struct dc_link *link;
struct drm_device *dev;
struct amdgpu_device *adev;
enum dc_connection_type new_connection_type = dc_connection_none;
- char *wr_buf = NULL;
+ char *wr_buf;
uint32_t wr_buf_size = 42;
int max_param_num = 1;
long param[1] = {0};
uint8_t param_nums = 0;
- bool ret = false;
+ bool ret;
if (!aconnector || !aconnector->dc_link)
return -EINVAL;
--
2.40.0
[PATCH 4/5] drm/amd/display: Delete a redundant statement in trigger_hotplug()
Date: Tue, 11 Apr 2023 13:26:35 +0200
An immediate return is performed by this function after a null pointer
was detected for the member “dc_link” in the data
structure “amdgpu_dm_connector”.
This check was repeated within one if branch.
Thus omit such a redundant statement.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index a37d23a13d7b..4805a482dc49 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1278,9 +1278,6 @@ static ssize_t trigger_hotplug(struct file *f, const char
__user *buf,
drm_kms_helper_connector_hotplug_event(connector);
} else if (param[0] == 0) {
- if (!aconnector->dc_link)
- goto unlock;
-
link = aconnector->dc_link;
if (link->local_sink) {
--
2.40.0
Am 11.04.23 um 15:36 schrieb Markus Elfring:
> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
> amdgpu: Move a variable assignment behind a null pointer check in
> amdgpu_ras_interrupt_dispatch()
> display: Move three variable assignments behind condition checks in
> trigger_hotplug()
> display: Delete three unnecessary variable initialisations in
> trigger_hotplug()
> display: Delete a redundant statement in trigger_hotplug()
> display: Move an expression into a return statement in
> dcn201_link_encoder_create()
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
> .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 ++-
> .../amd/display/dc/dcn201/dcn201_resource.c | 4 +---
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
[PATCH 5/5] drm/amd/display: Move an expression into a return statement in dcn201_link_encoder_create()
Date: Tue, 11 Apr 2023 14:04:57 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “dcn201_link_encoder_create”.
Thus avoid the risk for undefined behaviour by moving the usage
of an expression into a return statement.
This issue was detected by using the Coccinelle software.
Fixes: 3f68c01be9a2227de1e190317fe34a6fb835a094 ("drm/amd/display: add
cyan_skillfish display support")
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
index 6ea70da28aaa..a1b44c7bd34b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
@@ -791,7 +791,6 @@ static struct link_encoder *dcn201_link_encoder_create(
{
struct dcn20_link_encoder *enc20 =
kzalloc(sizeof(struct dcn20_link_encoder), GFP_ATOMIC);
- struct dcn10_link_encoder *enc10 = &enc20->enc10;
if (!enc20)
return NULL;
@@ -804,8 +803,7 @@ static struct link_encoder *dcn201_link_encoder_create(
&link_enc_hpd_regs[enc_init_data->hpd_source],
&le_shift,
&le_mask);
-
- return &enc10->base;
+ return &enc20->enc10.base;
}
static struct clock_source *dcn201_clock_source_create(
--
2.40.0
Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
On 2023-04-11 15:44, Daniel Vetter wrote:
On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but since the entire fb_var_screeninfo structure is uapi
we'd need to either add a new parameter to the ->fb_set_par callback
and fb_set_par() function, which has a _lot_ of users. Or some other
fairly ugly side-channel int fb_info. Neither is a pretty prospect.
Instead just correct the issue at hand by filtering out this
kernel-internal flag in the ioctl handling code.
Signed-off-by: Daniel Vetter
Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
Cc: Alex Deucher
Cc: shl...@fastmail.com
Cc: Michel Dänzer
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Cc: Nathan Chancellor
Cc: Qiujun Huang
Cc: Peter Rosin
Cc: linux-fb...@vger.kernel.org
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Geert Uytterhoeven
Cc: Samuel Thibault
Cc: Tetsuo Handa
Cc: Shigeru Yoshida
An Ack on this (or a better idea) would be great, so I can stuff it into
-fixes.
Acked-by: Maarten Lankhorst
Re: [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
Am 2023-04-11 um 09:42 schrieb Markus Elfring:
Date: Tue, 11 Apr 2023 10:52:48 +0200
The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “amdgpu_ras_interrupt_dispatch”.
Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “data” behind the null pointer check.
This issue was detected by using the Coccinelle software.
Fixes: c030f2e4166c3f5597c7e7a70bcd9ab383695de4 ("drm/amdgpu: add amdgpu_ras.c to
support ras (v2)")
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 4069bce9479f..a920c7888d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct amdgpu_device
*adev,
struct ras_dispatch_if *info)
{
struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
- struct ras_ih_data *data = &obj->ih_data;
+ struct ras_ih_data *data;
I'm curious, this only takes the address of obj->ih_data. It doesn't
dereference the pointer until after the !obj check below. How is this
undefined behaviour? Is this about the compiler being free to reorder
stuff for optimization, unaware of the dependency? Is there a link to an
explanation that could be added to the commit description?
Thanks,
Felix
if (!obj)
return -EINVAL;
+ data = &obj->ih_data;
if (data->inuse == 0)
return 0;
--
2.40.0
Patch "drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-display-dp_mst-handle-old-new-payload-states-in-drm_dp_remove_payload.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From e761cc20946a0094df71cb31a565a6a0d03bd8be Mon Sep 17 00:00:00 2001
From: Imre Deak
Date: Mon, 6 Feb 2023 13:48:54 +0200
Subject: drm/display/dp_mst: Handle old/new payload states in
drm_dp_remove_payload()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Imre Deak
commit e761cc20946a0094df71cb31a565a6a0d03bd8be upstream.
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.
This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Wayne Lin
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Reviewed-by: Lyude Paul
Acked-by: Lyude Paul
Acked-by: Daniel Vetter
Acked-by: Wayne Lin
Acked-by: Jani Nikula
Signed-off-by: Imre Deak
Link:
https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.d...@intel.com
Hand modified for missing 8c7d980da9ba3eb67a1b40fd4b33bcf49397084b
Signed-off-by: Mario Limonciello
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c |2 -
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c |4 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c |2 -
include/drm/display/drm_dp_mst_helper.h |3 +
5 files changed, 21 insertions(+), 16 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -206,7 +206,7 @@ bool dm_helpers_dp_mst_write_payload_all
if (enable)
drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
else
- drm_dp_remove_payload(mst_mgr, mst_state, payload);
+ drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
* drm_dp_remove_payload() - Remove an MST payload
* @mgr: Manager to use.
* @mst_state: The MST atomic state
- * @payload: The payload to write
+ * @old_payload: The payload with its old state
+ * @new_payload: The payload to write
*
* Removes a payload from an MST topology if it was successfully assigned a
start slot. Also updates
* the starting time slots of all other payloads which would have been shifted
towards the start of
@@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
*/
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload)
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload)
{
struct drm_dp_mst_atomic_payload *pos;
bool send_remove = false;
/* We failed to make the payload, so nothing to do */
- if (payload->vc_start_slot == -1)
+ if (new_payload->vc_start_slot == -1)
return;
mutex_lock(&mgr->lock);
- send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
mgr->mst_primary);
+ send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (send_remove)
- drm_dp_destroy_payload
Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
Daniel Vetter writes:
> This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> restore") - I failed to realize that nasty userspace could set this.
>
> It's not pretty to mix up kernel-internal and userspace uapi flags
> like this, but since the entire fb_var_screeninfo structure is uapi
> we'd need to either add a new parameter to the ->fb_set_par callback
> and fb_set_par() function, which has a _lot_ of users. Or some other
> fairly ugly side-channel int fb_info. Neither is a pretty prospect.
>
> Instead just correct the issue at hand by filtering out this
> kernel-internal flag in the ioctl handling code.
>
> Signed-off-by: Daniel Vetter
> Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
[..]
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 875541ff185b..3fd95a79e4c3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> case FBIOPUT_VSCREENINFO:
> if (copy_from_user(&var, argp, sizeof(var)))
> return -EFAULT;
> + /* only for kernel-internal use */
> + var.activate &= ~FB_ACTIVATE_KD_TEXT;
> console_lock();
I don't have a better idea on how to fix this and as you said the whole
struct fb_var_screeninfo is an uAPI anyways...
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH] drm/nouveau/mc/ga100: make ga100_mc_device static
Reviewed-by: Karol Herbst
On Thu, Dec 29, 2022 at 4:52 PM Ben Dooks wrote:
>
> Make ga100_mc_device static as it isn't exported, to
> fix the following sparse warning:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c:51:1: warning: symbol
> 'ga100_mc_device' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> index 1e2eabec1a76..5d28d30d09d5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c
> @@ -47,7 +47,7 @@ ga100_mc_device_enabled(struct nvkm_mc *mc, u32 mask)
> return (nvkm_rd32(mc->subdev.device, 0x000600) & mask) == mask;
> }
>
> -const struct nvkm_mc_device_func
> +static const struct nvkm_mc_device_func
> ga100_mc_device = {
> .enabled = ga100_mc_device_enabled,
> .enable = ga100_mc_device_enable,
> --
> 2.39.0
>
Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans
On Sat, Apr 08, 2023 at 04:05:20PM +0900, Asahi Lina wrote: > On 04/04/2023 10.58, Matthew Brost wrote: > > On Tue, Apr 04, 2023 at 10:07:48AM +0900, Asahi Lina wrote: > > > Hi, thanks for the Cc! > > > > > > > No problem. > > > > > On 04/04/2023 09.22, Matthew Brost wrote: > > > > Hello, > > > > > > > > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we > > > > have been asked to merge our common DRM scheduler patches first as well > > > > as develop a common solution for long running workloads with the DRM > > > > scheduler. This RFC series is our first attempt at doing this. We > > > > welcome any and all feedback. > > > > > > > > This can we thought of as 4 parts detailed below. > > > > > > > > - DRM scheduler changes for 1 to 1 relationship between scheduler and > > > > entity (patches 1-3) > > > > > > > > In Xe all of the scheduling of jobs is done by a firmware scheduler (the > > > > GuC) which is a new paradigm WRT to the DRM scheduler and presents > > > > severals problems as the DRM was originally designed to schedule jobs on > > > > hardware queues. The main problem being that DRM scheduler expects the > > > > submission order of jobs to be the completion order of jobs even across > > > > multiple entities. This assumption falls apart with a firmware scheduler > > > > as a firmware scheduler has no concept of jobs and jobs can complete out > > > > of order. A novel solution for was originally thought of by Faith during > > > > the initial prototype of Xe, create a 1 to 1 relationship between > > > > scheduler > > > > and entity. I believe the AGX driver [3] is using this approach and > > > > Boris may use approach as well for the Mali driver [4]. > > > > > > > > To support a 1 to 1 relationship we move the main execution function > > > > from a kthread to a work queue and add a new scheduling mode which > > > > bypasses code in the DRM which isn't needed in a 1 to 1 relationship. > > > > The new scheduling mode should unify all drivers usage with a 1 to 1 > > > > relationship and can be thought of as using scheduler as a dependency / > > > > infligt job tracker rather than a true scheduler. > > > > > > Yup, we're in the exact same situation with drm/asahi, so this is very > > > welcome! We've been using the existing scheduler as-is, but this should > > > help > > > remove some unneeded complexity in this use case. > > > > > > > That's the idea. > > > > > Do you want me to pull in this series into our tree and make sure this all > > > works out for us? > > > > > > > We tested this in Xe and it definitely works for us but the more testing > > the better. > > > > I haven't gotten around to testing this series yet, but after more debugging > of drm_sched issues I want to hear more about how Xe uses the scheduler. > > From what I can tell, and from what Christian says, drm_sched has the hidden > requirement that all job objects outlive the scheduler. I've run into > several UAF bugs due to this. Not only that, it also currently has the > requirement that all drm_sched fences outlive the scheduler object. > > These requirements are subtle and only manifest as kernel oopses in rare > corner cases, so it wasn't at all obvious to me that this was somehow a > fundamental design assumption when I started using it. > > As far as I can tell, this design is going to work in 99% of cases for > global-schedulers-per-GPU models, where those corner cases would have to be > hit on top of a GPU removal scenario (and GPU remove is... well, not the > most tested/exercised use case). When the scheduler basically lives forever, > none of this really matters. > > But with a one-scheduler-per-queue model, how do you deal with this when the > queue goes away? So far, without any of the partial bugfixes I have sent so > far (which Christian objected to): > > - If you try to tear down a scheduler with any jobs currently scheduled at > the hardware, drm_sched will oops when those jobs complete and the hw fences > signal. > - If you try to tear down an entity (which should cancel all its pending > jobs) and then the scheduler it was attached to without actually waiting for > all the free_job() callbacks to be called on every job that ever existed for > that entity, you can oops (entity cleanup is asynchronous in some cases like > killed processes, so it will return before all jobs are freed and then that > asynchronous process will crash and burn if the scheduler goes away out from > under its feet). Waiting for job completion fences is not enough for this, > you have to wait until free_job() has actually been called for all jobs. > - Even if you actually wait for all jobs to be truly gone and then tear down > the scheduler, if any scheduler job fences remain alive, that will then oops > if you try to call the debug functions on them (like cat > /sys/kernel/debug/dma_buf/bufinfo). > > I tried to fix these things, but Christian objected implying it was the > driver's job to keep a refe
[PATCH] accel/habanalabs: remove variable gaudi_irq_name
gcc with W=1 reports
drivers/accel/habanalabs/gaudi/gaudi.c:117:19: error:
‘gaudi_irq_name’ defined but not used [-Werror=unused-const-variable=]
117 | static const char
gaudi_irq_name[GAUDI_MSI_ENTRIES][GAUDI_MAX_STRING_LEN] = {
| ^~
This variable is not used so remove it.
Signed-off-by: Tom Rix
---
drivers/accel/habanalabs/gaudi/gaudi.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/accel/habanalabs/gaudi/gaudi.c
b/drivers/accel/habanalabs/gaudi/gaudi.c
index a29aa8f7b6f3..a1697581c218 100644
--- a/drivers/accel/habanalabs/gaudi/gaudi.c
+++ b/drivers/accel/habanalabs/gaudi/gaudi.c
@@ -114,13 +114,6 @@ static u32
gaudi_stream_master[GAUDI_STREAM_MASTER_ARR_SIZE] = {
GAUDI_QUEUE_ID_DMA_1_3
};
-static const char gaudi_irq_name[GAUDI_MSI_ENTRIES][GAUDI_MAX_STRING_LEN] = {
- "gaudi cq 0_0", "gaudi cq 0_1", "gaudi cq 0_2", "gaudi cq 0_3",
- "gaudi cq 1_0", "gaudi cq 1_1", "gaudi cq 1_2", "gaudi cq 1_3",
- "gaudi cq 5_0", "gaudi cq 5_1", "gaudi cq 5_2", "gaudi cq 5_3",
- "gaudi cpu eq"
-};
-
static const u8 gaudi_dma_assignment[GAUDI_DMA_MAX] = {
[GAUDI_PCI_DMA_1] = GAUDI_ENGINE_ID_DMA_0,
[GAUDI_PCI_DMA_2] = GAUDI_ENGINE_ID_DMA_1,
--
2.27.0
Re: [PATCH -next] drm/nouveau/disp: make gv100_disp_core_mthd_base static
Reviewed-by: Karol Herbst
On Sat, Sep 24, 2022 at 10:00 AM ruanjinjie wrote:
>
> The symbol is not used outside of the file, so mark it static.
>
> Fixes the following warning:
>
> ./drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:591:1: warning:
> symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static?
>
> Signed-off-by: ruanjinjie
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> index 6b9d49270fa7..347c12a1fcb7 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c
> @@ -587,7 +587,7 @@ gv100_disp_curs = {
> .user = 73,
> };
>
> -const struct nvkm_disp_mthd_list
> +static const struct nvkm_disp_mthd_list
> gv100_disp_core_mthd_base = {
> .mthd = 0x,
> .addr = 0x00,
> --
> 2.25.1
>
Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans
On Tue, Apr 11, 2023 at 11:02:55AM +0200, Christian König wrote: > The point is that this not only requires some work in the drm_scheduler, but > rather it then makes only little sense to use the drm_scheduler in the first > place. > > The whole point of the drm_scheduler is to provide dma_fence implementation > for the submitted jobs. > > We also have dependency handling, but as Daniel and I said this can be > easily extracted into a separate object/component. Uh that's not what I meant. My take is that minimally patching drm/sched to make the out-fence either optional, or complete it right away, is the simplest way to get at the dependency handling. For me at least the major part of drm/sched is the dep handling and timeout stuff. And the later can be reused with some glue to handle preempt timeouts too and other things, since tdr is a work struct you can just issue any other gpu timeouts on the same workqueue and using the roughly same pattern as the ->timed_out hook and it'll just work. The entire "oh we also make sure your hw fence doesn't leak into public fences and causes lifetime mayhem" seems pretty minor. And maybe also something we want to replicate for the preempt-ctx dma_fence that some long-running context need (but more as part of drm_sched_entity I guess). We can of course bikeshed how much flexibility really should be in the different parts of drm/sched, but imo that's a bikeshed. -Daniel > > Regards, > Christian. > > Am 07.04.23 um 02:20 schrieb Zeng, Oak: > > So this series basically go with option 2. The part that option2 makes me > > uncomfortable is, dma-fence doesn't work for long running workload, why we > > generate it in the first place? As long as dma-fence is generated, it will > > become a source of confusion in the future. It doesn't matter how much you > > annotate it/document it. So if we decide to go with option2, the bottom > > line is, don't generate dma-fence for long running workload during job > > submission. This requires some rework in drm scheduler. > > > > The cleanest solution to me is option3. Dma-fence is a very old technology. > > When it was created, no gpu support page fault. Obviously this is not a > > good technology for modern gpu with page fault support. I think the best > > way is to create a new scheduler and dependency tracking mechanism works > > for both page fault enabled and page fault disabled context. I think this > > matches what Christian said below. Maybe nobody think this is easy? > > > > Thanks, > > Oak > > > > > -Original Message- > > > From: Brost, Matthew > > > Sent: April 5, 2023 2:53 PM > > > To: Zeng, Oak > > > Cc: Christian König ; Vetter, Daniel > > > ; Thomas Hellström > > > ; dri-devel@lists.freedesktop.org; > > > intel- > > > x...@lists.freedesktop.org; robdcl...@chromium.org; airl...@linux.ie; > > > l...@asahilina.net; boris.brezil...@collabora.com; > > > faith.ekstr...@collabora.com > > > Subject: Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload > > > plans > > > > > > On Wed, Apr 05, 2023 at 12:06:53PM -0600, Zeng, Oak wrote: > > > > Hi, > > > > > > > > Using dma-fence for completion/dependency tracking for long-run > > > workload(more precisely on-demand paging/page fault enabled workload) can > > > cause deadlock. This seems the significant issue here. Other issues such > > > as the > > > drm scheduler completion order implication etc are minors which can be > > > solve > > > inside the framework of drm scheduler. We need to evaluate below paths: > > > > 1) still use drm scheduler for job submission, and use > > > > dma-fence for job > > > completion waiting/dependency tracking. This is solution proposed in this > > > series. > > > Annotate dma-fence for long-run workload: user can still wait dma-fence > > > for job > > > completion but can't wait dma-fence while holding any memory management > > > locks. We still use dma-fence for dependency tracking. But it is just > > > very easily > > > run into deadlock when on-demand paging is in the picture. The annotation > > > helps > > > us to detect deadlock but not solve deadlock problems. Seems *not* a > > > complete > > > solution: It is almost impossible to completely avoid dependency deadlock > > > in > > > complex runtime environment > > > No one can wait on LR fence, so it is impossible to deadlock. The > > > annotations enforce this. Literally this is only for flow controling the > > > ring / hold pending jobs in in the DRM schedule list. > > > > > > > 2) Still use drm scheduler but not use dma-fence for completion > > > > signaling > > > and dependency tracking. This way we still get some free functions > > > (reset, err > > > handling ring flow control as Matt said)from drm scheduler, but push the > > > dependency/completion tracking completely to user space using techniques > > > such > > > as user space fence. User space doesn't have chance to wait fence while > > > holding > > > a kerne
Re: [PATCH] fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
On Tue, Apr 11, 2023 at 04:03:24PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> > restore") - I failed to realize that nasty userspace could set this.
> >
> > It's not pretty to mix up kernel-internal and userspace uapi flags
> > like this, but since the entire fb_var_screeninfo structure is uapi
> > we'd need to either add a new parameter to the ->fb_set_par callback
> > and fb_set_par() function, which has a _lot_ of users. Or some other
> > fairly ugly side-channel int fb_info. Neither is a pretty prospect.
> >
> > Instead just correct the issue at hand by filtering out this
> > kernel-internal flag in the ioctl handling code.
> >
> > Signed-off-by: Daniel Vetter
> > Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
>
> [..]
>
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 875541ff185b..3fd95a79e4c3 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info,
> > unsigned int cmd,
> > case FBIOPUT_VSCREENINFO:
> > if (copy_from_user(&var, argp, sizeof(var)))
> > return -EFAULT;
> > + /* only for kernel-internal use */
> > + var.activate &= ~FB_ACTIVATE_KD_TEXT;
> > console_lock();
>
> I don't have a better idea on how to fix this and as you said the whole
> struct fb_var_screeninfo is an uAPI anyways...
>
> Reviewed-by: Javier Martinez Canillas
Thanks for taking a look, merged to drm-misc-fixes.
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] dt-bindings: display/msm: dsi-controller-main: Document qcom, master-dsi and qcom, sync-dual-dsi
This fixes warning:
sm8250-xiaomi-elish-csot.dtb: dsi@ae94000: Unevaluated properties are not
allowed ('qcom,master-dsi', 'qcom,sync-dual-dsi' were unexpected)
Signed-off-by: Jianhua Lu
---
.../bindings/display/msm/dsi-controller-main.yaml| 12
1 file changed, 12 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index e6c1ebfe8a32..940a506a289d 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -82,6 +82,18 @@ properties:
Indicates if the DSI controller is driving a panel which needs
2 DSI links.
+ qcom,master-dsi:
+type: boolean
+description: |
+ Indicates if the DSI controller is the master DSI controller when
+ qcom,dual-dsi-mode enabled.
+
+ qcom,sync-dual-dsi:
+type: boolean
+description: |
+ Indicates if the DSI controller need to sync the other DSI controller
+ with MIPI DCS commands when qcom,dual-dsi-mode enabled.
+
assigned-clocks:
minItems: 2
maxItems: 4
--
2.39.2
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On Tue, Apr 11, 2023 at 08:39:00AM +0200, Das, Nirmoy wrote:
>
> On 3/8/2023 10:41 AM, Andi Shyti wrote:
> > Currently, when we perform operations such as clearing or copying
> > large blocks of memory, we generate multiple requests that are
> > executed in a chain.
> >
> > However, if one of these requests fails, we may not realize it
> > unless it happens to be the last request in the chain. This is
> > because errors are not properly propagated.
> >
> > For this we need to keep propagating the chain of fence
> > notification in order to always reach the final fence associated
> > to the final request.
> >
> > To address this issue, we need to ensure that the chain of fence
> > notifications is always propagated so that we can reach the final
> > fence associated with the last request. By doing so, we will be
> > able to detect any memory operation failures and determine
> > whether the memory is still invalid.
> >
> > On copy and clear migration signal fences upon completion.
> >
> > On copy and clear migration, signal fences upon request
> > completion to ensure that we have a reliable perpetuation of the
> > operation outcome.
> >
> > Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
> > Reported-by: Matthew Auld
> > Suggested-by: Chris Wilson
> > Signed-off-by: Andi Shyti
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Matthew Auld
> With Matt's comment regarding missing lock in intel_context_migrate_clear
> addressed, this is:
>
> Acked-by: Nirmoy Das
Nack!
Please get some ack from Joonas or Tvrtko before merging this series.
It is a big series targeting stable o.O where the revisions in the cover
letter are not helping me to be confident that this is the right approach
instead of simply reverting the original offending commit:
cf586021642d ("drm/i915/gt: Pipelined page migration")
It looks to me that we are adding magic on top of magic to workaround
the deadlocks, but then adding more waits inside locks... And this with
the hang checks vs heartbeats, is this really an issue on current upstream
code? or was only on DII?
Where was the bug report to start with?
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_migrate.c | 41 ++---
> > 1 file changed, 30 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > index 3f638f1987968..0031e7b1b4704 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > @@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce,
> > dst_offset = 2 * CHUNK_SZ;
> > }
> > + /*
> > +* While building the chain of requests, we need to ensure
> > +* that no one can sneak into the timeline unnoticed.
> > +*/
> > + mutex_lock(&ce->timeline->mutex);
> > +
> > do {
> > int len;
> > - rq = i915_request_create(ce);
> > + rq = i915_request_create_locked(ce);
> > if (IS_ERR(rq)) {
> > err = PTR_ERR(rq);
> > - goto out_ce;
> > + break;
> > }
> > if (deps) {
> > @@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,
> > /* Arbitration is re-enabled between requests. */
> > out_rq:
> > - if (*out)
> > + i915_sw_fence_await(&rq->submit);
> > + i915_request_get(rq);
> > + i915_request_add_locked(rq);
> > + if (*out) {
> > + i915_sw_fence_complete(&(*out)->submit);
> > i915_request_put(*out);
> > - *out = i915_request_get(rq);
> > - i915_request_add(rq);
> > + }
> > + *out = rq;
> > if (err)
> > break;
> > @@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
> > cond_resched();
> > } while (1);
> > -out_ce:
> > + mutex_unlock(&ce->timeline->mutex);
> > +
> > + if (*out)
> > + i915_sw_fence_complete(&(*out)->submit);
> > return err;
> > }
> > @@ -1005,7 +1018,7 @@ intel_context_migrate_clear(struct intel_context *ce,
> > rq = i915_request_create(ce);
> > if (IS_ERR(rq)) {
> > err = PTR_ERR(rq);
> > - goto out_ce;
> > + break;
> > }
> > if (deps) {
> > @@ -1056,17 +1069,23 @@ intel_context_migrate_clear(struct intel_context
> > *ce,
> > /* Arbitration is re-enabled between requests. */
> > out_rq:
> > - if (*out)
> > - i915_request_put(*out);
> > - *out = i915_request_get(rq);
> > + i915_sw_fence_await(&rq->submit);
> > + i915_request_get(rq);
> > i915_request_add(rq);
> > + if (*out) {
> > + i915_sw_fence_complete(&(*out)->submit);
> > + i915_re
Re: [PATCH v5 2/9] video/aperture: use generic code to figure out the vga default device
On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
> On 4/6/23 15:21, Thomas Zimmermann wrote:
> > From: Daniel Vetter
> >
> > Since vgaarb has been promoted to be a core piece of the pci subsystem
> > we don't have to open code random guesses anymore, we actually know
> > this in a platform agnostic way, and there's no need for an x86
> > specific hack. See also commit 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
> > drivers/pci")
> >
> > This should not result in any functional change, and the non-x86
> > multi-gpu pci systems are probably rare enough to not matter (I don't
> > know of any tbh). But it's a nice cleanup, so let's do it.
> >
> > There's been a few questions on previous iterations on dri-devel and
> > irc:
> >
> > - fb_is_primary_device() seems to be yet another implementation of
> >this theme, and at least on x86 it checks for both
> >vga_default_device OR rom shadowing. There shouldn't ever be a case
> >where rom shadowing gives any additional hints about the boot vga
> >device, but if there is then the default vga selection in vgaarb
> >should probably be fixed. And not special-case checks replicated all
> >over.
> >
> > - Thomas also brought up that on most !x86 systems
> >fb_is_primary_device() returns 0, except on sparc/parisc. But these
> >2 special cases are about platform specific devices and not pci, so
> >shouldn't have any interactions.
>
> Nearly all graphics cards on parisc machines are actually PCI cards,
> but the way we handle the handover to graphics mode with STIcore doesn't
> conflicts with your planned aperture changes.
> So no problem as far as I can see for parisc...
Ah I thought sticore was some very special bus, if those can be pci cards
underneath then I guess some cleanup eventually might be a good idea? For
anything with a pci bus it's rather strange when vgaarb and
fb_is_primary_device() aren't a match ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 1/2] drm: Spelling s/sempahore/semaphore/
On 4/11/23 06:52, Geert Uytterhoeven wrote: Fix misspellings of "semaphore". Signed-off-by: Geert Uytterhoeven Series is Reviewed-by: Hamza Mahfooz --- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/radeon/cik.c| 2 +- drivers/gpu/drm/radeon/r600.c | 2 +- include/drm/task_barrier.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 630a732aaecca8fb..0bb368a5dd0bb107 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1220,7 +1220,7 @@ emit_semaphore_wait(struct i915_request *to, /* * If this or its dependents are waiting on an external fence * that may fail catastrophically, then we want to avoid using -* sempahores as they bypass the fence signaling metadata, and we +* semaphores as they bypass the fence signaling metadata, and we * lose the fence->error propagation. */ if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 5819737c21c678d3..5d6b81a6578ef2ba 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -3603,7 +3603,7 @@ void cik_fence_compute_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index dd78fc4994024815..34457e51035278fb 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -2918,7 +2918,7 @@ void r600_fence_ring_emit(struct radeon_device *rdev, * @rdev: radeon_device pointer * @ring: radeon ring buffer object * @semaphore: radeon semaphore object - * @emit_wait: Is this a sempahore wait? + * @emit_wait: Is this a semaphore wait? * * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP * from running ahead of semaphore waits. diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h index 087e3f649c52f02d..217c1cf21c1ab7d5 100644 --- a/include/drm/task_barrier.h +++ b/include/drm/task_barrier.h @@ -25,7 +25,7 @@ /* * Reusable 2 PHASE task barrier (randevouz point) implementation for N tasks. - * Based on the Little book of sempahores - https://greenteapress.com/wp/semaphores/ + * Based on the Little book of semaphores - https://greenteapress.com/wp/semaphores/ */ -- Hamza
Re: [PATCH 0/2] Add support for dumping error captures via kernel logging
On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > Sometimes, the only effective way to debug an issue is to dump all the > interesting information at the point of failure. So add support for > doing that. No! Please no! We have some of this on Xe and I'm hating it. I'm going to try to remove from there soon. It is horrible when you lost the hability to use dmesg directly because it goes over the number of lines it saves... or even with dmesg -w it goes over the number of lines of your terminal... or the ssh and serial slowness when printing a bunch of information. We probably want to be able to capture multiple error states and be able to cross them with a kernel timeline, but definitely not overflood our log terminals. > > Signed-off-by: John Harrison > > > John Harrison (2): > drm/i915: Dump error capture to kernel log > drm/i915/guc: Dump error capture to dmesg on CTB error > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 + > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 + > drivers/gpu/drm/i915/i915_gpu_error.c | 130 ++ > drivers/gpu/drm/i915/i915_gpu_error.h | 8 ++ > 4 files changed, 197 insertions(+) > > -- > 2.39.1 >
Re: [PATCH] drm/drm_plane.h: fix grammar of the comment
On Sun, Apr 09, 2023 at 09:15:47PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Signed-off-by: Sui Jingfeng
Applied to drm-misc-next, thanks
> ---
> include/drm/drm_plane.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 51291983ea44..79d62856defb 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -56,7 +56,7 @@ struct drm_plane_state {
> /**
>* @crtc:
>*
> - * Currently bound CRTC, NULL if disabled. Do not this write directly,
> + * Currently bound CRTC, NULL if disabled. Do not write this directly,
>* use drm_atomic_set_crtc_for_plane()
>*/
> struct drm_crtc *crtc;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/5] drm/amdgpu: Move a variable assignment behind a null pointer check in amdgpu_ras_interrupt_dispatch()
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> @@ -1730,11 +1730,12 @@ int amdgpu_ras_interrupt_dispatch(struct
>> amdgpu_device *adev,
>> struct ras_dispatch_if *info)
>> {
>> struct ras_manager *obj = amdgpu_ras_find_obj(adev, &info->head);
>> - struct ras_ih_data *data = &obj->ih_data;
>> + struct ras_ih_data *data;
> I'm curious, this only takes the address of obj->ih_data.
Even if a null pointer would accidentally be returned by a call of
the function “amdgpu_ras_find_obj”?
https://elixir.bootlin.com/linux/v6.3-rc6/source/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c#L618
> It doesn't dereference the pointer until after the !obj check below.
Does the used arrow operator indicate a pointer dereference?
> How is this undefined behaviour?
I guess that another information source can be helpful for such an issue.
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers?focusedCommentId=405504153#comment-405504153
Regards,
Markus
Re: [PATCH] drm/amd/pm: remove unused num_of_active_display variable
Applied. Thanks!
On Sun, Apr 9, 2023 at 8:48 PM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Evan Quan
>
> > -Original Message-
> > From: Tom Rix
> > Sent: Saturday, April 1, 2023 12:41 AM
> > To: Quan, Evan ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ;
> > airl...@gmail.com; dan...@ffwll.ch; nat...@kernel.org;
> > ndesaulni...@google.com; Zhang, Hawking ;
> > Feng, Kenneth ; Lazar, Lijo
> > ; Wang, Yang(Kevin) ;
> > Huang, Tim ; andrealm...@igalia.com; Liu, Kun
> > ; Limonciello, Mario
> > Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> > ker...@vger.kernel.org; l...@lists.linux.dev; Tom Rix
> > Subject: [PATCH] drm/amd/pm: remove unused num_of_active_display
> > variable
> >
> > clang with W=1 reports
> > drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:1700:6: error:
> > variable
> > 'num_of_active_display' set but not used [-Werror,-Wunused-but-set-
> > variable]
> > int num_of_active_display = 0;
> > ^
> > This variable is not used so remove it.
> >
> > Signed-off-by: Tom Rix
> > ---
> > drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 ---
> > 1 file changed, 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > index b5d64749990e..f93f7a9ed631 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > @@ -1696,8 +1696,6 @@ static int smu_display_configuration_change(void
> > *handle,
> > const struct
> > amd_pp_display_configuration *display_config) {
> > struct smu_context *smu = handle;
> > - int index = 0;
> > - int num_of_active_display = 0;
> >
> > if (!smu->pm_enabled || !smu->adev->pm.dpm_enabled)
> > return -EOPNOTSUPP;
> > @@ -1708,11 +1706,6 @@ static int smu_display_configuration_change(void
> > *handle,
> > smu_set_min_dcef_deep_sleep(smu,
> > display_config-
> > >min_dcef_deep_sleep_set_clk / 100);
> >
> > - for (index = 0; index < display_config-
> > >num_path_including_non_display; index++) {
> > - if (display_config->displays[index].controller_id != 0)
> > - num_of_active_display++;
> > - }
> > -
> > return 0;
> > }
> >
> > --
> > 2.27.0
Re: [PATCH] drm/fbdev-generic: fix potential out-of-bounds access
On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> We should setting the screen buffer size according to the screen's actual
> size, rather than the size of the GEM object backing the front framebuffer.
> The size of GEM buffer is page size aligned, while the size of active area
> of a specific screen is *NOT* necessarily page size aliged. For example,
> 1680x1050, 1600x900, 1440x900, 800x6000 etc. In those case, the damage rect
> computed by drm_fb_helper_memory_range_to_clip() goes out of bottom bounds
> of the display.
>
> Run fbdev test of IGT on a x86+ast2400 platform with 1680x1050 resolution
> will cause the system hang with the following call trace:
>
> Oops: [#1] PREEMPT SMP PTI
> [IGT] fbdev: starting subtest eof
> Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]
> [IGT] fbdev: starting subtest nullptr
>
> RIP: 0010:memcpy_erms+0xa/0x20
> RSP: 0018:a17d40167d98 EFLAGS: 00010246
> RAX: a17d4eb7fa80 RBX: a17d40e0aa80 RCX: 14c0
> RDX: 1a40 RSI: a17d40e0b000 RDI: a17d4eb8
> RBP: a17d40167e20 R08: R09: 89522ecff8c0
> R10: a17d4e4c5000 R11: R12: a17d4eb7fa80
> R13: 1a40 R14: 041a R15: a17d40167e30
> FS: () GS:89525738() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: a17d40e0b000 CR3: 0001eaeca006 CR4: 001706e0
> Call Trace:
>
>? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]
>drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]
>process_one_work+0x21f/0x430
>worker_thread+0x4e/0x3c0
>? __pfx_worker_thread+0x10/0x10
>kthread+0xf4/0x120
>? __pfx_kthread+0x10/0x10
>ret_from_fork+0x2c/0x50
>
> CR2: a17d40e0b000
> ---[ end trace ]---
>
> We also add trival code in this patch to restrict the damage rect beyond
> the last line of the framebuffer.
Nice catch!
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> drivers/gpu/drm/drm_fbdev_generic.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64458982be40..a2b749372759 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -645,7 +645,7 @@ static void drm_fb_helper_memory_range_to_clip(struct
> fb_info *info, off_t off,
> u32 x1 = 0;
> u32 y1 = off / info->fix.line_length;
> u32 x2 = info->var.xres;
> - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
> + u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length),
> info->var.yres);
So for additional robustness I think it'd be good if we change the entire
computation here to use drm_framebuffer data and not fb_info data, because
fundamentally that's what the drm kms code consumes. It should all match
anyway, but I think it makes the code more obviously correct.
So in the entire function instead of looking at fb_info->fix we should
probably look at
struct drm_fb_helper *helper = info->par;
And then helper->fb->pitches[0] and helper->fb->height.
If you agree would be great if you can please respin with that (and the
commit message augmented to explain why we do the change)?
>
> if ((y2 - y1) == 1) {
> /*
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 8e5148bf40bb..a6daecb5f640 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -95,6 +95,8 @@ static int drm_fbdev_generic_helper_fb_probe(struct
> drm_fb_helper *fb_helper,
> fb_helper->fb = buffer->fb;
>
> screen_size = buffer->gem->size;
I guess you forgot to remove this line here? Also I'm not understanding
why this matters, I think you're fix only needs the above chunk, not this
one? If I got this right then please drop this part, there's drivers which
only use drm_fb_helper.c but not drm_fbdev_generic.c, and from what I can
tell they all still set the gem buffer size here.
If otoh we need this too, then there's a few more places that need to be
fixed.
> + screen_size = sizes->surface_height * buffer->fb->pitches[0];
> +
> screen_buffer = vzalloc(screen_size);
> if (!screen_buffer) {
> ret = -ENOMEM;
Cheers, Daniel
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [pull] drm/msm: drm-msm-next-2023-04-10 for v6.4
On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote: > > On Mon, Apr 10, 2023 at 07:50:50AM -0700, Rob Clark wrote: > > Hi Dave, > > > > This is the main pull for v6.4, see below for description. A bit big > > this time because of (1) generated header updates and (2) dpu hw > > catelog rework which split the increasingly unwieldy > > big-giant-file-of-tables into per-SoC files. But those are mainly > > mechanical churn. > > > > The following changes since commit e752ab11dcb48353727ea26eefd740155e028865: > > > > Merge remote-tracking branch 'drm/drm-next' into msm-next > > (2023-03-20 10:31:25 -0700) > > > > are available in the Git repository at: > > > > https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2023-04-10 > > > > for you to fetch changes up to ac7e7c9c65ecfb1fcc99de91cfd6b17a8d4cb9c1: > > > > drm/msm/dpu: drop unused macros from hw catalog (2023-04-07 03:54:50 > > +0300) > > Pulled, thanks. > > Two comments below. > > > > > > > main pull request for v6.4 > > > > Core Display: > > > > * Bugfixes for error handling during probe > > * rework UBWC decoder programming > > * prepare_commit cleanup > > * bindings for SM8550 (MDSS, DPU), SM8450 (DP) > > * timeout calculation fixup > > * atomic: use drm_crtc_next_vblank_start() instead of our own > > custom thing to calculate the start of next vblank > > > > DP: > > == > > * interrupts cleanup > > > > DPU: > > === > > * DSPP sub-block flush on sc7280 > > * support AR30 in addition to XR30 format > > * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes > > * Split the HW catalog into individual per-SoC files > > > > DSI: > > === > > * rework DSI instance ID detection on obscure platforms > > > > GPU: > > === > > * uapi C++ compatibility fix > > * a6xx: More robust gdsc reset > > * a3xx and a4xx devfreq support > > * update generated headers > > * various cleanups and fixes > > * GPU and GEM updates to avoid allocations which could trigger > > reclaim (shrinker) in fence signaling path > > dim complained about a pile of commits without 2nd eyes, and it was mostly > this. I think especially for these tricky locking/reclaim issues having a > bus factor > 1 would be really good. I'll try and brush of my anotations, > hopefully we can have a bit more cross-driver discussions and reviews > going here, iirc when Boris did the timed_out annotations for panfrost he > didn't fix all the splats, so that's perfect candidate to help push the > remaining work. Fwiw, that was at least all tested with sched fence signaling annotations, so tested-by: lockdep ;-) Unfortunately we can't enable the annotations yet because of various fixes needed in pm and icc. But I'll resend that series with the remaining outstanding patches after the merge window. > > * dma-fence deadline hint support and wait-boost > > * a640 speedbin support > > * a650 speedbin support > > > > > > Abhinav Kumar (3): > > MAINTAINERS: Update the URI for MSM DRM bugs > > drm/msm/dpu: log the multirect_index in _dpu_crtc_blend_setup_pipe > > drm/msm/dpu: remove unused dpu_plane_validate_multirect_v2 function > > > > Adam Skladowski (1): > > drm: msm: adreno: Disable preemption on Adreno 510 > > > > Akhil P Oommen (3): > > drm/msm/a6xx: Vote for cx gdsc from gpu driver > > drm/msm/a6xx: Remove cx gdsc polling using 'reset' > > drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse > > > > Arnd Bergmann (1): > > drm/msm/a6xx: add CONFIG_PM dependency > > > > Colin Ian King (2): > > drm/msm/mdss: Fix spelling mistake "Unuspported" -> "Unsupported" > > drm/msm/dp: Fix spelling mistake "Capabiity" -> "Capability" > > > > Danylo Piliaiev (1): > > drm/msm: Rename drm_msm_gem_submit_reloc::or in C++ code > > > > Dmitry Baryshkov (67): > > drm/msm/adreno: stall translation on fault for all GPU families > > drm/msm/adreno: split a6xx fault handler into generic and a6xx parts > > drm/msm/a5xx: add devcoredump support to the fault handler > > drm/msm/mdss: convert UBWC setup to use match data > > drm/msm/mdss: add data for sc8180xp > > drm/msm/mdss: add the sdm845 data for completeness > > drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg) > > drm/msm/dpu: move SSPP allocation to the RM > > drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c > > drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout > > drm/msm/dpu: move pipe_hw to dpu_plane_state > > drm/msm/dpu: drop dpu_plane_pipe function > > drm/msm/dpu: introduce struct dpu_sw_pipe > > drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks > > drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() > > drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid > > fill > > drm/msm/d
