Re: [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails
Hi Lyude, Thank you for the reviews. On 5/18/22 19:39, Lyude Paul wrote: > On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote: >> Typically the acpi_video driver will initialize before nouveau, which >> used to cause /sys/class/backlight/acpi_video0 to get registered and then >> nouveau would register its own nv_backlight device later. After which >> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device >> to avoid there being 2 backlight devices. >> >> This means that userspace used to briefly see 2 devices and the >> disappearing of acpi_video0 after a brief time confuses the systemd >> backlight level save/restore code, see e.g.: >> https://bbs.archlinux.org/viewtopic.php?id=269920 >> >> To fix this the ACPI video code has been modified to make backlight class >> device registration a separate step, relying on the drm/kms driver to >> ask for the acpi_video backlight registration after it is done setting up >> its native backlight device. >> >> Add a call to the new acpi_video_register_backlight() when native backlight >> device registration has failed / was skipped to ensure that there is a >> backlight device available before the drm_device gets registered with >> userspace. >> >> Signed-off-by: Hans de Goede >> --- >> drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c >> b/drivers/gpu/drm/nouveau/nouveau_backlight.c >> index f56ff797c78c..0ae8793357a4 100644 >> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c >> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c >> @@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector) >> >> fail_alloc: >> kfree(bl); >> + /* >> + * If we get here we have an internal panel, but no nv_backlight, >> + * try registering an ACPI video backlight device instead. >> + */ >> + if (ret == 0) >> + acpi_video_register_backlight(); > > Assuming we don't need to return the value of acpi_video_register_backlight() > here: The function return type is void, so no return value to check :) > > Reviewed-by: Lyude Paul > >> + >> return ret; >> } >> >
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, Jun 01, 2022 at 10:08:35PM -0700, Niranjana Vishwanathapura wrote:
On Wed, Jun 01, 2022 at 11:27:17AM +0200, Daniel Vetter wrote:
On Wed, 1 Jun 2022 at 11:03, Dave Airlie wrote:
On Tue, 24 May 2022 at 05:20, Niranjana Vishwanathapura
wrote:
On Thu, May 19, 2022 at 04:07:30PM -0700, Zanoni, Paulo R wrote:
>On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
>> VM_BIND and related uapi definitions
>>
>> v2: Ensure proper kernel-doc formatting with cross references.
>> Also add new uapi and documentation as per review comments
>> from Daniel.
>>
>> Signed-off-by: Niranjana Vishwanathapura
>> ---
>> Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
>> 1 file changed, 399 insertions(+)
>> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>>
>> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
>> new file mode 100644
>> index ..589c0a009107
>> --- /dev/null
>> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
>> @@ -0,0 +1,399 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2022 Intel Corporation
>> + */
>> +
>> +/**
>> + * DOC: I915_PARAM_HAS_VM_BIND
>> + *
>> + * VM_BIND feature availability.
>> + * See typedef drm_i915_getparam_t param.
>> + */
>> +#define I915_PARAM_HAS_VM_BIND 57
>> +
>> +/**
>> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
>> + *
>> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
>> + * See struct drm_i915_gem_vm_control flags.
>> + *
>> + * A VM in VM_BIND mode will not support the older execbuff mode of binding.
>> + * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
>> + * &drm_i915_gem_execbuffer2.buffer_count must be 0).
>> + * Also, &drm_i915_gem_execbuffer2.batch_start_offset and
>> + * &drm_i915_gem_execbuffer2.batch_len must be 0.
>> + * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
>> + * to pass in the batch buffer addresses.
>> + *
>> + * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
>> + * I915_EXEC_BATCH_FIRST of &drm_i915_gem_execbuffer2.flags must be 0
>> + * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always be
>> + * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
>> + * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
>> + * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
>> + */
>
>From that description, it seems we have:
>
>struct drm_i915_gem_execbuffer2 {
>__u64 buffers_ptr; -> must be 0 (new)
>__u32 buffer_count; -> must be 0 (new)
>__u32 batch_start_offset; -> must be 0 (new)
>__u32 batch_len;-> must be 0 (new)
>__u32 DR1; -> must be 0 (old)
>__u32 DR4; -> must be 0 (old)
>__u32 num_cliprects; (fences) -> must be 0 since using extensions
>__u64 cliprects_ptr; (fences, extensions) -> contains an actual
pointer!
>__u64 flags;-> some flags must be 0 (new)
>__u64 rsvd1; (context info) -> repurposed field (old)
>__u64 rsvd2;-> unused
>};
>
>Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
>of adding even more complexity to an already abused interface? While
>the Vulkan-like extension thing is really nice, I don't think what
>we're doing here is extending the ioctl usage, we're completely
>changing how the base struct should be interpreted based on how the VM
>was created (which is an entirely different ioctl).
>
>From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
>already at -6 without these changes. I think after vm_bind we'll need
>to create a -11 entry just to deal with this ioctl.
>
The only change here is removing the execlist support for VM_BIND
mode (other than natual extensions).
Adding a new execbuffer3 was considered, but I think we need to be careful
with that as that goes beyond the VM_BIND support, including any future
requirements (as we don't want an execbuffer4 after VM_BIND).
Why not? it's not like adding extensions here is really that different
than adding new ioctls.
I definitely think this deserves an execbuffer3 without even
considering future requirements. Just to burn down the old
requirements and pointless fields.
Make execbuffer3 be vm bind only, no relocs, no legacy bits, leave the
older sw on execbuf2 for ever.
I guess another point in favour of execbuf3 would be that it's less
midlayer. If we share the entry point then there's quite a few vfuncs
needed to cleanly split out the vm_bind paths from the legacy
reloc/softping paths.
If we invert this and do execbuf3, then there's the existing ioctl
vfunc, and then we share code (where it even makes sense, probably
request setup/submit need to be shared, anything else is probably
cleaner to just copypaste) with the usual helper approach
Re: [PATCH v2 0/8] Add a panel API to return panel orientation
Hi, On 6/2/22 23:48, Doug Anderson wrote: > Hi, > > On Wed, Jun 1, 2022 at 2:46 AM Hsin-Yi Wang wrote: >> >> Panels usually call drm_connector_set_panel_orientation(), which is >> later than drm/kms driver calling drm_dev_register(). This leads to a >> WARN()[1]. >> >> The orientation property is known earlier. For example, some panels >> parse the property through device tree during probe. >> >> The series add a panel API drm_panel_get_orientation() for drm/kms >> drivers. The drivers can use the API to get panel's orientation, so they >> can call drm_connector_set_panel_orientation() before drm_dev_register(). >> >> Panel needs to implement .get_orientation callback to return the property. >> >> [1] >> https://patchwork.kernel.org/project/linux-mediatek/patch/20220530081910.3947168-2-hsi...@chromium.org/ >> >> Hsin-Yi Wang (8): >> drm/panel: Add an API drm_panel_get_orientation() to return panel >> orientation >> drm/panel: boe-tv101wum-nl6: Implement .get_orientation callback >> drm/panel: panel-edp: Implement .get_orientation callback >> drm/panel: lvds: Implement .get_orientation callback >> drm/panel: panel-simple: Implement .get_orientation callback >> drm/panel: ili9881c: Implement .get_orientation callback >> drm/panel: elida-kd35t133: Implement .get_orientation callback >> drm/mediatek: Config orientation property if panel provides it >> >> drivers/gpu/drm/drm_panel.c| 8 >> drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++ >> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8 >> drivers/gpu/drm/panel/panel-edp.c | 8 >> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 >> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 >> drivers/gpu/drm/panel/panel-lvds.c | 8 >> drivers/gpu/drm/panel/panel-simple.c | 9 + >> include/drm/drm_panel.h| 10 ++ >> 9 files changed, 77 insertions(+) > > Seems reasonable to me. I added a request to the panel-edp patch that > probably applies to all of the panel patches requesting a comment next > to the old calls in get_modes(). > > I assume that all but patch #8 ought to land through drm-misc. I'm > happy to help commit them once everyone is happy. If the Mediatek > maintainer(s) want to Ack patch #8 I can land that in drm-misc too. If > we want something fancier like an immutable branch you'll probably > have to get someone involved that's got a higher drm pay grade than > me. ;-) Thanks, patch 8/8 looks good to me now too, so: Reviewed-by: Hans de Goede for the series. Note I'm currently travelling so I cannot push this to drm-mic-next myself. Regards, Hans
Re: [RESEND 10/14] iio: adc: mt6370: Add Mediatek MT6370 support
Hi Jonathan,
Sorry for sending the same email again. I miss to reply all in the last email..
Thanks for your valuable suggestions!
Jonathan Cameron 於 2022年5月31日 週二 下午9:21寫道：
>
> On Tue, 31 May 2022 19:18:56 +0800
> ChiaEn Wu wrote:
>
> > From: ChiaEn Wu
> >
> > Add Mediatek MT6370 ADC support.
> >
> > Signed-off-by: ChiaEn Wu
>
> Hi ChiaEn,
>
> A few comments inline.
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/Kconfig | 9 ++
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/mt6370-adc.c | 257 +++
> > 3 files changed, 267 insertions(+)
> > create mode 100644 drivers/iio/adc/mt6370-adc.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 71ab0a06aa82..d7932dd9b773 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -737,6 +737,15 @@ config MEDIATEK_MT6360_ADC
> > is used in smartphones and tablets and supports a 11 channel
> > general purpose ADC.
> >
> > +config MEDIATEK_MT6370_ADC
> > + tristate "Mediatek MT6370 ADC driver"
> > + depends on MFD_MT6370
> > + help
> > + Say Y here to enable MT6370 ADC support.
> > + Integrated for System Monitoring includes
>
> The wrapping of this text needs cleaning up.
>
> > + is used in smartphones and tablets and supports a 9 channel
> > + general purpose ADC.
> > +
> > config MEDIATEK_MT6577_AUXADC
> > tristate "MediaTek AUXADC driver"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 39d806f6d457..0ce285c7e2d0 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> > obj-$(CONFIG_MCP3422) += mcp3422.o
> > obj-$(CONFIG_MCP3911) += mcp3911.o
> > obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> > +obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
> > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> > diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c
> > new file mode 100644
> > index ..3320ebca17ad
> > --- /dev/null
> > +++ b/drivers/iio/adc/mt6370-adc.c
> > @@ -0,0 +1,257 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Not seeing any interrupt support in here.
Sorry for that I forgot remove this line, I'll refine it in the next patch.
>
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MT6370_REG_CHG_CTRL3 0x113 /* AICR */
> > +#define MT6370_REG_CHG_CTRL7 0x117 /* ICHG */
> > +#define MT6370_REG_CHG_ADC 0x121
> > +#define MT6370_REG_ADC_DATA_H0x14C
> > +
> > +#define MT6370_ADC_START_MASKBIT(0)
> > +#define MT6370_ADC_IN_SEL_MASK GENMASK(7, 4)
> > +#define MT6370_AICR_ICHG_MASKGENMASK(7, 2)
> > +
> > +#define MT6370_ADC_CHAN_SHIFT4
>
> Prefer using a mask and then FIELD_PREP
OK, I got it!
>
> > +
> > +#define MT6370_AICR_400MA0x6
> > +#define MT6370_ICHG_500MA0x4
> > +#define MT6370_ICHG_900MA0x8
> > +
> > +#define ADC_CONV_TIME_US 35000
> > +#define ADC_CONV_POLLING_TIME1000
> > +
> > +struct mt6370_adc_data {
> > + struct device *dev;
> > + struct regmap *regmap;
> > + struct mutex lock;
>
> All locks need documentation. What is the scope of the lock?
> Looks like it protects device state when doing setup, wait for read, read
> cycles.
This mutex lock is for preventing the different adc channel from being
read at the same time.
So, if I just change its name to adc_chan_lock or adc_lock and add the
comment for this mutex lock, does this change meet your requirement?
>
> > +};
> > +
> > +static int mt6370_adc_read_channel(struct mt6370_adc_data *priv, int chan,
> > +unsigned long addr, int *val)
> > +{
> > + __be16 be_val;
> > + unsigned int reg_val;
> > + int ret;
> > +
> > + mutex_lock(&priv->lock);
> > +
> > + reg_val = MT6370_ADC_START_MASK | (addr << MT6370_ADC_CHAN_SHIFT);
>
> FIELD_PREP for that shift?
I got it! I'll refine it in the next patch.
>
> > + ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, reg_val);
> > + if (ret)
> > + goto adc_unlock;
> > +
> > + msleep(ADC_CONV_TIME_US / 1000);
> > +
> > + ret = regmap_read_poll_timeout(priv->regmap,
> > +MT6370_REG_CHG_ADC, reg_val,
> > +!(reg_val & MT6370_ADC_START_MASK),
> > +ADC_CONV_POLLING_TIME,
> > +ADC_CONV_TIME_US * 3);
> > + if (ret) {
> > + if (ret == -ETIMED
Re: [RESEND 14/14] video: backlight: mt6370: Add Mediatek MT6370 support
Hi Daniel,
Thanks for your valuable feedback!
Daniel Thompson 於 2022年6月1日 週三 下午5:46寫道：
>
> On Tue, May 31, 2022 at 07:19:00PM +0800, ChiaEn Wu wrote:
> > From: ChiaEn Wu
> >
> > Add Mediatek MT6370 Backlight support.
> >
> > Signed-off-by: ChiaEn Wu
> > ---
> > drivers/video/backlight/Kconfig| 8 +
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/mt6370-backlight.c | 338 +
> > 3 files changed, 347 insertions(+)
> > create mode 100644 drivers/video/backlight/mt6370-backlight.c
> >
> > diff --git a/drivers/video/backlight/Kconfig
> > b/drivers/video/backlight/Kconfig
> > index a003e02e13ce..d9868fbe7488 100644
> > --- a/drivers/video/backlight/Kconfig
> > +++ b/drivers/video/backlight/Kconfig
> > @@ -268,6 +268,14 @@ config BACKLIGHT_MAX8925
> > If you have a LCD backlight connected to the WLED output of MAX8925
> > WLED output, say Y here to enable this driver.
> >
> > +config BACKLIGHT_MT6370
>
> Is MT6370 really the best name for this driver? In other words, you
> don't expect there to be any family resemblance between this backlight
> and the backlight in the *next* Mediatak PMIC?
>
> Moreover,
MT6370, MT6371, MT6372 are very similar, their hardware design and
features are almost the same and this driver can be compatible with
them.
But, MT6374 is not the same serials PMIC as MT6370, but the name is
very similar. And It has no backlight feature, so I think MT6370 is
the best name for this driver now.
>
>
> > + tristate "Mediatek MT6370 Backlight Driver"
> > + depends on MFD_MT6370
> > + help
> > + Say Y here to enable MT6370 Backlight support.
> > + It's commonly used to drive the display WLED. There're 4 channels
> > + inisde, and each channel can provide up to 30mA current.
>
> Nitpicking but this doesn't align well with other help texts in this
> file.
>
OK! I will try to align well in the next patch.
>
> > +
> > config BACKLIGHT_APPLE
> > tristate "Apple Backlight Driver"
> > depends on X86 && ACPI
> > diff --git a/drivers/video/backlight/Makefile
> > b/drivers/video/backlight/Makefile
> > index cae2c83422ae..e815f3f1deff 100644
> > --- a/drivers/video/backlight/Makefile
> > +++ b/drivers/video/backlight/Makefile
> > @@ -44,6 +44,7 @@ obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
> > obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
> > obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
> > obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
> > +obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
> > obj-$(CONFIG_BACKLIGHT_OMAP1)+= omap1_bl.o
> > obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> > obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> > diff --git a/drivers/video/backlight/mt6370-backlight.c
> > b/drivers/video/backlight/mt6370-backlight.c
> > new file mode 100644
> > index ..f8a8d33203ed
> > --- /dev/null
> > +++ b/drivers/video/backlight/mt6370-backlight.c
> > @@ -0,0 +1,338 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MT6370_REG_DEV_INFO 0x100
> > +#define MT6370_REG_BL_EN 0x1A0
> > +#define MT6370_REG_BL_BSTCTRL0x1A1
> > +#define MT6370_REG_BL_PWM0x1A2
> > +#define MT6370_REG_BL_DIM2 0x1A4
> > +
> > +#define MT6370_VENID_MASKGENMASK(7, 4)
> > +#define MT6370_BL_EXT_EN_MASKBIT(7)
> > +#define MT6370_BL_EN_MASKBIT(6)
> > +#define MT6370_BL_CONFIG_MASKBIT(0)
> > +#define MT6370_BL_CH_MASKGENMASK(5, 2)
> > +#define MT6370_BL_DIM2_MASK GENMASK(2, 0)
> > +#define MT6370_BL_DUMMY_6372_MASKGENMASK(2, 0)
> > +#define MT6370_BL_DIM2_6372_SHIFT3
> > +#define MT6370_BL_PWM_EN_MASKBIT(7)
> > +#define MT6370_BL_PWM_HYS_EN_MASKBIT(2)
> > +#define MT6370_BL_PWM_HYS_SEL_MASK GENMASK(1, 0)
> > +#define MT6370_BL_OVP_EN_MASKBIT(7)
> > +#define MT6370_BL_OVP_SEL_MASK GENMASK(6, 5)
> > +#define MT6370_BL_OC_EN_MASK BIT(3)
> > +#define MT6370_BL_OC_SEL_MASKGENMASK(2, 1)
> > +
> > +#define MT6370_BL_MAX_BRIGHTNESS 2048
> > +
> > +enum {
> > + MT6370_VID_COMMON = 0,
> > + MT6370_VID_6372,
> > + MT6370_VID_MAX,
>
> Unused.
>
> > +};
> > +
> > +enum mt6370_prop_type {
> > + MT6370_PARSE_TYPE_BOOL = 0,
> > + MT6370_PARSE_TYPE_U8,
> > + MT6370_PARSE_TYPE_MAX,
>
> Unused.
>
> > +};
> > +
> > +struct mt6370_priv {
> > + int vid_type;
> > + struct backlight_device *bl;
> > + struct device *dev;
> > + struct gpio_desc *enable_gpio;
> > + struct regmap *regmap;
> > +};
> > +
> > +static int mt6370_bl_update_status(struct backlight_device
Re: [PATCH 10/14] dt-bindings: power: supply: Add Mediatek MT6370 Charger binding documentation
Hi Krzysztof, Thank you for the valuable suggestion. Sorry for sending the same email again. I forgot to reply to everyone in my last email.. Krzysztof Kozlowski 於 2022年6月1日 週三 上午4:15寫道： > > On 31/05/2022 12:42, ChiaEn Wu wrote: > > From: ChiaEn Wu > > > > Subject - remove "binding documentation". It's already implied by prefix. > > > Add Mediatek MT6370 Charger binding documentation. > > > > Signed-off-by: ChiaEn Wu > > --- > > .../power/supply/mediatek,mt6370-charger.yaml | 60 +++ > > 1 file changed, 60 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml > > > > b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml > > new file mode 100644 > > index ..9d5c4487ca9c > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml > > @@ -0,0 +1,60 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > > http://devicetree.org/schemas/power/supply/mediatek,mt6370-charger.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Mediatek MT6370 Battery Charger > > + > > +maintainers: > > + - ChiaEn Wu > > + > > +description: | > > + This module is part of the MT6370 MFD device. > > + Provides Battery Charger, Boost for OTG devices and BC1.2 detection. > > + > > +properties: > > + compatible: > > +const: mediatek,mt6370-charger > > + > > + interrupts: > > +description: | > > + Specify what irqs are needed to be handled by MT6370 Charger driver. > > IRQ > > + "MT6370_IRQ_CHG_MIVR", "MT6370_IRQ_ATTACH" and > > "MT6370_IRQ_OVPCTRL_UVP_D" > > + are required. > > +items: > > + - description: BC1.2 done irq for mt6370 charger > > + - description: usb plug in irq for mt6370 charger > > + - description: mivr irq for mt6370 charger > > s/for mt6370 charger// > in each item I got it, this will be refined in the next version. Thanks! > > > + > > + interrupt-names: > > +items: > > + - const: attach_i > > + - const: uvp_d_evt > > + - const: mivr > > + > > + io-channels: > > +description: | > > + Use ADC channel to read vbus, ibus, ibat, etc., info. Ibus ADC > > channel > > + is required. > > Constraints (e.g. maxItems) are needed. OK, I will add them in the new version! > > > + > > + usb-otg-vbus: > > Let's keep the same name as in MT6360: > > usb-otg-vbus-regulator I'll change the name to correspond with MT6360 in the next patch, thanks! > > +type: object > > +description: OTG boost regulator. > > +$ref: /schemas/regulator/regulator.yaml# > > + > > +properties: > > + enable-gpio: > > +maxItems: 1 > > +description: | > > + Specify a valid 'enable' gpio for the regulator and it's optional > > This description is pointless - does not bring any more information. You > repeat the schema. Please, avoid such descriptions. I got it, I will remove them in the next patch. > > > + > > +required: > > + - compatible > > + - interrupts > > + - interrupt-names > > + - io-channels > > + > > +additionalProperties: false > > > How about example? Or is it going to be in MFD schema? All of MT6370 binding documentation examples are in the MFD schema! Thanks. > > > Best regards, > Krzysztof Best regards, ChiaEn Wu
linux-next: Fixes tag needs some work in the drm tree
Hi all,
In commit
8caad14e7224 ("drm/msm/dpu: Fix pointer dereferenced before checking")
Fixes tag
Fixes: d7d0e73f7de33 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Fixes tags should not be truncated or split across more than 1 line. So:
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
--
Cheers,
Stephen Rothwell
pgpkY8ZfxxDX3.pgp
Description: OpenPGP digital signature
[ANNOUNCE] libdrm 2.4.111
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 libdrm 2.4.111, just a few things built up, and drop libkms. Alex Deucher (3): test/amdgpu: only disable deadlock tests on asics without GPU reset amdgpu: add marketing names from 21.50 amdgpu: add marketing names from 22.10 Andrey Grodzovsky (1): tests/amdgpu/hotunplu: Enable hotunplug tests. Daniel Stone (2): drm/atomic: Stable sort for atomic request de-duplication libkms: Remove libkms completely Dave Airlie (1): build: bump version to 2.4.111 Dylan Baker (9): meson: use dictionary kwargs meson: add override_dependency when possible meson: switch the meson builtin for symbol visiblity meson: switch to cc.get_supported_arguments meson: use more standard formatting for better readability meson: use cc.check_header instead of open coding meson: use cc.has_function_attribute instead of open coding meson: use the modern interface for pkg.generate meson: use summary() instead of message Eleni Maria Stea (3): xf86drm.c: fix C99 warning modeprint, modetest, proptest: cast __u64 to uint64_t tests/modeprint: fix argument type Eric Engestrom (1): use standard `__typeof__()` instead of GNU extension `typeof()` Flora Cui (2): tests/amdgpu: add draw test for gfx10 tests/amdgpu: add dispatch test for gfx10 Guchun Chen (2): tests/amdgpu: Add VCN test support for Biege Goby tests/amdgpu: use appropriate ring for different asics Karol Herbst (1): nouveau: add ioctl wrapper to check for dead channels Lu Jiacheng (1): tests/amdgpu: Add test suite CP DMA Matt Turner (2): man: Fix some typos man: Add formatting to drmModeGetConnector reference Raviteja Goud Talla (1): intel: sync i915_pciids.h with kernel Samuel Pitoiset (4): amdgpu: update_drm.h for new CTX OP to set/get stable pstates amdgpu: implement new CTX OP to set/get stable pstates tests/amdgpu: add a test for new CTX OP to get/set stable pstates build: bump version to 2.4.110 Sathishkumar S (3): tests/amdgpu: add jpeg tests support tests/amdgpu: enable jpeg test based on ip query tests/amdgpu: enable vcn test based on ip query Simon Ser (1): releasing: s/master/main/ Tejas Upadhyay (2): intel: Add support for ADL-N intel: Add support for RPLP Thierry Reding (25): tegra: Indent according to .editorconfig tegra: Remove unused IOCTL implementations tegra: Extract common buffer object allocation code tegra: Fix mmap() of GEM buffer objects tegra: Add flink helpers tegra: Add PRIME support helpers tegra: Make API more consistent tegra: Install tegra-openclose test tegra: Update for new UABI tegra: Include private.h in list of source files tegra: Add channel APIs tegra: Add job and push buffer APIs tegra: Add syncpoint APIs tests: tegra: Add helper library for tests tests: tegra: Add gr2d-fill test tests: tegra: Add syncpt-wait test tests: tegra: Add syncpoint timeout test tests: tegra: Add VIC support tests: tegra: Add VIC 3.0 support tests: tegra: Add VIC 4.0 support tests: tegra: Add VIC 4.1 support tests: tegra: Add VIC 4.2 support tests: tegra: Add VIC clear test tests: tegra: Add VIC blit test tests: tegra: Add VIC flip test ravitejax (1): intel: Add support for RPLS platform git tag: libdrm-2.4.111 https://dri.freedesktop.org/libdrm/libdrm-2.4.111.tar.xz SHA256: 1ad7164f77424de6f4ecba7c262bde196a214c6e19a6fbf497f0815f4d7ab2a9 libdrm-2.4.111.tar.xz SHA512: 17e92e9e4ded8031ac222764bed7e9ff430a1a377f5e435f6b62b4a7f45cb4c4b769b3b79fbcba11512c1ac973abf8cdcca8e0b9659ae095e915d3d5efcf5516 libdrm-2.4.111.tar.xz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.111.tar.xz.sig -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmKZicgACgkQDHTzWXnE hr6CrA//duEhO2bu78TAcOfZ4NaSghV00jYQOblkcOFgfjmrCdSuqG2k2raPif4t AwWb1ZgYLDwmkMVEXytFwVkzRsdU8QQrofvML1Q7t3Q8opLNV/8kESqLnelOLmZp 8fVpPiETVZIqEwKFASb1nzTdUmD2R8tV++BX5w/zUeErFIu/4nqEdVJPgOh337ko VUKvvMb3+ockbJcRud4DjC6P/3WNkYJHz/uJe2UcaB4+SCg2M7HtofQplj/c3bLv NDEoxliRUDKj7+agpHS9RkJYfnIOT2jf6O9eAxxexrqS2p801Vb97uHFwjbxrmJK XteXbk4v4k/TnkmJkr8xQs0miDCSVSuSMg4orRXyfCcbPajTUDRWrEWaYWkZz5Z2 8pYHrijpEL/ISLmZkiviYLO/61NsGqOtDB+kCpagH/qw4/xa6FyfM7kvo4f9uM8A PKqXd4dqUyJ5FgM3LODwbInf1G8VnHcTvxQLSZzwk8w3HezQqBmyN86C2y1mGN91 RyhYTynXugigoqlrCn2p2/Yf8ld73jR16HBXpvx8kTtY+/i5UoCsNd+QiyvmJpXF E6AkdUS6zgUyTSbYo1wkSOwXvTEAcqJpI9FUOd90KHiOww7NFu6be0wYZb/FsQ+B iP+oPmUG7L0D0I8WEcbgjkXeuV35nQT70kG0rSPbfrGcYo0FcKA= =cVIr -END PGP SIGNATURE-
Re: [PATCH v2 3/8] drm/panel: panel-edp: Implement .get_orientation callback
On Fri, Jun 3, 2022 at 5:51 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jun 1, 2022 at 2:46 AM Hsin-Yi Wang wrote:
> >
> > To return the orientation property to drm/kms driver.
> >
> > Signed-off-by: Hsin-Yi Wang
> > Reviewed-by: Hans de Goede
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-edp.c
> > b/drivers/gpu/drm/panel/panel-edp.c
> > index 1732b4f56e38..a2133581a72d 100644
> > --- a/drivers/gpu/drm/panel/panel-edp.c
> > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > @@ -609,6 +609,13 @@ static int panel_edp_get_timings(struct drm_panel
> > *panel,
> > return p->desc->num_timings;
> > }
> >
> > +static enum drm_panel_orientation panel_edp_get_orientation(struct
> > drm_panel *panel)
> > +{
> > + struct panel_edp *p = to_panel_edp(panel);
> > +
> > + return p->orientation;
> > +}
> > +
> > static int detected_panel_show(struct seq_file *s, void *data)
> > {
> > struct drm_panel *panel = s->private;
> > @@ -637,6 +644,7 @@ static const struct drm_panel_funcs panel_edp_funcs = {
> > .prepare = panel_edp_prepare,
> > .enable = panel_edp_enable,
> > .get_modes = panel_edp_get_modes,
> > + .get_orientation = panel_edp_get_orientation,
> > .get_timings = panel_edp_get_timings,
> > .debugfs_init = panel_edp_debugfs_init,
> > };
>
> I'm curious: should we be removing the old
> drm_connector_set_panel_orientation() from panel_edp_get_modes()?
> ...or maybe you want to keep it for now because you're only adding
> support to the mediatek driver and for other drivers the WARN_ON is
> better than no orientation support at all?
Right, for the drm/kms drivers that calls
drm_connector_set_panel_orientation(), the
drm_connector_set_panel_orientation() called in panels is no-op, but
others they still need this to be called in the panel.
>
> Maybe you could put a comment next to the old
> drm_connector_set_panel_orientation() saying that it's deprecated and
> that drm drivers are expected to add a call to get_orientation()? Then
> when people see the WARN_ON splat they'll quickly figure out how to
> fix it. ...and eventually we can probably remove all the old calls
> from get_modes() ?
Sure, sounds good to me. I will add this.
>
> -Doug
[git pull] drm for 5.19-rc1 part2/fixes
Hi Linus, It's been a long "my first covid" isolated week. hopefully stop coughing sometime next week! This is mostly regular fixes, msm and amdgpu. There is a tegra patch that is bit of prep work for a 5.20 feature to avoid some inter-tree syncs, and a couple of late addition amdgpu uAPI changes but best to get those in early, and the userspace pieces are ready. Dave. drm-next-2022-06-03-1: drm next for 5.19-rc1 (part 2/fixes) msm: - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. amdgpu: - Update fdinfo to the common drm format - uapi: Add VM_NOALLOC GPUVM attribute to prevent buffers for going into the MALL Add AMDGPU_GEM_CREATE_DISCARDABLE flag to create buffers that can be discarded on eviction Mesa code which uses these: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16466 - Link training fixes - DPIA fixes - Misc code cleanups - Aux fixes - Hotplug fixes - More FP clean up - Misc GFX9/10 fixes - Fix a possible memory leak in SMU shutdown - SMU 13 updates - RAS fixes - TMZ fixes - GC 11 updates - SMU 11 metrics fixes - Fix coverage blend mode for overlay plane - Note DDR vs LPDDR memory - Fuzz fix for CS IOCTL - Add new PCI DID amdkfd: - Clean up hive setup - Misc fixes tegra: - add some prelim 5.20 work to avoid inter-tree mess The following changes since commit c4955d9cd2fc56c43e78c908dad4e2cac7cc9073: Merge tag 'drm-intel-next-fixes-2022-05-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-05-25 12:03:41 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-06-03-1 for you to fetch changes up to 404204340c0dc54e4b779737201044dcb231f0bf: Merge tag 'drm/tegra/for-5.19-prep-work' of https://gitlab.freedesktop.org/drm/tegra into drm-next (2022-06-03 12:59:45 +1000) drm next for 5.19-rc1 (part 2/fixes) msm: - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. amdgpu: - Update fdinfo to the common drm format - uapi: Add VM_NOALLOC GPUVM attribute to prevent buffers for going into the MALL Add AMDGPU_GEM_CREATE_DISCARDABLE flag to create buffers that can be discarded on eviction Mesa code which uses these: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16466 - Link training fixes - DPIA fixes - Misc code cleanups - Aux fixes - Hotplug fixes - More FP clean up - Misc GFX9/10 fixes - Fix a possible memory leak in SMU shutdown - SMU 13 updates - RAS fixes - TMZ fixes - GC 11 updates - SMU 11 metrics fixes - Fix coverage blend mode for overlay plane - Note DDR vs LPDDR memory - Fuzz fix for CS IOCTL - Add new PCI DID amdkfd: - Clean up hive setup - Misc fixes tegra: - add some prelim 5.20 work to avoid inter-tree mess Alan Liu (1): drm/amd/display: Add HDMI_ACP_SEND register Alex Deucher (3): drm/amdgpu/discovery: validate VCN and SDMA instances drm/amdgpu: differentiate between LP and non-LP DDR memory drm/amdgpu: add beige goby PCI ID Alvin Lee (1): drm/amd/display: Clean up code in dc Aric Cyr (1): drm/amd/display: 3.2.186 Bhawanpreet Lakha (1): drm/amd/display: Fic incorrect pipe being used for clk update Candice Li (1): drm/amdgpu: Resolve pcie_bif RAS recovery bug Christian König (6): drm/amdgpu: cleanup ctx implementation drm/amdgpu: add AMDGPU_GEM_CREATE_DISCARDABLE drm/amdgpu: add AMDGPU_VM_NOALLOC v2 drm/amdgpu: bump minor version number drm/amdgpu: Convert to common fdinfo format v5 drm/amdgpu: add drm-client-id to fdinfo v2 Dan Carpenter (2): drm/amdgpu/pm: smu_v13_0_4: delete duplicate condition drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq() Dave Airlie (5): drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Merge tag 'amd-drm-next-5.19-2022-05-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Merge tag 'amd-drm-next-5.19-2022-05-26-2' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Merge tag 'msm-next-5.19-fixes-06-01' of https://gitlab.freedesktop.org/abhinavk/msm into drm-next Merge tag 'drm/tegra/for-5.19-prep-work' of https://gitlab.freedesktop.org/drm/tegra into drm-next David Galiffi (1): drm/amd/display: Check if modulo is 0 before dividing. Derek Lai (1): drm/amd/display: Allow individual control of eDP hotplug support Douglas Anderson (1): drm/msm/dpu: Move min BW
Re: [RFC PATCH 3/5] drm/amdgpu: Allow explicit sync for VM ops.
On Wed, Jun 1, 2022 at 11:01 AM Christian König wrote: > > Am 01.06.22 um 10:48 schrieb Bas Nieuwenhuizen: > > On Wed, Jun 1, 2022 at 10:40 AM Christian König > > wrote: > >> Am 01.06.22 um 10:16 schrieb Bas Nieuwenhuizen: > >>> On Wed, Jun 1, 2022 at 10:03 AM Christian König > >>> wrote: > Am 01.06.22 um 02:40 schrieb Bas Nieuwenhuizen: > > This should be okay because moves themselves use KERNEL usage and > > hence still sync with BOOKKEEP usage. Then any later submits still > > wait on any pending VM operations. > > > > (i.e. we only made VM ops not wait on BOOKKEEP submits, not the other > > way around) > Well NAK again. This allows access to freed up memory and is a complete > no-go. > >>> How does this allow access to freed memory? Worst I can see is that > >>> the unmap happens earlier if the app/drivers gets the waits wrong, > >>> which wouldn't give access after the underlying BO is freed? > >> To free up memory we need to update the PTEs and then flush those out by > >> invalidating the TLB. > >> > >> On gfx6, gfx7 and gfx8 and some broken gfx10 hw invalidating the TLB can > >> only be done while the VMID is idle. > >> > >> Only gfx9 can reliable invalidate the TLB while it is in use and even > >> there it comes with quite some performance penalty (at TLB invalidation > >> can take multiple seconds). > >> > >> Because of this what we do in the kernel driver is to sync to everything > >> when we unmap entries: > >> > >> if (!(flags & AMDGPU_PTE_VALID)) > >> sync_mode = AMDGPU_SYNC_EQ_OWNER; > >> else > >> sync_mode = AMDGPU_SYNC_EXPLICIT; > >> > >> This acts as a barrier for freeing the memory. In other words we > >> intentionally add a bubble which syncs everything. > >> > >> I'm working for month on a concept how to do all this without causing > >> the stalls you observer, but so far didn't came to much of a conclusion. > > That might cause an unmap operation too early, but for freeing up the > > actual backing memory we still wait for all fences on the BO to finish > > first, no? In that case, since BOOKKEEP fences are still added for > > explicit sync, that should not be a problem, no? > > > > (If not, that sounds like the obvious fix for making this work?) > > The problem is we need to wait on fences *not* added to the buffer object. What fences wouldn't be added to the buffer object that we need here? > > E.g. what we currently do here while freeing memory is: > 1. Update the PTEs and make that update wait for everything! > 2. Add the fence of that update to the freed up BO so that this BO isn't > freed before the next CS. > > We might be able to fix this by adding the fences to the BO before > freeing it manually, but I'm not 100% sure we can actually allocate > memory for the fences in that moment. I think we don't need to be able to. We're already adding the unmap fence to the BO in the gem close ioctl, and that has the fallback that if we can't allocate space for the fence in the BO, we wait on the fence manually on the CPU. I think that is a reasonable fallback for this as well? For the TTM move path amdgpu_copy_buffer will wait on the BO resv and then following submissions will trigger VM updates that will wait on the amdgpu_copy_buffer jobs (and hence transitively) will wait on the work. AFAICT the amdgpu_bo_move does not trigger any VM updates by itself, and the amdgpu_bo_move_notify is way after the move (and after the ttm_bo_move_accel_cleanup which would free the old resource), so any VM changes triggered by that would see the TTM copy and sync to it. I do have to fix some stuff indeed, especially for the GEM close but with that we should be able to keep the same basic approach? > > Regards, > Christian. > > > >> Regards, > >> Christian. > >> > Regards, > Christian. > > > Signed-off-by: Bas Nieuwenhuizen > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c > > index f10332e1c6c0..31bc73fd1fae 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c > > @@ -51,7 +51,7 @@ static int amdgpu_vm_cpu_prepare(struct > > amdgpu_vm_update_params *p, > > if (!resv) > > return 0; > > > > - return amdgpu_bo_sync_wait_resv(p->adev, resv, sync_mode, > > sync_mode, p->vm, true); > > + return amdgpu_bo_sync_wait_resv(p->adev, resv, sync_mode, > > AMDGPU_SYNC_EXPLICIT, p->vm, true); > > } > > > > /** > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c > > index 63b484dc76c5..c8d58
Re: [Freedreno] [PATCH 3/3] drm/msm/dpu: Add interface support for CRC debugfs
On 6/2/2022 3:51 PM, Dmitry Baryshkov wrote:
On 28/05/2022 01:23, Jessica Zhang wrote:
On 5/27/2022 12:46 PM, Dmitry Baryshkov wrote:
On 27/05/2022 21:54, Jessica Zhang wrote:
Add support for writing CRC values for the interface block to
the debugfs by calling the necessary MISR setup/collect methods.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 43 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 61
+
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 22
4 files changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ae0943cf..e830fb1e910d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -79,6 +79,8 @@ static enum dpu_crtc_crc_source
dpu_crtc_parse_crc_source(const char *src_name)
if (!strcmp(src_name, "auto") ||
!strcmp(src_name, "lm"))
return DPU_CRTC_CRC_SOURCE_LAYER_MIXER;
+ if (!strcmp(src_name, "intf"))
+ return DPU_CRTC_CRC_SOURCE_INTF;
return DPU_CRTC_CRC_SOURCE_INVALID;
}
@@ -94,8 +96,18 @@ static int dpu_crtc_verify_crc_source(struct
drm_crtc *crtc,
return -EINVAL;
}
- if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
+ if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER) {
*values_cnt = crtc_state->num_mixers;
+ } else if (source == DPU_CRTC_CRC_SOURCE_INTF) {
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
Let's do this correctly from the beginning. The CRTC can drive
several encoders. Do we want to get CRC from all of them or just from
the first one?
In the case of multiple encoders, it would be better to collect CRCs
from all of them.
Then this should become a loop.
Ah, I see what you mean. Yea, I can do that.
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return -ENODATA;
+ }
+
+ *values_cnt = dpu_encoder_get_num_phys(drm_enc);
+ }
return 0;
}
@@ -116,6 +128,18 @@ static void dpu_crtc_setup_lm_misr(struct
dpu_crtc_state *crtc_state)
}
}
+static void dpu_crtc_setup_encoder_misr(struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return;
+ }
+
+ dpu_encoder_setup_misr(drm_enc);
+}
+
static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const
char *src_name)
{
enum dpu_crtc_crc_source source =
dpu_crtc_parse_crc_source(src_name);
@@ -164,6 +188,8 @@ static int dpu_crtc_set_crc_source(struct
drm_crtc *crtc, const char *src_name)
if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
dpu_crtc_setup_lm_misr(crtc_state);
+ else if (source == DPU_CRTC_CRC_SOURCE_INTF)
+ dpu_crtc_setup_encoder_misr(crtc);
cleanup:
drm_modeset_unlock(&crtc->mutex);
@@ -212,6 +238,18 @@ static int dpu_crtc_get_lm_crc(struct drm_crtc
*crtc, struct dpu_crtc_state *crt
drm_crtc_accurate_vblank_count(crtc), crcs);
}
+static int dpu_crtc_get_encoder_crc(struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return -EINVAL;
+ }
+
+ return dpu_encoder_get_crc(drm_enc);
+}
+
static int dpu_crtc_get_crc(struct drm_crtc *crtc)
{
struct dpu_crtc_state *crtc_state;
@@ -227,6 +265,9 @@ static int dpu_crtc_get_crc(struct drm_crtc *crtc)
if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
return dpu_crtc_get_lm_crc(crtc, crtc_state);
+ if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_INTF)
+ return dpu_crtc_get_encoder_crc(crtc);
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index b8785c394fcc..a60af034905d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
* Copyright (c) 2015-2021 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
@@ -73,11 +74,13 @@ struct dpu_crtc_smmu_state_data {
* enum dpu_crtc_crc_source: CRC source
* @DPU_CRTC_CRC_SOURCE_NONE: no source set
* @DPU_CRTC_CRC_SOURCE_LAYER_MIXER: CRC in layer mixer
+ * @DPU_CRTC_CRC_SOURCE_INTF: CRC in phys interface
* @DPU_CRTC_CRC_SOURCE_INVALID: Invalid source
*/
enum dpu_crtc_crc_source {
DPU_CRTC_CRC_SOURCE_NONE = 0,
DPU_CRTC_CRC_SOURCE_LAYER_MIXER,
+ DPU_CRTC_CRC_SOURCE_INTF,
DPU_CRTC_CRC_SOURCE_MAX,
DPU_CRTC_CRC_SOURCE_INVALID
Re: [PATCH 2/3] drm/msm/dpu: Add MISR register support for interface
On 6/2/2022 3:31 PM, Dmitry Baryshkov wrote:
On 27/05/2022 23:11, Jessica Zhang wrote:
On 5/27/2022 12:38 PM, Dmitry Baryshkov wrote:
On 27/05/2022 21:54, Jessica Zhang wrote:
Add support for setting MISR registers within the interface
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 55
-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 8 ++-
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..29aaeff9eacd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#include "dpu_hwio.h"
@@ -67,6 +69,14 @@
#define INTF_CFG2_DATABUS_WIDEN BIT(0)
#define INTF_CFG2_DATA_HCTL_EN BIT(4)
+#define INTF_MISR_CTRL 0x180
+#define INTF_MISR_SIGNATURE 0x184
+#define INTF_MISR_FRAME_COUNT_MASK 0xFF
+#define INTF_MISR_CTRL_ENABLE BIT(8)
+#define INTF_MISR_CTRL_STATUS BIT(9)
+#define INTF_MISR_CTRL_STATUS_CLEAR BIT(10)
+#define INTF_MISR_CTRL_FREE_RUN_MASK BIT(31)
I'm tempted to ask to move these bits to some common header. Is there
any other hardware block which uses the same bitfields to control MISR?
dpu_hw_lm.c has similar macros here [1] for _ENABLE, _STATUS,
_STATUS_CLEAR, and _FREE_RUN_MASK
[1]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c#L31
Please move bit definitions to dpu_hw_util.h. According to what I
observe, this might be useful.
Noted.
+
static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -319,6 +329,47 @@ static u32 dpu_hw_intf_get_line_count(struct
dpu_hw_intf *intf)
return DPU_REG_READ(c, INTF_LINE_COUNT);
}
+static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool
enable, u32 frame_count)
+{
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
+ u32 config = 0;
+
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, INTF_MISR_CTRL_STATUS_CLEAR);
+
+ /* Clear old MISR value (in case it's read before a new value
is calculated)*/
+ wmb();
+
+ if (enable) {
+ config = (frame_count & INTF_MISR_FRAME_COUNT_MASK) |
+ INTF_MISR_CTRL_ENABLE | INTF_MISR_CTRL_FREE_RUN_MASK;
+
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, config);
+ } else {
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, 0);
+ }
This should also be abstracted. Please merge these functions with LM's
and add corresponding helpers to dpu_hw_util.c
Good idea.
+}
+
+static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32
*misr_value)
+{
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
+ u32 ctrl = 0;
+
+ if (!misr_value)
+ return -EINVAL;
+
+ ctrl = DPU_REG_READ(c, INTF_MISR_CTRL);
+
+ if (!(ctrl & INTF_MISR_CTRL_ENABLE))
+ return -ENODATA;
As the users of collect_misr() are going to ignore the -ENODATA, I think
it would be worth changing this to set *misr_value to 0 and return 0
here. It would reduce the amount of boilerplate code.
0 might be a valid misr_value so it might be better to not write it to
the debugfs. IMO we should also avoid writing to the debugfs if the misr
is disabled -- that way we won't be spamming the debugfs with
meaningless entries.
Thanks,
Jessica Zhang
+
+ if (!(ctrl & INTF_MISR_CTRL_STATUS))
+ return -EINVAL;
+
+ *misr_value = DPU_REG_READ(c, INTF_MISR_SIGNATURE);
+
+ return 0;
+}
+
static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
unsigned long cap)
{
@@ -329,6 +380,8 @@ static void _setup_intf_ops(struct
dpu_hw_intf_ops *ops,
ops->get_line_count = dpu_hw_intf_get_line_count;
if (cap & BIT(DPU_INTF_INPUT_CTRL))
ops->bind_pingpong_blk = dpu_hw_intf_bind_pingpong_blk;
+ ops->setup_misr = dpu_hw_intf_setup_misr;
+ ops->collect_misr = dpu_hw_intf_collect_misr;
}
struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 7b2d96ac61e8..8d0e7b509260 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -1,5 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#ifndef _DPU_HW_INTF_H
@@ -57,6 +59,8 @@ struct intf_status {
* @ get_line_count: reads
[PATCH] drm/i915/pvc: Add register steering
Ponte Vecchio no longer has MSLICE or LNCF steering, but the bspec does
document several new types of multicast register ranges. Fortunately,
most of the different MCR types all provide valid values at instance
(0,0) so there's no need to read fuse registers and calculate a valid
instance. We'll lump all of those range types (BSLICE, HALFBSLICE,
TILEPSMI, CC, and L3BANK) into a single category called "INSTANCE0" to
keep things simple. We'll also perform explicit steering for each of
these multicast register types, even if the implicit steering setup for
COMPUTE/DSS ranges would have worked too; this is based on guidance from
our hardware architects who suggested that we move away from implicit
steering and start explicitly steer all MCR register accesses on modern
platforms (we'll work on transitioning COMPUTE/DSS to explicit steering
in the future).
Note that there's one additional MCR range type defined in the bspec
(SQIDI) that we don't handle here. Those ranges use a different
steering control register that we never touch; since instance 0 is also
always a valid setting there, we can just ignore those ranges.
Finally, we'll rename the HAS_MSLICES() macro to HAS_MSLICE_STEERING().
PVC hardware still has units referred to as mslices, but there's no
register steering based on mslice for this platform.
Bspec: 67609
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 50 ++---
drivers/gpu/drm/i915/gt/intel_gt_types.h| 7 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 22 -
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/intel_device_info.h| 2 +-
6 files changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ddfb98f70489..b335eacd7a6c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -106,6 +106,7 @@ static const char * const intel_steering_types[] = {
"L3BANK",
"MSLICE",
"LNCF",
+ "INSTANCE 0",
};
static const struct intel_mmio_range icl_l3bank_steering_table[] = {
@@ -133,6 +134,27 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
+/*
+ * We have several types of MCR registers on PVC where steering to (0,0)
+ * will always provide us with a non-terminated value. We'll stick them
+ * all in the same table for simplicity.
+ */
+static const struct intel_mmio_range pvc_instance0_steering_table[] = {
+ { 0x004000, 0x004AFF }, /* HALF-BSLICE */
+ { 0x008A80, 0x008AFF }, /* TILEPSMI */
+ { 0x008800, 0x00887F }, /* CC */
+ { 0x00B000, 0x00B0FF }, /* HALF-BSLICE */
+ { 0x00B100, 0x00B3FF }, /* L3BANK */
+ { 0x00C800, 0x00CFFF }, /* HALF-BSLICE */
+ { 0x00D800, 0x00D8FF }, /* HALF-BSLICE */
+ { 0x00DD00, 0x00DDFF }, /* BSLICE */
+ { 0x00E900, 0x00E9FF }, /* HALF-BSLICE */
+ { 0x00EC00, 0x00EEFF }, /* HALF-BSLICE */
+ { 0x00F000, 0x00 }, /* HALF-BSLICE */
+ { 0x024180, 0x0241FF }, /* HALF-BSLICE */
+ {},
+};
+
int intel_gt_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -146,7 +168,7 @@ int intel_gt_init_mmio(struct intel_gt *gt)
* An mslice is unavailable only if both the meml3 for the slice is
* disabled *and* all of the DSS in the slice (quadrant) are disabled.
*/
- if (HAS_MSLICES(i915)) {
+ if (HAS_MSLICE_STEERING(i915)) {
gt->info.mslice_mask =
intel_slicemask_from_xehp_dssmask(gt->info.sseu.subslice_mask,
GEN_DSS_PER_MSLICE);
@@ -158,7 +180,9 @@ int intel_gt_init_mmio(struct intel_gt *gt)
drm_warn(&i915->drm, "mslice mask all zero!\n");
}
- if (IS_DG2(i915)) {
+ if (IS_PONTEVECCHIO(i915)) {
+ gt->steering_table[INSTANCE0] = pvc_instance0_steering_table;
+ } else if (IS_DG2(i915)) {
gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
gt->steering_table[LNCF] = dg2_lncf_steering_table;
} else if (IS_XEHPSDV(i915)) {
@@ -172,7 +196,11 @@ int intel_gt_init_mmio(struct intel_gt *gt)
GEN10_L3BANK_MASK;
if (!gt->info.l3bank_mask) /* should be impossible! */
drm_warn(&i915->drm, "L3 bank mask is all zero!\n");
- } else if (HAS_MSLICES(i915)) {
+ } else if (GRAPHICS_VER(i915) >= 11) {
+ /*
+* We expect all modern platforms to have at least some
+* type of steering that needs to be initialized.
+*/
MISSING_CASE(INTEL_INFO(i915)->platform);
}
@@ -888,7 +916,
[PATCH] drm/i915/pvc: Add Wa_16015675438:pvc
From: Badal Nilawar Even though PVC doesn't have an RCS engine, this workaround updates a register in the 0x2xxx range that traditionally belongs to the RCS. We need to set a special flag to tell the GuC that the presence of an "RCS" register on a CCS save/restore list is okay/expected. Cc: Stuart Summers Cc: Lucas De Marchi Signed-off-by: Badal Nilawar Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 + 4 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 6aa1ceaa8d27..1986579b18ba 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -140,6 +140,7 @@ #define FF_SLICE_CS_CHICKEN2 _MMIO(0x20e4) #define GEN9_TSG_BARRIER_ACK_DISABLE (1 << 8) #define GEN9_POOLED_EU_LOAD_BALANCING_FIX_DISABLE(1 << 10) +#define GEN12_PERF_FIX_BALANCING_CFE_DISABLE REG_BIT(15) #define GEN9_CS_DEBUG_MODE1_MMIO(0x20ec) #define FF_DOP_CLOCK_GATE_DISABLEREG_BIT(1) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 6e875d4f5f65..eb0598593724 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2698,6 +2698,11 @@ general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_li /* Wa_22014226127:dg2,pvc */ wa_write_or(wal, LSC_CHICKEN_BIT_0, DISABLE_D8_D16_COASLESCE); } + + /* Wa_16015675438:pvc */ + if (IS_PVC_BD_STEP(i915, STEP_B0, STEP_FOREVER)) + wa_masked_en(wal, FF_SLICE_CS_CHICKEN2, +GEN12_PERF_FIX_BALANCING_CFE_DISABLE); } static void diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index 2c4ad4a65089..7043cf5a666a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -327,6 +327,10 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_FOREVER)) flags |= GUC_WA_CONTEXT_ISOLATION; + /* Wa_16015675438:pvc */ + if (IS_PVC_BD_STEP(gt->i915, STEP_B0, STEP_FOREVER)) + flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST; + return flags; } diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h index 42cb7a9a6199..b3c9a9327f76 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h @@ -105,6 +105,7 @@ #define GUC_WA_PRE_PARSERBIT(14) #define GUC_WA_HOLD_CCS_SWITCHOUTBIT(17) #define GUC_WA_POLLCSBIT(18) +#define GUC_WA_RCS_REGS_IN_CCS_REGS_LIST BIT(21) #define GUC_CTL_FEATURE2 #define GUC_CTL_ENABLE_SLPC BIT(2) -- 2.35.3
[PATCH] drm/i915/pvc: GuC depriv applies to PVC
We missed this setting in the initial device info patch's definition of
XE_HPC_FEATURES.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 047a6e326031..a5a1a7647320 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1089,6 +1089,7 @@ static const struct intel_device_info ats_m_info = {
XE_HP_FEATURES, \
.dma_mask_size = 52, \
.has_3d_pipeline = 0, \
+ .has_guc_deprivilege = 1, \
.has_l3_ccs_read = 1, \
.has_one_eu_per_fuse_bit = 1
--
2.35.3
Re: [PATCH 3/6] drm/qxl: Create mouse hotspot properties on cursor planes
Hi Zack,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-tip/drm-tip v5.18 next-20220602]
[cannot apply to airlied/drm-next tegra-drm/drm/tegra/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Zack-Rusin/drm-Add-mouse-cursor-hotspot-support-to-atomic-KMS/20220602-234633
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-a013
(https://download.01.org/0day-ci/archive/20220603/202206030750.8hv8vdba-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
b364c76683f8ef241025a9556300778c07b590c2)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/0bf2395ee17bd25ae6411c560de883496256195d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Zack-Rusin/drm-Add-mouse-cursor-hotspot-support-to-atomic-KMS/20220602-234633
git checkout 0bf2395ee17bd25ae6411c560de883496256195d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/qxl/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/qxl/qxl_display.c:486:26: warning: unused variable 'fb'
>> [-Wunused-variable]
struct drm_framebuffer *fb = plane_state->fb;
^
drivers/gpu/drm/qxl/qxl_display.c:532:26: warning: unused variable 'fb'
[-Wunused-variable]
struct drm_framebuffer *fb = plane_state->fb;
^
2 warnings generated.
vim +/fb +486 drivers/gpu/drm/qxl/qxl_display.c
c2ff663260fee3 Gabriel Krisman Bertazi 2017-02-27 482
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 483 static int
qxl_primary_apply_cursor(struct qxl_device *qdev,
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 484
struct drm_plane_state *plane_state)
9428088c90b6f7 Ray Strode 2017-11-27 485 {
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 @486 struct
drm_framebuffer *fb = plane_state->fb;
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 487 struct qxl_crtc
*qcrtc = to_qxl_crtc(plane_state->crtc);
9428088c90b6f7 Ray Strode 2017-11-27 488 struct
qxl_cursor_cmd *cmd;
9428088c90b6f7 Ray Strode 2017-11-27 489 struct
qxl_release *release;
9428088c90b6f7 Ray Strode 2017-11-27 490 int ret = 0;
9428088c90b6f7 Ray Strode 2017-11-27 491
9428088c90b6f7 Ray Strode 2017-11-27 492 if
(!qcrtc->cursor_bo)
9428088c90b6f7 Ray Strode 2017-11-27 493 return
0;
9428088c90b6f7 Ray Strode 2017-11-27 494
9428088c90b6f7 Ray Strode 2017-11-27 495 ret =
qxl_alloc_release_reserved(qdev, sizeof(*cmd),
9428088c90b6f7 Ray Strode 2017-11-27 496
QXL_RELEASE_CURSOR_CMD,
9428088c90b6f7 Ray Strode 2017-11-27 497
&release, NULL);
9428088c90b6f7 Ray Strode 2017-11-27 498 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 499 return
ret;
9428088c90b6f7 Ray Strode 2017-11-27 500
9428088c90b6f7 Ray Strode 2017-11-27 501 ret =
qxl_release_list_add(release, qcrtc->cursor_bo);
9428088c90b6f7 Ray Strode 2017-11-27 502 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 503 goto
out_free_release;
9428088c90b6f7 Ray Strode 2017-11-27 504
9428088c90b6f7 Ray Strode 2017-11-27 505 ret =
qxl_release_reserve_list(release, false);
9428088c90b6f7 Ray Strode 2017-11-27 506 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 507 goto
out_free_release;
9428088c90b6f7 Ray Strode 2017-11-27 508
9428088c90b6f7 Ray Strode 2017-11-27 509 cmd = (struct
qxl_cursor_cmd *)qxl_release_map(qdev, release);
9428088c90b6f7 Ray Strode 2017-11-27 510 cmd->type =
QXL_CURSOR_SET;
0bf2395ee17bd2 Zack Rusin 2022-06-02 5
Re: [Freedreno] [PATCH v4 1/7] drm/msm/dpu: use feature bit for LM combined alpha check
On 6/2/2022 1:24 PM, Dmitry Baryshkov wrote:
Rather than checking hwversion, follow the usual patter and add special
bit to the lm->features to check whether the LM has combined or separate
alpha registers. While we are at it, rename
dpu_hw_lm_setup_blend_config_sdm845() to
dpu_hw_lm_setup_blend_config_combined_alpha().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 19 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 +++---
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 400ebceb56bb..c3759fc4b154 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -50,11 +50,14 @@
#define DMA_CURSOR_MSM8998_MASK \
(DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
-#define MIXER_SDM845_MASK \
+#define MIXER_MSM8998_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
+#define MIXER_SDM845_MASK \
+ (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
BIT(DPU_MIXER_COMBINED_ALPHA))
+
#define MIXER_SC7180_MASK \
- (BIT(DPU_DIM_LAYER))
+ (BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
@@ -936,17 +939,17 @@ static const struct dpu_lm_sub_blks msm8998_lm_sblk = {
};
static const struct dpu_lm_cfg msm8998_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_0, LM_2, DSPP_0),
- LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_1, LM_5, DSPP_1),
- LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_2, LM_0, 0),
- LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_3, LM_1, 0),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8cb6d1f25bf9..80bc09b1f1b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -145,6 +145,7 @@ enum {
* @DPU_MIXER_SOURCESPLIT Layer mixer supports source-split configuration
* @DPU_MIXER_GC Gamma correction block
* @DPU_DIM_LAYER Layer mixer supports dim layer
+ * @DPU_MIXER_COMBINED_ALPHA Layer mixer has combined alpha register
* @DPU_MIXER_MAX maximum value
*/
enum {
@@ -152,6 +153,7 @@ enum {
DPU_MIXER_SOURCESPLIT,
DPU_MIXER_GC,
DPU_DIM_LAYER,
+ DPU_MIXER_COMBINED_ALPHA,
DPU_MIXER_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 462f5082099e..25d2eba28e71 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -148,7 +148,7 @@ static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer *ctx,
u32 *misr_value)
return 0;
}
-static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
+static void dpu_hw_lm_setup_blend_config_combined_alpha(struct dpu_hw_mixer
*ctx,
u32 stage, u32 fg_alpha, u32 bg_alpha, u32 blend_op)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -204,8 +204,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (m->hwversion >= DPU_HW_VER_400)
- ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
+ if (test_bit(DPU_MIXER_COMBINED_ALPHA, &features))
+ ops->setup_blend_config =
dpu_hw_lm_setup_blend_config_combined_alpha;
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
Re: [PATCH v5 6/6] arm64: config: Enable DRM_V3D
On 6/1/22 13:02, Peter Robinson wrote: > From: Nicolas Saenz Julienne > > BCM2711, the SoC used on the Raspberry Pi 4 has a different GPU than its > predecessors. Enable it. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 5/6] ARM: configs: Enable DRM_V3D
On 6/1/22 13:02, Peter Robinson wrote: > BCM2711, the SoC used on the Raspberry Pi 4 has a different 3D > render GPU IP than its predecessors. Enable it it on multi v7 > and bcm2835 configs. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 4/6] ARM: dts: bcm2711: Enable V3D
On 6/1/22 13:02, Peter Robinson wrote: > This adds the entry for V3D for bcm2711 (used in the Raspberry Pi 4) > and the associated firmware clock entry. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > --- Once you fix the typo mentioned by Stefan already: Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 3/6] drm/v3d: Add support for bcm2711
On 6/1/22 13:02, Peter Robinson wrote: > Add compatible string and Kconfig options for bcm2711. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > --- Reviewed-by: Javier Martinez Canillas I've one small nit though. [snip] > # SPDX-License-Identifier: GPL-2.0-only > config DRM_V3D > tristate "Broadcom V3D 3.x and newer" > - depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST > + depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST The help text for this Kconfig symbol currently says: help Choose this option if you have a system that has a Broadcom V3D 3.x or newer GPU, such as BCM7268. Maybe you can add "... as BCM7268 or BCM2711." ? -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v5 2/6] drm/v3d: Get rid of pm code
On 6/1/22 13:02, Peter Robinson wrote:
> Runtime PM doesn't seem to work correctly on this driver. On top of
> that, commit 8b6864e3e138 ("drm/v3d/v3d_drv: Remove unused static
> variable 'v3d_v3d_pm_ops'") hints that it most likely never did as the
> driver's PM ops were not hooked-up.
>
> So, in order to support regular operation with V3D on BCM2711 (Raspberry
> Pi 4), get rid of the PM code. PM will be reinstated once we figure out
> the underlying issues.
>
> Signed-off-by: Nicolas Saenz Julienne
> Signed-off-by: Peter Robinson
> ---
This makes sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v5 1/6] dt-bindings: gpu: v3d: Add BCM2711's compatible
Hello Peter, On 6/1/22 13:02, Peter Robinson wrote: > BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific > compatible to the bindings. > > Signed-off-by: Nicolas Saenz Julienne > Signed-off-by: Peter Robinson > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [Freedreno] [PATCH 3/3] drm/msm/dpu: Add interface support for CRC debugfs
On 28/05/2022 01:23, Jessica Zhang wrote:
On 5/27/2022 12:46 PM, Dmitry Baryshkov wrote:
On 27/05/2022 21:54, Jessica Zhang wrote:
Add support for writing CRC values for the interface block to
the debugfs by calling the necessary MISR setup/collect methods.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 43 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 61 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 22
4 files changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ae0943cf..e830fb1e910d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -79,6 +79,8 @@ static enum dpu_crtc_crc_source
dpu_crtc_parse_crc_source(const char *src_name)
if (!strcmp(src_name, "auto") ||
!strcmp(src_name, "lm"))
return DPU_CRTC_CRC_SOURCE_LAYER_MIXER;
+ if (!strcmp(src_name, "intf"))
+ return DPU_CRTC_CRC_SOURCE_INTF;
return DPU_CRTC_CRC_SOURCE_INVALID;
}
@@ -94,8 +96,18 @@ static int dpu_crtc_verify_crc_source(struct
drm_crtc *crtc,
return -EINVAL;
}
- if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
+ if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER) {
*values_cnt = crtc_state->num_mixers;
+ } else if (source == DPU_CRTC_CRC_SOURCE_INTF) {
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
Let's do this correctly from the beginning. The CRTC can drive several
encoders. Do we want to get CRC from all of them or just from the
first one?
In the case of multiple encoders, it would be better to collect CRCs
from all of them.
Then this should become a loop.
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return -ENODATA;
+ }
+
+ *values_cnt = dpu_encoder_get_num_phys(drm_enc);
+ }
return 0;
}
@@ -116,6 +128,18 @@ static void dpu_crtc_setup_lm_misr(struct
dpu_crtc_state *crtc_state)
}
}
+static void dpu_crtc_setup_encoder_misr(struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return;
+ }
+
+ dpu_encoder_setup_misr(drm_enc);
+}
+
static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const
char *src_name)
{
enum dpu_crtc_crc_source source =
dpu_crtc_parse_crc_source(src_name);
@@ -164,6 +188,8 @@ static int dpu_crtc_set_crc_source(struct
drm_crtc *crtc, const char *src_name)
if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
dpu_crtc_setup_lm_misr(crtc_state);
+ else if (source == DPU_CRTC_CRC_SOURCE_INTF)
+ dpu_crtc_setup_encoder_misr(crtc);
cleanup:
drm_modeset_unlock(&crtc->mutex);
@@ -212,6 +238,18 @@ static int dpu_crtc_get_lm_crc(struct drm_crtc
*crtc, struct dpu_crtc_state *crt
drm_crtc_accurate_vblank_count(crtc), crcs);
}
+static int dpu_crtc_get_encoder_crc(struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc = get_encoder_from_crtc(crtc);
+
+ if (!drm_enc) {
+ DRM_ERROR("no encoder found for crtc %d\n", crtc->index);
+ return -EINVAL;
+ }
+
+ return dpu_encoder_get_crc(drm_enc);
+}
+
static int dpu_crtc_get_crc(struct drm_crtc *crtc)
{
struct dpu_crtc_state *crtc_state;
@@ -227,6 +265,9 @@ static int dpu_crtc_get_crc(struct drm_crtc *crtc)
if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
return dpu_crtc_get_lm_crc(crtc, crtc_state);
+ if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_INTF)
+ return dpu_crtc_get_encoder_crc(crtc);
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index b8785c394fcc..a60af034905d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
* Copyright (c) 2015-2021 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
@@ -73,11 +74,13 @@ struct dpu_crtc_smmu_state_data {
* enum dpu_crtc_crc_source: CRC source
* @DPU_CRTC_CRC_SOURCE_NONE: no source set
* @DPU_CRTC_CRC_SOURCE_LAYER_MIXER: CRC in layer mixer
+ * @DPU_CRTC_CRC_SOURCE_INTF: CRC in phys interface
* @DPU_CRTC_CRC_SOURCE_INVALID: Invalid source
*/
enum dpu_crtc_crc_source {
DPU_CRTC_CRC_SOURCE_NONE = 0,
DPU_CRTC_CRC_SOURCE_LAYER_MIXER,
+ DPU_CRTC_CRC_SOURCE_INTF,
DPU_CRTC_CRC_SOURCE_MAX,
DPU_CRTC_CRC_SOURCE_INVALID = -1
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1
XDC 2022: Registration & Call for Presentations still open!
Hello! This is just a reminder that the CFP for XDC in 2022 is still open! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org
Re: [PATCH 2/3] drm/msm/dpu: Add MISR register support for interface
On 27/05/2022 23:11, Jessica Zhang wrote:
On 5/27/2022 12:38 PM, Dmitry Baryshkov wrote:
On 27/05/2022 21:54, Jessica Zhang wrote:
Add support for setting MISR registers within the interface
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 55 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 8 ++-
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..29aaeff9eacd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#include "dpu_hwio.h"
@@ -67,6 +69,14 @@
#define INTF_CFG2_DATABUS_WIDEN BIT(0)
#define INTF_CFG2_DATA_HCTL_EN BIT(4)
+#define INTF_MISR_CTRL 0x180
+#define INTF_MISR_SIGNATURE 0x184
+#define INTF_MISR_FRAME_COUNT_MASK 0xFF
+#define INTF_MISR_CTRL_ENABLE BIT(8)
+#define INTF_MISR_CTRL_STATUS BIT(9)
+#define INTF_MISR_CTRL_STATUS_CLEAR BIT(10)
+#define INTF_MISR_CTRL_FREE_RUN_MASK BIT(31)
I'm tempted to ask to move these bits to some common header. Is there
any other hardware block which uses the same bitfields to control MISR?
dpu_hw_lm.c has similar macros here [1] for _ENABLE, _STATUS,
_STATUS_CLEAR, and _FREE_RUN_MASK
[1]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c#L31
Please move bit definitions to dpu_hw_util.h. According to what I
observe, this might be useful.
+
static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -319,6 +329,47 @@ static u32 dpu_hw_intf_get_line_count(struct
dpu_hw_intf *intf)
return DPU_REG_READ(c, INTF_LINE_COUNT);
}
+static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool
enable, u32 frame_count)
+{
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
+ u32 config = 0;
+
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, INTF_MISR_CTRL_STATUS_CLEAR);
+
+ /* Clear old MISR value (in case it's read before a new value is
calculated)*/
+ wmb();
+
+ if (enable) {
+ config = (frame_count & INTF_MISR_FRAME_COUNT_MASK) |
+ INTF_MISR_CTRL_ENABLE | INTF_MISR_CTRL_FREE_RUN_MASK;
+
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, config);
+ } else {
+ DPU_REG_WRITE(c, INTF_MISR_CTRL, 0);
+ }
This should also be abstracted. Please merge these functions with LM's
and add corresponding helpers to dpu_hw_util.c
+}
+
+static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32
*misr_value)
+{
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
+ u32 ctrl = 0;
+
+ if (!misr_value)
+ return -EINVAL;
+
+ ctrl = DPU_REG_READ(c, INTF_MISR_CTRL);
+
+ if (!(ctrl & INTF_MISR_CTRL_ENABLE))
+ return -ENODATA;
As the users of collect_misr() are going to ignore the -ENODATA, I think
it would be worth changing this to set *misr_value to 0 and return 0
here. It would reduce the amount of boilerplate code.
+
+ if (!(ctrl & INTF_MISR_CTRL_STATUS))
+ return -EINVAL;
+
+ *misr_value = DPU_REG_READ(c, INTF_MISR_SIGNATURE);
+
+ return 0;
+}
+
static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
unsigned long cap)
{
@@ -329,6 +380,8 @@ static void _setup_intf_ops(struct
dpu_hw_intf_ops *ops,
ops->get_line_count = dpu_hw_intf_get_line_count;
if (cap & BIT(DPU_INTF_INPUT_CTRL))
ops->bind_pingpong_blk = dpu_hw_intf_bind_pingpong_blk;
+ ops->setup_misr = dpu_hw_intf_setup_misr;
+ ops->collect_misr = dpu_hw_intf_collect_misr;
}
struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 7b2d96ac61e8..8d0e7b509260 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -1,5 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#ifndef _DPU_HW_INTF_H
@@ -57,6 +59,8 @@ struct intf_status {
* @ get_line_count: reads current vertical line counter
* @bind_pingpong_blk: enable/disable the connection with pingpong
which will
* feed pixels to this interface
+ * @setup_misr: enable/disable MISR
+ * @collect_misr: read MISR signature
*/
struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
Re: [PATCH v3 0/4] drm/dp: Make DP AUX bus usage easier; use it on ps8640
Hi,
On Tue, May 10, 2022 at 12:30 PM Douglas Anderson wrote:
>
> This patch is v3 of the first 2 patches from my RFC series ("drm/dp:
> Improvements
> for DP AUX channel") [1]. I've broken the series in two so we can make
> progress on the two halves separately.
>
> v2 of this series tries to incorporate all the feedback from v1. Hopefully
> things are less confusing and simpler this time around. The one thing that got
> slightly more confusing is that the done_probing() callback can't return
> -EPROBE_DEFER in most cases so we have to adjust drivers a little more.
>
> v3 takes Dmitry's advice on v2. This now introduces
> devm_drm_bridge_add() (in an extra patch), splits some fixups into
> their own patch, uses a new name for functions, and requires an
> explicit call to done_probing if you have no children.
>
> The idea for this series came up during the review process of
> Sankeerth's series trying to add eDP for Qualcomm SoCs [2].
>
> This _doesn't_ attempt to fix the Analogix driver. If this works out,
> ideally someone can post a patch up to do that.
>
> NOTE: I don't have any ps8640 devices that _don't_ use the aux panel
> underneath them, so I'm relying on code inspection to make sure I
> didn't break those. If someone sees that I did something wrong for
> that case then please yell!
>
> [1] https://lore.kernel.org/r/20220409023628.2104952-1-diand...@chromium.org/
> [2]
> https://lore.kernel.org/r/1648656179-10347-2-git-send-email-quic_sbill...@quicinc.com/
>
> Changes in v3:
> - Adapt to v3 changes in aux bus.
> - Don't call done_probing() if there are no children; return -ENODEV.
> - Patch ("drm/bridge: Add devm_drm_bridge_add()") new for v3.
> - Patch ("drm/dp: Export symbol / kerneldoc fixes...") split for v3.
> - Split out EXPORT_SYMBOL and kerneldoc fixes to its own patch.
> - Use devm_drm_bridge_add() to simplify.
> - Used Dmitry's proposed name: of_dp_aux_populate_bus()
>
> Changes in v2:
> - Change to assume exactly one device.
> - Have a probe callback instead of an extra sub device.
> - Rewrote atop new method introduced by patch #1.
>
> Douglas Anderson (4):
> drm/dp: Export symbol / kerneldoc fixes for DP AUX bus
> drm/dp: Add callbacks to make using DP AUX bus properly easier
> drm/bridge: Add devm_drm_bridge_add()
> drm/bridge: parade-ps8640: Handle DP AUX more properly
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 74 +---
> drivers/gpu/drm/display/drm_dp_aux_bus.c | 211 +++
> drivers/gpu/drm/drm_bridge.c | 23 +++
> include/drm/display/drm_dp_aux_bus.h | 34 +++-
> include/drm/drm_bridge.h | 1 +
> 5 files changed, 238 insertions(+), 105 deletions(-)
I'd previously pushed patch #1. Now I've pushed the rest of the
patches to drm-misc-next with Dmitry's review:
10e619f1f31c drm/bridge: parade-ps8640: Handle DP AUX more properly
50e156bd8a9d drm/bridge: Add devm_drm_bridge_add()
3800b1710946 drm/dp: Add callbacks to make using DP AUX bus properly easier
-Doug
Re: [PATCH 3/6] drm/qxl: Create mouse hotspot properties on cursor planes
Hi Zack,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-tip/drm-tip v5.18 next-20220602]
[cannot apply to airlied/drm-next tegra-drm/drm/tegra/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Zack-Rusin/drm-Add-mouse-cursor-hotspot-support-to-atomic-KMS/20220602-234633
base: git://anongit.freedesktop.org/drm/drm drm-next
config: x86_64-randconfig-a011
(https://download.01.org/0day-ci/archive/20220603/202206030624.tdmarys5-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/0bf2395ee17bd25ae6411c560de883496256195d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Zack-Rusin/drm-Add-mouse-cursor-hotspot-support-to-atomic-KMS/20220602-234633
git checkout 0bf2395ee17bd25ae6411c560de883496256195d
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/qxl/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_apply_cursor':
>> drivers/gpu/drm/qxl/qxl_display.c:486:33: warning: unused variable 'fb'
>> [-Wunused-variable]
486 | struct drm_framebuffer *fb = plane_state->fb;
| ^~
drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_primary_move_cursor':
drivers/gpu/drm/qxl/qxl_display.c:532:33: warning: unused variable 'fb'
[-Wunused-variable]
532 | struct drm_framebuffer *fb = plane_state->fb;
| ^~
vim +/fb +486 drivers/gpu/drm/qxl/qxl_display.c
c2ff663260fee3 Gabriel Krisman Bertazi 2017-02-27 482
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 483 static int
qxl_primary_apply_cursor(struct qxl_device *qdev,
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 484
struct drm_plane_state *plane_state)
9428088c90b6f7 Ray Strode 2017-11-27 485 {
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 @486 struct
drm_framebuffer *fb = plane_state->fb;
b4b27f08f9f96d Gerd Hoffmann 2021-02-17 487 struct qxl_crtc
*qcrtc = to_qxl_crtc(plane_state->crtc);
9428088c90b6f7 Ray Strode 2017-11-27 488 struct
qxl_cursor_cmd *cmd;
9428088c90b6f7 Ray Strode 2017-11-27 489 struct
qxl_release *release;
9428088c90b6f7 Ray Strode 2017-11-27 490 int ret = 0;
9428088c90b6f7 Ray Strode 2017-11-27 491
9428088c90b6f7 Ray Strode 2017-11-27 492 if
(!qcrtc->cursor_bo)
9428088c90b6f7 Ray Strode 2017-11-27 493 return
0;
9428088c90b6f7 Ray Strode 2017-11-27 494
9428088c90b6f7 Ray Strode 2017-11-27 495 ret =
qxl_alloc_release_reserved(qdev, sizeof(*cmd),
9428088c90b6f7 Ray Strode 2017-11-27 496
QXL_RELEASE_CURSOR_CMD,
9428088c90b6f7 Ray Strode 2017-11-27 497
&release, NULL);
9428088c90b6f7 Ray Strode 2017-11-27 498 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 499 return
ret;
9428088c90b6f7 Ray Strode 2017-11-27 500
9428088c90b6f7 Ray Strode 2017-11-27 501 ret =
qxl_release_list_add(release, qcrtc->cursor_bo);
9428088c90b6f7 Ray Strode 2017-11-27 502 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 503 goto
out_free_release;
9428088c90b6f7 Ray Strode 2017-11-27 504
9428088c90b6f7 Ray Strode 2017-11-27 505 ret =
qxl_release_reserve_list(release, false);
9428088c90b6f7 Ray Strode 2017-11-27 506 if (ret)
9428088c90b6f7 Ray Strode 2017-11-27 507 goto
out_free_release;
9428088c90b6f7 Ray Strode 2017-11-27 508
9428088c90b6f7 Ray Strode 2017-11-27 509 cmd = (struct
qxl_cursor_cmd *)qxl_release_map(qdev, release);
9428088c90b6f7 Ray Strode 2017-11-27 510 cmd->type =
QXL_CURSOR_SET;
0bf2395ee17bd2 Zack Rusin 2022-06-02 511
cmd->u.set.position.x = plane_state->crtc_x + plane_state->h
Re: [PATCH] drm/sun4i: sun8i: Add the ability to keep scaler enabled for VI layer
Hi Roman,
On Thu, Jun 02, 2022 at 06:01:18PM +, Roman Stratiienko wrote:
> According to DE2.0/DE3.0 manual VI scaler enable register is double
> buffered, but de facto it doesn't, or the hardware has the shadow
> register latching issues which causes single-frame picture corruption
> after changing the state of scaler enable register.
>
> Allow the user to keep the scaler always enabled, preventing the UI
> glitches on the transition from scaled to unscaled state.
>
> NOTE:
> UI layer scaler has more registers with double-buffering issue and can't
> be workarounded in the same manner.
>
> You may find a python test and a demo video for this issue at [1]
Isn't this an issue with kernel driver not waiting for DE2 FINISH IRQ, but
for VBLANK IRQ from TCON instead, before allowing to write new set of register
values?
https://megous.com/dl/tmp/4fe35b3fc72ee7de.png
I haven't checked if FINISH flag is set at time of VBLANK interrupt, so maybe
this is not the issue.
regards,
o.
> [1]: https://github.com/GloDroid/glodroid_tests/issues/4
> Signed-off-by: Roman Stratiienko
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 12
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 71ab0a00b4de..15cad0330f66 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -27,6 +27,18 @@
> #include "sun8i_vi_layer.h"
> #include "sunxi_engine.h"
>
> +/* According to DE2.0/DE3.0 manual VI scaler enable register is double
> + * buffered, but de facto it doesn't, or the hardware has the shadow
> + * register latching issues which causes single-frame picture corruption
> + * after changing the state of scaler enable register.
> + * Allow the user to keep the scaler always enabled, preventing the UI
> + * glitches on the transition from scaled to unscaled state.
> + */
> +int sun8i_vi_keep_scaler_enabled;
> +MODULE_PARM_DESC(keep_vi_scaler_enabled,
> + "Keep VI scaler enabled (1 = enabled, 0 = disabled
> (default))");
> +module_param_named(keep_vi_scaler_enabled, sun8i_vi_keep_scaler_enabled,
> int, 0644);
> +
> struct de2_fmt_info {
> u32 drm_fmt;
> u32 de2_fmt;
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> index 662ba1018cc4..f005ab883503 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -17,6 +17,8 @@
> #include "sun8i_vi_layer.h"
> #include "sun8i_vi_scaler.h"
>
> +extern int sun8i_vi_keep_scaler_enabled;
> +
> static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer, int channel,
> int overlay, bool enable, unsigned int zpos)
> {
> @@ -149,7 +151,7 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
> *mixer, int channel,
>*/
> subsampled = format->hsub > 1 || format->vsub > 1;
>
> - if (insize != outsize || subsampled || hphase || vphase) {
> + if (insize != outsize || subsampled || hphase || vphase ||
> sun8i_vi_keep_scaler_enabled) {
> unsigned int scanline, required;
> struct drm_display_mode *mode;
> u32 hscale, vscale, fps;
> --
> 2.30.2
>
Re: [PATCH v2 3/8] drm/panel: panel-edp: Implement .get_orientation callback
Hi,
On Wed, Jun 1, 2022 at 2:46 AM Hsin-Yi Wang wrote:
>
> To return the orientation property to drm/kms driver.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Hans de Goede
> ---
> drivers/gpu/drm/panel/panel-edp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 1732b4f56e38..a2133581a72d 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -609,6 +609,13 @@ static int panel_edp_get_timings(struct drm_panel *panel,
> return p->desc->num_timings;
> }
>
> +static enum drm_panel_orientation panel_edp_get_orientation(struct drm_panel
> *panel)
> +{
> + struct panel_edp *p = to_panel_edp(panel);
> +
> + return p->orientation;
> +}
> +
> static int detected_panel_show(struct seq_file *s, void *data)
> {
> struct drm_panel *panel = s->private;
> @@ -637,6 +644,7 @@ static const struct drm_panel_funcs panel_edp_funcs = {
> .prepare = panel_edp_prepare,
> .enable = panel_edp_enable,
> .get_modes = panel_edp_get_modes,
> + .get_orientation = panel_edp_get_orientation,
> .get_timings = panel_edp_get_timings,
> .debugfs_init = panel_edp_debugfs_init,
> };
I'm curious: should we be removing the old
drm_connector_set_panel_orientation() from panel_edp_get_modes()?
...or maybe you want to keep it for now because you're only adding
support to the mediatek driver and for other drivers the WARN_ON is
better than no orientation support at all?
Maybe you could put a comment next to the old
drm_connector_set_panel_orientation() saying that it's deprecated and
that drm drivers are expected to add a call to get_orientation()? Then
when people see the WARN_ON splat they'll quickly figure out how to
fix it. ...and eventually we can probably remove all the old calls
from get_modes() ?
-Doug
Re: [PATCH v2 0/8] Add a panel API to return panel orientation
Hi, On Wed, Jun 1, 2022 at 2:46 AM Hsin-Yi Wang wrote: > > Panels usually call drm_connector_set_panel_orientation(), which is > later than drm/kms driver calling drm_dev_register(). This leads to a > WARN()[1]. > > The orientation property is known earlier. For example, some panels > parse the property through device tree during probe. > > The series add a panel API drm_panel_get_orientation() for drm/kms > drivers. The drivers can use the API to get panel's orientation, so they > can call drm_connector_set_panel_orientation() before drm_dev_register(). > > Panel needs to implement .get_orientation callback to return the property. > > [1] > https://patchwork.kernel.org/project/linux-mediatek/patch/20220530081910.3947168-2-hsi...@chromium.org/ > > Hsin-Yi Wang (8): > drm/panel: Add an API drm_panel_get_orientation() to return panel > orientation > drm/panel: boe-tv101wum-nl6: Implement .get_orientation callback > drm/panel: panel-edp: Implement .get_orientation callback > drm/panel: lvds: Implement .get_orientation callback > drm/panel: panel-simple: Implement .get_orientation callback > drm/panel: ili9881c: Implement .get_orientation callback > drm/panel: elida-kd35t133: Implement .get_orientation callback > drm/mediatek: Config orientation property if panel provides it > > drivers/gpu/drm/drm_panel.c| 8 > drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++ > drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8 > drivers/gpu/drm/panel/panel-edp.c | 8 > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 > drivers/gpu/drm/panel/panel-lvds.c | 8 > drivers/gpu/drm/panel/panel-simple.c | 9 + > include/drm/drm_panel.h| 10 ++ > 9 files changed, 77 insertions(+) Seems reasonable to me. I added a request to the panel-edp patch that probably applies to all of the panel patches requesting a comment next to the old calls in get_modes(). I assume that all but patch #8 ought to land through drm-misc. I'm happy to help commit them once everyone is happy. If the Mediatek maintainer(s) want to Ack patch #8 I can land that in drm-misc too. If we want something fancier like an immutable branch you'll probably have to get someone involved that's got a higher drm pay grade than me. ;-) -Doug
Re: [PATCH v3 0/7] drm/msm: clean up the hw catalog init
On 02/06/2022 23:24, Abhinav Kumar wrote: On 6/2/2022 1:22 PM, Dmitry Baryshkov wrote: Replace superfluous cfg_init functions, which just assign a static config to the struct dpu_mdss_cfg, with static instances of struct dpu_mdss_cfg. Changes since v2: - Add DPU_MIXER_COMBINED_ALPHA to sc7180's mixer features mask (noted by Abhinav). Changes since v1: - Turn catalog->perf and catalog->dma_cfg to be pointers, otherwise clang complains that they are not constant. I see you have dropped the R-bs from all the changes in V2. Can you please add them back? Yes, I missed that in v3. Should be fixed in v4. Dmitry Baryshkov (7): drm/msm/dpu: use feature bit for LM combined alpha check drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog drm/msm/dpu: remove hwversion field from data structures drm/msm/dpu: change catalog->perf to be a const pointer drm/msm/dpu: change catalog->dma_cfg to be a const pointer drm/msm/dpu: constify struct dpu_mdss_cfg drm/msm/dpu: make dpu hardware catalog static const drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 24 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 502 -- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 7 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c | 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +- 27 files changed, 283 insertions(+), 359 deletions(-) -- With best wishes Dmitry
[PATCH 2/3] drm/amdgpu/dm/mst: Stop grabbing mst_mgr->lock in pre_compute_mst_dsc_configs_for_state()
This lock is only needed if you're iterating through the in-memory topology
(e.g. drm_dp_mst_branch->ports, drm_dp_mst_port->mstb, etc.). This doesn't
actually seem to be what's going on here though, so we can just drop this
lock.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index cb3b0e08acc4..1259f2f7a8f9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -1112,16 +1112,12 @@ static bool
if (!is_dsc_need_re_compute(state, dc_state, stream->link))
continue;
- mutex_lock(&aconnector->mst_mgr.lock);
if (!compute_mst_dsc_configs_for_link(state,
dc_state,
stream->link,
vars,
- &link_vars_start_index)) {
- mutex_unlock(&aconnector->mst_mgr.lock);
+ &link_vars_start_index))
return false;
- }
- mutex_unlock(&aconnector->mst_mgr.lock);
for (j = 0; j < dc_state->stream_count; j++) {
if (dc_state->streams[j]->link == stream->link)
--
2.35.3
[PATCH 3/3] drm/amdgpu/dm: Drop != NULL check in dm_mst_get_pbn_divider()
A lot of code in amdgpu seems to sprinkle in
if (foo != NULL)
…
Checks pretty much all over the place, many times in locations where it's
clear foo (whatever foo may be) should never be NULL unless we've run into
a programming error. This is definitely one of those places, as
dm_mst_get_pbn_divider() should never be getting called with a NULL dc_link
pointer.
The problem with this code pattern is that many times the places I've seen
it used in amdgpu have no real error handling. This is actually quite bad,
if we try to avoid the NULL pointer and instead simply skip any code that
was expecting a valid pointer - we're already in undefined territory.
Subsequent code we execute may have expected sideaffects from the code we
skipped that are no longer present, which leads to even more unpredictable
behavior then a simple segfault. This could be silent errors or even just
another segfault somewhere else.
If we simply segfault though, that's not good either. But unlike the former
solution, no subsequent code in the kernel thread will execute - and we
will likely even get a clear backtrace from the invalid memory access. Of
course, the preferred approach is to simply handle the possibility of both
NULL and non-NULL pointers with nice error handling code. However, that's
not always desirable or even possible, and in those cases it's likely just
better to fail predictably rather than unpredictably.
This code is a nice example of that - if link is NULL, you'll return a PBN
divisor of 0. And thus, you've simply traded in your potential segfault for
a potential divide by 0 error. This was something I actually managed to hit
while working on the legacy MST removal work.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 1259f2f7a8f9..35c7def8f2bd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -537,9 +537,6 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
int dm_mst_get_pbn_divider(struct dc_link *link)
{
- if (!link)
- return 0;
-
return dc_link_bandwidth_kbps(link,
dc_link_get_link_cap(link)) / (8 * 1000 * 54);
}
--
2.35.3
[PATCH 1/3] drm/amdgpu/dm/mst: Stop grabbing mst_mgr->lock in compute_mst_dsc_configs_for_state()
Noticed this while trying to update amdgpu for the non-atomic MST removal
changes - for some reason we appear to grab mst_mgr->lock before computing
mst DSC configs. This is wrong though - mst_mgr->lock is only needed while
traversing the actual MST topology state - which is not typically something
that DRM drivers should be doing themselves anyway.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9221b6690a4a..cb3b0e08acc4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -1056,13 +1056,10 @@ bool compute_mst_dsc_configs_for_state(struct
drm_atomic_state *state,
if (!is_dsc_need_re_compute(state, dc_state, stream->link))
continue;
- mutex_lock(&aconnector->mst_mgr.lock);
if (!compute_mst_dsc_configs_for_link(state, dc_state,
stream->link,
vars, &link_vars_start_index)) {
- mutex_unlock(&aconnector->mst_mgr.lock);
return false;
}
- mutex_unlock(&aconnector->mst_mgr.lock);
for (j = 0; j < dc_state->stream_count; j++) {
if (dc_state->streams[j]->link == stream->link)
--
2.35.3
Re: [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Wed, Jun 01, 2022 at 07:13:16PM -0700, Zeng, Oak wrote: Regards, Oak -Original Message- From: dri-devel On Behalf Of Niranjana Vishwanathapura Sent: May 17, 2022 2:32 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Vetter, Daniel Cc: Brost, Matthew ; Hellstrom, Thomas ; ja...@jlekstrand.net; Wilson, Chris P ; christian.koe...@amd.com Subject: [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document VM_BIND design document with description of intended use cases. v2: Add more documentation and format as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura --- Documentation/driver-api/dma-buf.rst | 2 + Documentation/gpu/rfc/i915_vm_bind.rst | 304 + Documentation/gpu/rfc/index.rst| 4 + 3 files changed, 310 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver- api/dma-buf.rst index 36a76cbe9095..64cb924ec5bb 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -200,6 +200,8 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +.. _indefinite_dma_fences: + Indefinite DMA Fences ~ diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..f1be560d313c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,304 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuff calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuff mode). + +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace +to specify how the binding/unbinding should sync with other operations +like the GPU job submission. These fences will be timeline 'drm_syncobj's +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). +For Compute contexts, they will be user/memory fences (See struct +drm_i915_vm_bind_ext_user_fence). + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. Hi, Is user required to wait for the out fence be signaled before submit a gpu job using the vm_bind address? Or is user required to order the gpu job to make gpu job run after vm_bind out fence signaled? Thanks Oak, Either should be fine and up to user how to use vm_bind/unbind out-fence. I think there could be different behavior on a non-faultable platform and a faultable platform, such as on a non-faultable Platform, gpu job is required to be order after vm_bind out fence signaling; and on a faultable platform, there is no such Restriction since vm bind can be finished in the fault handler? With GPU page faults handler, out fence won't be needed as residency is purely managed by page fault handler populating page tables (there is a mention of it in GPU Page Faults section below). Should we document such thing? We don't talk much about GPU page faults case in this document as that may warrent a separate rfc when we add page faults support. We did mention it in couple places to ensure our locking design here is extensible to gpu page faults case. Niranjana Regards, Oak + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuff ioctl in VM_BIND mode +--- +The execbuff ioctl handling in VM_BIND mode differs signifi
Re: [PATCH 2/3] drm/display/dp_mst: Fix drm_atomic_get_mst_topology_state()
On Thu, 2022-06-02 at 23:42 +0300, Ville Syrjälä wrote:
> On Thu, Jun 02, 2022 at 04:17:56PM -0400, Lyude Paul wrote:
> > I noticed a rather surprising issue here while working on removing all of
> > the non-atomic MST code: drm_atomic_get_mst_topology_state() doesn't check
> > the return value of drm_atomic_get_private_obj_state() and instead just
> > passes it directly to to_dp_mst_topology_state(). This means that if we
> > hit a deadlock or something else which would return an error code pointer,
> > we'll likely segfault the kernel.
> >
> > This is definitely another one of those fixes where I'm astonished we
> > somehow managed never to discover this issue until now…
>
> It has been discussed before.
>
> struct drm_dp_mst_topology_state {
> struct drm_private_state base;
> ...
> }
>
> so offsetof(base)==0.
fhjdffds yes you're right, I guess we can just drop this patch then
>
> >
> > Signed-off-by: Lyude Paul
> > Fixes: a4370c777406 ("drm/atomic: Make private objs proper objects")
> > Cc: Ville Syrjälä
> > Cc: # v4.14+
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> > include/drm/display/drm_dp_mst_helper.h | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index d84673b3294b..d6e595b95f07 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -5468,7 +5468,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
> > struct drm_dp_mst_topology_state
> > *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
> > struct
> > drm_dp_mst_topology_mgr *mgr)
> > {
> > - return
> > to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, &mgr-
> > >base));
> > + return
> > to_dp_mst_topology_state_safe(drm_atomic_get_private_obj_state(state,
> > &mgr->base));
> > }
> > EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
> >
> > diff --git a/include/drm/display/drm_dp_mst_helper.h
> > b/include/drm/display/drm_dp_mst_helper.h
> > index 10adec068b7f..fe7577e7f305 100644
> > --- a/include/drm/display/drm_dp_mst_helper.h
> > +++ b/include/drm/display/drm_dp_mst_helper.h
> > @@ -541,6 +541,8 @@ struct drm_dp_payload {
> > };
> >
> > #define to_dp_mst_topology_state(x) container_of(x, struct
> > drm_dp_mst_topology_state, base)
> > +#define to_dp_mst_topology_state_safe(x) \
> > + container_of_safe(x, struct drm_dp_mst_topology_state, base)
>
> Wasn't aware of container_of_safe(). I suppose no real harm
> in using it. Not sure why we'd even keep the non-safe version
> around?
>
> Though the use of container_of_safe() everywhere won't help
> when "casting" the other way (&foo->base, when foo==NULL/errptr).
> In order to make that work for non-zero offsets we'd have to
> introduce a casting macro for that direction as well.
>
> >
> > struct drm_dp_vcpi_allocation {
> > struct drm_dp_mst_port *port;
> > --
> > 2.35.3
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH 2/3] drm/display/dp_mst: Fix drm_atomic_get_mst_topology_state()
On Thu, Jun 02, 2022 at 04:17:56PM -0400, Lyude Paul wrote:
> I noticed a rather surprising issue here while working on removing all of
> the non-atomic MST code: drm_atomic_get_mst_topology_state() doesn't check
> the return value of drm_atomic_get_private_obj_state() and instead just
> passes it directly to to_dp_mst_topology_state(). This means that if we
> hit a deadlock or something else which would return an error code pointer,
> we'll likely segfault the kernel.
>
> This is definitely another one of those fixes where I'm astonished we
> somehow managed never to discover this issue until now…
It has been discussed before.
struct drm_dp_mst_topology_state {
struct drm_private_state base;
...
}
so offsetof(base)==0.
>
> Signed-off-by: Lyude Paul
> Fixes: a4370c777406 ("drm/atomic: Make private objs proper objects")
> Cc: Ville Syrjälä
> Cc: # v4.14+
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index d84673b3294b..d6e595b95f07 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -5468,7 +5468,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
> struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
> drm_atomic_state *state,
> struct
> drm_dp_mst_topology_mgr *mgr)
> {
> - return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
> &mgr->base));
> + return
> to_dp_mst_topology_state_safe(drm_atomic_get_private_obj_state(state,
> &mgr->base));
> }
> EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
>
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 10adec068b7f..fe7577e7f305 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -541,6 +541,8 @@ struct drm_dp_payload {
> };
>
> #define to_dp_mst_topology_state(x) container_of(x, struct
> drm_dp_mst_topology_state, base)
> +#define to_dp_mst_topology_state_safe(x) \
> + container_of_safe(x, struct drm_dp_mst_topology_state, base)
Wasn't aware of container_of_safe(). I suppose no real harm
in using it. Not sure why we'd even keep the non-safe version
around?
Though the use of container_of_safe() everywhere won't help
when "casting" the other way (&foo->base, when foo==NULL/errptr).
In order to make that work for non-zero offsets we'd have to
introduce a casting macro for that direction as well.
>
> struct drm_dp_vcpi_allocation {
> struct drm_dp_mst_port *port;
> --
> 2.35.3
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Thu, Jun 2, 2022 at 3:11 PM Niranjana Vishwanathapura < niranjana.vishwanathap...@intel.com> wrote: > On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew Brost wrote: > >On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > >> On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > >> > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the > mapping in an > >> > +async worker. The binding and unbinding will work like a special GPU > engine. > >> > +The binding and unbinding operations are serialized and will wait on > specified > >> > +input fences before the operation and will signal the output fences > upon the > >> > +completion of the operation. Due to serialization, completion of an > operation > >> > +will also indicate that all previous operations are also complete. > >> > >> I guess we should avoid saying "will immediately start > binding/unbinding" if > >> there are fences involved. > >> > >> And the fact that it's happening in an async worker seem to imply it's > not > >> immediate. > >> > > Ok, will fix. > This was added because in earlier design binding was deferred until next > execbuff. > But now it is non-deferred (immediate in that sense). But yah, this is > confusing > and will fix it. > > >> > >> I have a question on the behavior of the bind operation when no input > fence > >> is provided. Let say I do : > >> > >> VM_BIND (out_fence=fence1) > >> > >> VM_BIND (out_fence=fence2) > >> > >> VM_BIND (out_fence=fence3) > >> > >> > >> In what order are the fences going to be signaled? > >> > >> In the order of VM_BIND ioctls? Or out of order? > >> > >> Because you wrote "serialized I assume it's : in order > >> > > Yes, in the order of VM_BIND/UNBIND ioctls. Note that bind and unbind will > use > the same queue and hence are ordered. > > >> > >> One thing I didn't realize is that because we only get one "VM_BIND" > engine, > >> there is a disconnect from the Vulkan specification. > >> > >> In Vulkan VM_BIND operations are serialized but per engine. > >> > >> So you could have something like this : > >> > >> VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > >> > >> VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > >> > >> > >> fence1 is not signaled > >> > >> fence3 is signaled > >> > >> So the second VM_BIND will proceed before the first VM_BIND. > >> > >> > >> I guess we can deal with that scenario in userspace by doing the wait > >> ourselves in one thread per engines. > >> > >> But then it makes the VM_BIND input fences useless. > >> > >> > >> Daniel : what do you think? Should be rework this or just deal with wait > >> fences in userspace? > >> > > > >My opinion is rework this but make the ordering via an engine param > optional. > > > >e.g. A VM can be configured so all binds are ordered within the VM > > > >e.g. A VM can be configured so all binds accept an engine argument (in > >the case of the i915 likely this is a gem context handle) and binds > >ordered with respect to that engine. > > > >This gives UMDs options as the later likely consumes more KMD resources > >so if a different UMD can live with binds being ordered within the VM > >they can use a mode consuming less resources. > > > > I think we need to be careful here if we are looking for some out of > (submission) order completion of vm_bind/unbind. > In-order completion means, in a batch of binds and unbinds to be > completed in-order, user only needs to specify in-fence for the > first bind/unbind call and the our-fence for the last bind/unbind > call. Also, the VA released by an unbind call can be re-used by > any subsequent bind call in that in-order batch. > > These things will break if binding/unbinding were to be allowed to > go out of order (of submission) and user need to be extra careful > not to run into pre-mature triggereing of out-fence and bind failing > as VA is still in use etc. > > Also, VM_BIND binds the provided mapping on the specified address space > (VM). So, the uapi is not engine/context specific. > > We can however add a 'queue' to the uapi which can be one from the > pre-defined queues, > I915_VM_BIND_QUEUE_0 > I915_VM_BIND_QUEUE_1 > ... > I915_VM_BIND_QUEUE_(N-1) > > KMD will spawn an async work queue for each queue which will only > bind the mappings on that queue in the order of submission. > User can assign the queue to per engine or anything like that. > > But again here, user need to be careful and not deadlock these > queues with circular dependency of fences. > > I prefer adding this later an as extension based on whether it > is really helping with the implementation. > I can tell you right now that having everything on a single in-order queue will not get us the perf we want. What vulkan really wants is one of two things: 1. No implicit ordering of VM_BIND ops. They just happen in whatever their dependencies are resolved and we ensure ordering ourselves by having a syncobj in the VkQueue. 2. The ability to create multiple VM_BIND queues.
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Thu, Jun 02, 2022 at 09:22:46AM -0700, Matthew Brost wrote: On Thu, Jun 02, 2022 at 08:42:13AM +0300, Lionel Landwerlin wrote: On 02/06/2022 00:18, Matthew Brost wrote: > On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > > On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > > > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an > > > +async worker. The binding and unbinding will work like a special GPU engine. > > > +The binding and unbinding operations are serialized and will wait on specified > > > +input fences before the operation and will signal the output fences upon the > > > +completion of the operation. Due to serialization, completion of an operation > > > +will also indicate that all previous operations are also complete. > > I guess we should avoid saying "will immediately start binding/unbinding" if > > there are fences involved. > > > > And the fact that it's happening in an async worker seem to imply it's not > > immediate. > > > > > > I have a question on the behavior of the bind operation when no input fence > > is provided. Let say I do : > > > > VM_BIND (out_fence=fence1) > > > > VM_BIND (out_fence=fence2) > > > > VM_BIND (out_fence=fence3) > > > > > > In what order are the fences going to be signaled? > > > > In the order of VM_BIND ioctls? Or out of order? > > > > Because you wrote "serialized I assume it's : in order > > > > > > One thing I didn't realize is that because we only get one "VM_BIND" engine, > > there is a disconnect from the Vulkan specification. > > > > In Vulkan VM_BIND operations are serialized but per engine. > > > > So you could have something like this : > > > > VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > > > > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > > Question - let's say this done after the above operations: > > EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) > > Is the exec ordered with respected to bind (i.e. would fence3 & 4 be > signaled before the exec starts)? > > Matt Hi Matt, From the vulkan point of view, everything is serialized within an engine (we map that to a VkQueue). So with : EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) EXEC completes first then VM_BIND executes. To be even clearer : EXEC (engine=ccs0, in_fence=fence2, out_fence=NULL) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) EXEC will wait until fence2 is signaled. Once fence2 is signaled, EXEC proceeds, finishes and only after it is done, VM_BIND executes. It would kind of like having the VM_BIND operation be another batch executed from the ringbuffer buffer. Yea this makes sense. I think of VM_BINDs as more or less just another version of an EXEC and this fits with that. Note that VM_BIND itself can bind while and EXEC (GPU job) is running. (Say, getting binds ready for next submission). It is up to user though, how to use it. In practice I don't think we can share a ring but we should be able to present an engine (again likely a gem context in i915) to the user that orders VM_BINDs / EXECs if that is what Vulkan expects, at least I think. I have responded in the other thread on this. Niranjana Hopefully Niranjana + Daniel agree. Matt -Lionel > > > fence1 is not signaled > > > > fence3 is signaled > > > > So the second VM_BIND will proceed before the first VM_BIND. > > > > > > I guess we can deal with that scenario in userspace by doing the wait > > ourselves in one thread per engines. > > > > But then it makes the VM_BIND input fences useless. > > > > > > Daniel : what do you think? Should be rework this or just deal with wait > > fences in userspace? > > > > > > Sorry I noticed this late. > > > > > > -Lionel > > > >
[PATCH v4 6/7] drm/msm/dpu: constify struct dpu_mdss_cfg
Mark struct dpu_mdss_cfg instance as a const pointer. This is mostly a
preparation for the next patch.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 9 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
17 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 31767d0f7353..1d9d83d7b99e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -468,7 +468,7 @@ static const struct file_operations dpu_core_perf_mode_fops
= {
int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
{
struct dpu_core_perf *perf = &dpu_kms->perf;
- struct dpu_mdss_cfg *catalog = perf->catalog;
+ const struct dpu_mdss_cfg *catalog = perf->catalog;
struct dentry *entry;
entry = debugfs_create_dir("core_perf", parent);
@@ -517,7 +517,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk)
{
perf->dev = dev;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 8dfcc6db7176..e3795995e145 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -68,7 +68,7 @@ struct dpu_core_perf_tune {
struct dpu_core_perf {
struct drm_device *dev;
struct dentry *debugfs_root;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
struct clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -119,7 +119,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk);
struct dpu_kms;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 52516eb20cb8..460df2a4831c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1207,7 +1207,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
mutex_unlock(&dpu_enc->enc_lock);
}
-static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
+static enum dpu_intf dpu_encoder_get_intf(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
@@ -1224,7 +1224,7 @@ static enum dpu_intf dpu_encoder_get_intf(struct
dpu_mdss_cfg *catalog,
return INTF_MAX;
}
-static enum dpu_wb dpu_encoder_get_wb(struct dpu_mdss_cfg *catalog,
+static enum dpu_wb dpu_encoder_get_wb(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 1e4a4822fbf4..4088c9e17d50 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -103,7 +103,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
{
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cca3b3a0c231..1c40307af0ec 100644
--- a/drivers/gpu/drm/msm/d
[PATCH v4 7/7] drm/msm/dpu: make dpu hardware catalog static const
Replace superfluous cfg_init functions, which just assign a static
config to the struct dpu_mdss_cfg, with static instances of struct
dpu_mdss_cfg.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 475 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 213 insertions(+), 269 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 1c40307af0ec..6d52db450e42 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1722,283 +1722,228 @@ static const struct dpu_perf_cfg qcm2290_perf_data = {
.bw_inefficiency_factor = 120,
};
/*
- * Hardware catalog init
+ * Hardware catalog
*/
-/*
- * msm8998_cfg_init(): populate sdm845 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void msm8998_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &msm8998_dpu_caps,
- .mdp_count = ARRAY_SIZE(msm8998_mdp),
- .mdp = msm8998_mdp,
- .ctl_count = ARRAY_SIZE(msm8998_ctl),
- .ctl = msm8998_ctl,
- .sspp_count = ARRAY_SIZE(msm8998_sspp),
- .sspp = msm8998_sspp,
- .mixer_count = ARRAY_SIZE(msm8998_lm),
- .mixer = msm8998_lm,
- .dspp_count = ARRAY_SIZE(msm8998_dspp),
- .dspp = msm8998_dspp,
- .pingpong_count = ARRAY_SIZE(sdm845_pp),
- .pingpong = sdm845_pp,
- .intf_count = ARRAY_SIZE(msm8998_intf),
- .intf = msm8998_intf,
- .vbif_count = ARRAY_SIZE(msm8998_vbif),
- .vbif = msm8998_vbif,
- .reg_dma_count = 0,
- .perf = &msm8998_perf_data,
- .mdss_irqs = IRQ_SM8250_MASK,
- };
-}
-
-/*
- * sdm845_cfg_init(): populate sdm845 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sdm845_dpu_caps,
- .mdp_count = ARRAY_SIZE(sdm845_mdp),
- .mdp = sdm845_mdp,
- .ctl_count = ARRAY_SIZE(sdm845_ctl),
- .ctl = sdm845_ctl,
- .sspp_count = ARRAY_SIZE(sdm845_sspp),
- .sspp = sdm845_sspp,
- .mixer_count = ARRAY_SIZE(sdm845_lm),
- .mixer = sdm845_lm,
- .pingpong_count = ARRAY_SIZE(sdm845_pp),
- .pingpong = sdm845_pp,
- .dsc_count = ARRAY_SIZE(sdm845_dsc),
- .dsc = sdm845_dsc,
- .intf_count = ARRAY_SIZE(sdm845_intf),
- .intf = sdm845_intf,
- .vbif_count = ARRAY_SIZE(sdm845_vbif),
- .vbif = sdm845_vbif,
- .reg_dma_count = 1,
- .dma_cfg = &sdm845_regdma,
- .perf = &sdm845_perf_data,
- .mdss_irqs = IRQ_SDM845_MASK,
- };
-}
-
-/*
- * sc7180_cfg_init(): populate sc7180 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sc7180_dpu_caps,
- .mdp_count = ARRAY_SIZE(sc7180_mdp),
- .mdp = sc7180_mdp,
- .ctl_count = ARRAY_SIZE(sc7180_ctl),
- .ctl = sc7180_ctl,
- .sspp_count = ARRAY_SIZE(sc7180_sspp),
- .sspp = sc7180_sspp,
- .mixer_count = ARRAY_SIZE(sc7180_lm),
- .mixer = sc7180_lm,
- .dspp_count = ARRAY_SIZE(sc7180_dspp),
- .dspp = sc7180_dspp,
- .pingpong_count = ARRAY_SIZE(sc7180_pp),
- .pingpong = sc7180_pp,
- .intf_count = ARRAY_SIZE(sc7180_intf),
- .intf = sc7180_intf,
- .vbif_count = ARRAY_SIZE(sdm845_vbif),
- .vbif = sdm845_vbif,
- .reg_dma_count = 1,
- .dma_cfg = &sdm845_regdma,
- .perf = &sc7180_perf_data,
- .mdss_irqs = IRQ_SC7180_MASK,
- };
-}
-
-/*
- * sm8150_cfg_init(): populate sm8150 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sm8150_dpu_caps,
- .mdp_count = ARRAY_SIZE(sdm845_mdp),
- .mdp = sdm845_mdp,
- .ctl_count = ARRAY_SIZE(sm8150_ctl),
- .ctl = sm8150_ctl,
- .sspp_count = ARRAY_SIZE(sdm845_sspp),
- .sspp = sdm845_sspp,
- .mixer_count = ARRAY_SIZE(sm8150_lm
[PATCH v4 1/7] drm/msm/dpu: use feature bit for LM combined alpha check
Rather than checking hwversion, follow the usual patter and add special
bit to the lm->features to check whether the LM has combined or separate
alpha registers. While we are at it, rename
dpu_hw_lm_setup_blend_config_sdm845() to
dpu_hw_lm_setup_blend_config_combined_alpha().
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 19 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 +++---
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 400ebceb56bb..c3759fc4b154 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -50,11 +50,14 @@
#define DMA_CURSOR_MSM8998_MASK \
(DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
-#define MIXER_SDM845_MASK \
+#define MIXER_MSM8998_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
+#define MIXER_SDM845_MASK \
+ (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
BIT(DPU_MIXER_COMBINED_ALPHA))
+
#define MIXER_SC7180_MASK \
- (BIT(DPU_DIM_LAYER))
+ (BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
@@ -936,17 +939,17 @@ static const struct dpu_lm_sub_blks msm8998_lm_sblk = {
};
static const struct dpu_lm_cfg msm8998_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_0, LM_2, DSPP_0),
- LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_1, LM_5, DSPP_1),
- LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_2, LM_0, 0),
- LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_3, LM_1, 0),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8cb6d1f25bf9..80bc09b1f1b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -145,6 +145,7 @@ enum {
* @DPU_MIXER_SOURCESPLIT Layer mixer supports source-split configuration
* @DPU_MIXER_GC Gamma correction block
* @DPU_DIM_LAYER Layer mixer supports dim layer
+ * @DPU_MIXER_COMBINED_ALPHA Layer mixer has combined alpha register
* @DPU_MIXER_MAX maximum value
*/
enum {
@@ -152,6 +153,7 @@ enum {
DPU_MIXER_SOURCESPLIT,
DPU_MIXER_GC,
DPU_DIM_LAYER,
+ DPU_MIXER_COMBINED_ALPHA,
DPU_MIXER_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 462f5082099e..25d2eba28e71 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -148,7 +148,7 @@ static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer *ctx,
u32 *misr_value)
return 0;
}
-static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
+static void dpu_hw_lm_setup_blend_config_combined_alpha(struct dpu_hw_mixer
*ctx,
u32 stage, u32 fg_alpha, u32 bg_alpha, u32 blend_op)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -204,8 +204,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (m->hwversion >= DPU_HW_VER_400)
- ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
+ if (test_bit(DPU_MIXER_COMBINED_ALPHA, &features))
+ ops->setup_blend_config =
dpu_hw_lm_setup_blend_config_combined_alpha;
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
--
2.35.1
[PATCH v4 3/7] drm/msm/dpu: remove hwversion field from data structures
The driver should not depend on hw revision for detecting features.
Instead it should use features from the hw catalog. Drop the hwversion
field from struct dpu_mdss_cfg and struct dpu_hw_blk_reg_map.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 -
15 files changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 101d9abe652b..355c7aa82582 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2002,7 +2002,6 @@ struct dpu_mdss_cfg *dpu_hw_catalog_init(u32 hw_rev)
for (i = 0; i < ARRAY_SIZE(cfg_handler); i++) {
if (cfg_handler[i].hw_rev == hw_rev) {
cfg_handler[i].cfg_init(dpu_cfg);
- dpu_cfg->hwversion = hw_rev;
return dpu_cfg;
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index f70de97f492a..4225f58d8f97 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -826,8 +826,6 @@ struct dpu_perf_cfg {
* @mdss_irqs: Bitmap with the irqs supported by the target
*/
struct dpu_mdss_cfg {
- u32 hwversion;
-
const struct dpu_caps *caps;
u32 mdp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index c33e7ef611a6..7d416bf4ae91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -61,7 +61,6 @@ static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
b->base_off = addr;
b->blk_off = m->ctl[i].base;
b->length = m->ctl[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_CTL;
return &m->ctl[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4ad8991fc7d9..6f20d6b6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -169,7 +169,6 @@ static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
b->base_off = addr;
b->blk_off = m->dsc[i].base;
b->length = m->dsc[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSC;
return &m->dsc[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 355894a3b48c..3e63bf4fa64e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -83,7 +83,6 @@ static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp
dspp,
b->base_off = addr;
b->blk_off = m->dspp[i].base;
b->length = m->dspp[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSPP;
return &m->dspp[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 61284e6c313d..01bb2d84c3a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -403,7 +403,6 @@ static void __intr_offset(struct dpu_mdss_cfg *m,
{
hw->base_off = addr;
hw->blk_off = m->mdp[0].base;
- hw->hwversion = m->hwversion;
}
struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..b2ca8d19fdd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -80,7 +80,6 @@ static const struct dpu_intf_cfg *_intf
[PATCH v4 5/7] drm/msm/dpu: change catalog->dma_cfg to be a const pointer
Change dpu_mdss_cfg::dma_cfg to be a const pointer rather than embedding
the dpu_reg_dma_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 95b3ecc4db60..cca3b3a0c231 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1780,7 +1780,7 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sdm845_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1811,7 +1811,7 @@ static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sc7180_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
@@ -1844,7 +1844,7 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sm8150_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1875,7 +1875,7 @@ static void sc8180x_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sc8180x_perf_data,
.mdss_irqs = IRQ_SC8180X_MASK,
};
@@ -1910,7 +1910,7 @@ static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.wb_count = ARRAY_SIZE(sm8250_wb),
.wb = sm8250_wb,
.reg_dma_count = 1,
- .dma_cfg = sm8250_regdma,
+ .dma_cfg = &sm8250_regdma,
.perf = &sm8250_perf_data,
.mdss_irqs = IRQ_SM8250_MASK,
};
@@ -1965,7 +1965,7 @@ static void qcm2290_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &qcm2290_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 64ed96b2fa3d..60b403ac9f0f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -859,7 +859,7 @@ struct dpu_mdss_cfg {
const struct dpu_wb_cfg *wb;
u32 reg_dma_count;
- struct dpu_reg_dma_cfg dma_cfg;
+ const struct dpu_reg_dma_cfg *dma_cfg;
u32 ad_count;
--
2.35.1
Re: [PATCH v3 0/7] drm/msm: clean up the hw catalog init
On 6/2/2022 1:22 PM, Dmitry Baryshkov wrote: Replace superfluous cfg_init functions, which just assign a static config to the struct dpu_mdss_cfg, with static instances of struct dpu_mdss_cfg. Changes since v2: - Add DPU_MIXER_COMBINED_ALPHA to sc7180's mixer features mask (noted by Abhinav). Changes since v1: - Turn catalog->perf and catalog->dma_cfg to be pointers, otherwise clang complains that they are not constant. I see you have dropped the R-bs from all the changes in V2. Can you please add them back? Dmitry Baryshkov (7): drm/msm/dpu: use feature bit for LM combined alpha check drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog drm/msm/dpu: remove hwversion field from data structures drm/msm/dpu: change catalog->perf to be a const pointer drm/msm/dpu: change catalog->dma_cfg to be a const pointer drm/msm/dpu: constify struct dpu_mdss_cfg drm/msm/dpu: make dpu hardware catalog static const drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 24 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 502 -- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 7 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 2 +- 27 files changed, 283 insertions(+), 359 deletions(-)
[PATCH v4 0/7] drm/msm: clean up the hw catalog init
Replace superfluous cfg_init functions, which just assign a static config to the struct dpu_mdss_cfg, with static instances of struct dpu_mdss_cfg. Changes since v3: - Add missed Reviewed-by tags by Abhinav. Changes since v2: - Add DPU_MIXER_COMBINED_ALPHA to sc7180's mixer features mask (noted by Abhinav). Changes since v1: - Turn catalog->perf and catalog->dma_cfg to be pointers, otherwise clang complains that they are not constant. Dmitry Baryshkov (7): drm/msm/dpu: use feature bit for LM combined alpha check drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog drm/msm/dpu: remove hwversion field from data structures drm/msm/dpu: change catalog->perf to be a const pointer drm/msm/dpu: change catalog->dma_cfg to be a const pointer drm/msm/dpu: constify struct dpu_mdss_cfg drm/msm/dpu: make dpu hardware catalog static const drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 24 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 502 -- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 7 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 2 +- 27 files changed, 283 insertions(+), 359 deletions(-) -- 2.35.1
[PATCH v4 4/7] drm/msm/dpu: change catalog->perf to be a const pointer
Change dpu_mdss_cfg::perf to be a const pointer rather than embedding
the dpu_perf_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 20 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 16 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 -
5 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index a7492dd6ed65..31767d0f7353 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -53,7 +53,7 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
crtc_plane_bw += pstate->plane_fetch_bw;
}
- bw_factor = kms->catalog->perf.bw_inefficiency_factor;
+ bw_factor = kms->catalog->perf->bw_inefficiency_factor;
if (bw_factor) {
crtc_plane_bw *= bw_factor;
do_div(crtc_plane_bw, 100);
@@ -90,7 +90,7 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
crtc_clk = max(pstate->plane_clk, crtc_clk);
}
- clk_factor = kms->catalog->perf.clk_inefficiency_factor;
+ clk_factor = kms->catalog->perf->clk_inefficiency_factor;
if (clk_factor) {
crtc_clk *= clk_factor;
do_div(crtc_clk, 100);
@@ -128,7 +128,7 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
} else {
perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
- perf->max_per_pipe_ib = kms->catalog->perf.min_dram_ib;
+ perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
@@ -189,7 +189,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
bw = DIV_ROUND_UP_ULL(bw_sum_of_intfs, 1000);
DRM_DEBUG_ATOMIC("calculated bandwidth=%uk\n", bw);
- threshold = kms->catalog->perf.max_bw_high;
+ threshold = kms->catalog->perf->max_bw_high;
DRM_DEBUG_ATOMIC("final threshold bw limit = %d\n", threshold);
@@ -413,7 +413,7 @@ static ssize_t _dpu_core_perf_mode_write(struct file *file,
const char __user *user_buf, size_t count, loff_t *ppos)
{
struct dpu_core_perf *perf = file->private_data;
- struct dpu_perf_cfg *cfg = &perf->catalog->perf;
+ const struct dpu_perf_cfg *cfg = perf->catalog->perf;
u32 perf_mode = 0;
int ret;
@@ -480,15 +480,15 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms,
struct dentry *parent)
debugfs_create_u32("enable_bw_release", 0600, entry,
(u32 *)&perf->enable_bw_release);
debugfs_create_u32("threshold_low", 0600, entry,
- (u32 *)&catalog->perf.max_bw_low);
+ (u32 *)&catalog->perf->max_bw_low);
debugfs_create_u32("threshold_high", 0600, entry,
- (u32 *)&catalog->perf.max_bw_high);
+ (u32 *)&catalog->perf->max_bw_high);
debugfs_create_u32("min_core_ib", 0600, entry,
- (u32 *)&catalog->perf.min_core_ib);
+ (u32 *)&catalog->perf->min_core_ib);
debugfs_create_u32("min_llcc_ib", 0600, entry,
- (u32 *)&catalog->perf.min_llcc_ib);
+ (u32 *)&catalog->perf->min_llcc_ib);
debugfs_create_u32("min_dram_ib", 0600, entry,
- (u32 *)&catalog->perf.min_dram_ib);
+ (u32 *)&catalog->perf->min_dram_ib);
debugfs_create_file("perf_mode", 0600, entry,
(u32 *)perf, &dpu_core_perf_mode_fops);
debugfs_create_u64("fix_core_clk_rate", 0600, entry,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 4829d1ce0cf8..1e4a4822fbf4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -104,7 +104,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
struct dpu_mdss_cfg *catalog;
- struct dpu_qos_lut_tbl *qos_lut_tb;
+ const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
DPU_ERROR("invalid parameter(s)\n");
@@ -118,11 +118,11 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
memset(&qos_cfg, 0, s
[PATCH v4 2/7] drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog
Rather than detecting VBIF_XINL_QOS_LVL_REMAP_000 based on the
hwversion, push the offset to the hw_catalog.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c| 4 ++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c3759fc4b154..101d9abe652b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1339,6 +1339,7 @@ static const struct dpu_vbif_cfg msm8998_vbif[] = {
.default_ot_wr_limit = 32,
.features = BIT(DPU_VBIF_QOS_REMAP) | BIT(DPU_VBIF_QOS_OTLIM),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x20,
.dynamic_ot_rd_tbl = {
.count = ARRAY_SIZE(msm8998_ot_rdwr_cfg),
.cfg = msm8998_ot_rdwr_cfg,
@@ -1366,6 +1367,7 @@ static const struct dpu_vbif_cfg sdm845_vbif[] = {
.base = 0, .len = 0x1040,
.features = BIT(DPU_VBIF_QOS_REMAP),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x40,
.qos_rt_tbl = {
.npriority_lvl = ARRAY_SIZE(sdm845_rt_pri_lvl),
.priority_lvl = sdm845_rt_pri_lvl,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 80bc09b1f1b3..f70de97f492a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -709,6 +709,7 @@ struct dpu_vbif_qos_tbl {
* @ot_rd_limitdefault OT read limit
* @ot_wr_limitdefault OT write limit
* @xin_halt_timeout maximum time (in usec) for xin to halt
+ * @qos_rp_remap_size size of VBIF_XINL_QOS_RP_REMAP register space
* @dynamic_ot_rd_tbl dynamic OT read configuration table
* @dynamic_ot_wr_tbl dynamic OT write configuration table
* @qos_rt_tbl real-time QoS priority table
@@ -721,6 +722,7 @@ struct dpu_vbif_cfg {
u32 default_ot_rd_limit;
u32 default_ot_wr_limit;
u32 xin_halt_timeout;
+ u32 qos_rp_remap_size;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_rd_tbl;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_wr_tbl;
struct dpu_vbif_qos_tbl qos_rt_tbl;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
index b757054e1c23..046854c3fbed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
@@ -30,7 +30,7 @@
#define VBIF_XIN_HALT_CTRL00x0200
#define VBIF_XIN_HALT_CTRL10x0204
#define VBIF_XINL_QOS_RP_REMAP_000 0x0550
-#define VBIF_XINL_QOS_LVL_REMAP_000(v) (v < DPU_HW_VER_400 ? 0x570 : 0x0590)
+#define VBIF_XINL_QOS_LVL_REMAP_000(vbif) (VBIF_XINL_QOS_RP_REMAP_000 +
(vbif)->cap->qos_rp_remap_size)
static void dpu_hw_clear_errors(struct dpu_hw_vbif *vbif,
u32 *pnd_errors, u32 *src_errors)
@@ -163,7 +163,7 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
c = &vbif->hw;
- reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(c->hwversion);
+ reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(vbif);
reg_high = ((xin_id & 0x8) >> 3) * 4 + (level * 8);
reg_shift = (xin_id & 0x7) * 4;
--
2.35.1
[PATCH v3 7/7] drm/msm/dpu: make dpu hardware catalog static const
Replace superfluous cfg_init functions, which just assign a static
config to the struct dpu_mdss_cfg, with static instances of struct
dpu_mdss_cfg.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 475 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 213 insertions(+), 269 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 1c40307af0ec..6d52db450e42 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1722,283 +1722,228 @@ static const struct dpu_perf_cfg qcm2290_perf_data = {
.bw_inefficiency_factor = 120,
};
/*
- * Hardware catalog init
+ * Hardware catalog
*/
-/*
- * msm8998_cfg_init(): populate sdm845 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void msm8998_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &msm8998_dpu_caps,
- .mdp_count = ARRAY_SIZE(msm8998_mdp),
- .mdp = msm8998_mdp,
- .ctl_count = ARRAY_SIZE(msm8998_ctl),
- .ctl = msm8998_ctl,
- .sspp_count = ARRAY_SIZE(msm8998_sspp),
- .sspp = msm8998_sspp,
- .mixer_count = ARRAY_SIZE(msm8998_lm),
- .mixer = msm8998_lm,
- .dspp_count = ARRAY_SIZE(msm8998_dspp),
- .dspp = msm8998_dspp,
- .pingpong_count = ARRAY_SIZE(sdm845_pp),
- .pingpong = sdm845_pp,
- .intf_count = ARRAY_SIZE(msm8998_intf),
- .intf = msm8998_intf,
- .vbif_count = ARRAY_SIZE(msm8998_vbif),
- .vbif = msm8998_vbif,
- .reg_dma_count = 0,
- .perf = &msm8998_perf_data,
- .mdss_irqs = IRQ_SM8250_MASK,
- };
-}
-
-/*
- * sdm845_cfg_init(): populate sdm845 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sdm845_dpu_caps,
- .mdp_count = ARRAY_SIZE(sdm845_mdp),
- .mdp = sdm845_mdp,
- .ctl_count = ARRAY_SIZE(sdm845_ctl),
- .ctl = sdm845_ctl,
- .sspp_count = ARRAY_SIZE(sdm845_sspp),
- .sspp = sdm845_sspp,
- .mixer_count = ARRAY_SIZE(sdm845_lm),
- .mixer = sdm845_lm,
- .pingpong_count = ARRAY_SIZE(sdm845_pp),
- .pingpong = sdm845_pp,
- .dsc_count = ARRAY_SIZE(sdm845_dsc),
- .dsc = sdm845_dsc,
- .intf_count = ARRAY_SIZE(sdm845_intf),
- .intf = sdm845_intf,
- .vbif_count = ARRAY_SIZE(sdm845_vbif),
- .vbif = sdm845_vbif,
- .reg_dma_count = 1,
- .dma_cfg = &sdm845_regdma,
- .perf = &sdm845_perf_data,
- .mdss_irqs = IRQ_SDM845_MASK,
- };
-}
-
-/*
- * sc7180_cfg_init(): populate sc7180 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sc7180_dpu_caps,
- .mdp_count = ARRAY_SIZE(sc7180_mdp),
- .mdp = sc7180_mdp,
- .ctl_count = ARRAY_SIZE(sc7180_ctl),
- .ctl = sc7180_ctl,
- .sspp_count = ARRAY_SIZE(sc7180_sspp),
- .sspp = sc7180_sspp,
- .mixer_count = ARRAY_SIZE(sc7180_lm),
- .mixer = sc7180_lm,
- .dspp_count = ARRAY_SIZE(sc7180_dspp),
- .dspp = sc7180_dspp,
- .pingpong_count = ARRAY_SIZE(sc7180_pp),
- .pingpong = sc7180_pp,
- .intf_count = ARRAY_SIZE(sc7180_intf),
- .intf = sc7180_intf,
- .vbif_count = ARRAY_SIZE(sdm845_vbif),
- .vbif = sdm845_vbif,
- .reg_dma_count = 1,
- .dma_cfg = &sdm845_regdma,
- .perf = &sc7180_perf_data,
- .mdss_irqs = IRQ_SC7180_MASK,
- };
-}
-
-/*
- * sm8150_cfg_init(): populate sm8150 dpu sub-blocks reg offsets
- * and instance counts.
- */
-static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
-{
- *dpu_cfg = (struct dpu_mdss_cfg){
- .caps = &sm8150_dpu_caps,
- .mdp_count = ARRAY_SIZE(sdm845_mdp),
- .mdp = sdm845_mdp,
- .ctl_count = ARRAY_SIZE(sm8150_ctl),
- .ctl = sm8150_ctl,
- .sspp_count = ARRAY_SIZE(sdm845_sspp),
- .sspp = sdm845_sspp,
- .mixer_count = ARRAY_SIZE(sm8150_lm
[PATCH v3 6/7] drm/msm/dpu: constify struct dpu_mdss_cfg
Mark struct dpu_mdss_cfg instance as a const pointer. This is mostly a
preparation for the next patch.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 9 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
17 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 31767d0f7353..1d9d83d7b99e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -468,7 +468,7 @@ static const struct file_operations dpu_core_perf_mode_fops
= {
int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
{
struct dpu_core_perf *perf = &dpu_kms->perf;
- struct dpu_mdss_cfg *catalog = perf->catalog;
+ const struct dpu_mdss_cfg *catalog = perf->catalog;
struct dentry *entry;
entry = debugfs_create_dir("core_perf", parent);
@@ -517,7 +517,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk)
{
perf->dev = dev;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 8dfcc6db7176..e3795995e145 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -68,7 +68,7 @@ struct dpu_core_perf_tune {
struct dpu_core_perf {
struct drm_device *dev;
struct dentry *debugfs_root;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
struct clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -119,7 +119,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk);
struct dpu_kms;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 52516eb20cb8..460df2a4831c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1207,7 +1207,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
mutex_unlock(&dpu_enc->enc_lock);
}
-static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
+static enum dpu_intf dpu_encoder_get_intf(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
@@ -1224,7 +1224,7 @@ static enum dpu_intf dpu_encoder_get_intf(struct
dpu_mdss_cfg *catalog,
return INTF_MAX;
}
-static enum dpu_wb dpu_encoder_get_wb(struct dpu_mdss_cfg *catalog,
+static enum dpu_wb dpu_encoder_get_wb(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 1e4a4822fbf4..4088c9e17d50 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -103,7 +103,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
{
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cca3b3a0c231..1c40307af0ec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
++
[PATCH v3 5/7] drm/msm/dpu: change catalog->dma_cfg to be a const pointer
Change dpu_mdss_cfg::dma_cfg to be a const pointer rather than embedding
the dpu_reg_dma_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 95b3ecc4db60..cca3b3a0c231 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1780,7 +1780,7 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sdm845_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1811,7 +1811,7 @@ static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sc7180_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
@@ -1844,7 +1844,7 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sm8150_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1875,7 +1875,7 @@ static void sc8180x_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sc8180x_perf_data,
.mdss_irqs = IRQ_SC8180X_MASK,
};
@@ -1910,7 +1910,7 @@ static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.wb_count = ARRAY_SIZE(sm8250_wb),
.wb = sm8250_wb,
.reg_dma_count = 1,
- .dma_cfg = sm8250_regdma,
+ .dma_cfg = &sm8250_regdma,
.perf = &sm8250_perf_data,
.mdss_irqs = IRQ_SM8250_MASK,
};
@@ -1965,7 +1965,7 @@ static void qcm2290_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &qcm2290_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 64ed96b2fa3d..60b403ac9f0f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -859,7 +859,7 @@ struct dpu_mdss_cfg {
const struct dpu_wb_cfg *wb;
u32 reg_dma_count;
- struct dpu_reg_dma_cfg dma_cfg;
+ const struct dpu_reg_dma_cfg *dma_cfg;
u32 ad_count;
--
2.35.1
[PATCH v3 4/7] drm/msm/dpu: change catalog->perf to be a const pointer
Change dpu_mdss_cfg::perf to be a const pointer rather than embedding
the dpu_perf_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 20 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 16 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 -
5 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index a7492dd6ed65..31767d0f7353 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -53,7 +53,7 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
crtc_plane_bw += pstate->plane_fetch_bw;
}
- bw_factor = kms->catalog->perf.bw_inefficiency_factor;
+ bw_factor = kms->catalog->perf->bw_inefficiency_factor;
if (bw_factor) {
crtc_plane_bw *= bw_factor;
do_div(crtc_plane_bw, 100);
@@ -90,7 +90,7 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
crtc_clk = max(pstate->plane_clk, crtc_clk);
}
- clk_factor = kms->catalog->perf.clk_inefficiency_factor;
+ clk_factor = kms->catalog->perf->clk_inefficiency_factor;
if (clk_factor) {
crtc_clk *= clk_factor;
do_div(crtc_clk, 100);
@@ -128,7 +128,7 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
} else {
perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
- perf->max_per_pipe_ib = kms->catalog->perf.min_dram_ib;
+ perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
@@ -189,7 +189,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
bw = DIV_ROUND_UP_ULL(bw_sum_of_intfs, 1000);
DRM_DEBUG_ATOMIC("calculated bandwidth=%uk\n", bw);
- threshold = kms->catalog->perf.max_bw_high;
+ threshold = kms->catalog->perf->max_bw_high;
DRM_DEBUG_ATOMIC("final threshold bw limit = %d\n", threshold);
@@ -413,7 +413,7 @@ static ssize_t _dpu_core_perf_mode_write(struct file *file,
const char __user *user_buf, size_t count, loff_t *ppos)
{
struct dpu_core_perf *perf = file->private_data;
- struct dpu_perf_cfg *cfg = &perf->catalog->perf;
+ const struct dpu_perf_cfg *cfg = perf->catalog->perf;
u32 perf_mode = 0;
int ret;
@@ -480,15 +480,15 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms,
struct dentry *parent)
debugfs_create_u32("enable_bw_release", 0600, entry,
(u32 *)&perf->enable_bw_release);
debugfs_create_u32("threshold_low", 0600, entry,
- (u32 *)&catalog->perf.max_bw_low);
+ (u32 *)&catalog->perf->max_bw_low);
debugfs_create_u32("threshold_high", 0600, entry,
- (u32 *)&catalog->perf.max_bw_high);
+ (u32 *)&catalog->perf->max_bw_high);
debugfs_create_u32("min_core_ib", 0600, entry,
- (u32 *)&catalog->perf.min_core_ib);
+ (u32 *)&catalog->perf->min_core_ib);
debugfs_create_u32("min_llcc_ib", 0600, entry,
- (u32 *)&catalog->perf.min_llcc_ib);
+ (u32 *)&catalog->perf->min_llcc_ib);
debugfs_create_u32("min_dram_ib", 0600, entry,
- (u32 *)&catalog->perf.min_dram_ib);
+ (u32 *)&catalog->perf->min_dram_ib);
debugfs_create_file("perf_mode", 0600, entry,
(u32 *)perf, &dpu_core_perf_mode_fops);
debugfs_create_u64("fix_core_clk_rate", 0600, entry,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 4829d1ce0cf8..1e4a4822fbf4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -104,7 +104,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
struct dpu_mdss_cfg *catalog;
- struct dpu_qos_lut_tbl *qos_lut_tb;
+ const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
DPU_ERROR("invalid parameter(s)\n");
@@ -118,11 +118,11 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
memset(&qos_cfg, 0, sizeof(struct dpu_hw_wb_qos_c
[PATCH v3 2/7] drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog
Rather than detecting VBIF_XINL_QOS_LVL_REMAP_000 based on the
hwversion, push the offset to the hw_catalog.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c| 4 ++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c3759fc4b154..101d9abe652b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1339,6 +1339,7 @@ static const struct dpu_vbif_cfg msm8998_vbif[] = {
.default_ot_wr_limit = 32,
.features = BIT(DPU_VBIF_QOS_REMAP) | BIT(DPU_VBIF_QOS_OTLIM),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x20,
.dynamic_ot_rd_tbl = {
.count = ARRAY_SIZE(msm8998_ot_rdwr_cfg),
.cfg = msm8998_ot_rdwr_cfg,
@@ -1366,6 +1367,7 @@ static const struct dpu_vbif_cfg sdm845_vbif[] = {
.base = 0, .len = 0x1040,
.features = BIT(DPU_VBIF_QOS_REMAP),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x40,
.qos_rt_tbl = {
.npriority_lvl = ARRAY_SIZE(sdm845_rt_pri_lvl),
.priority_lvl = sdm845_rt_pri_lvl,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 80bc09b1f1b3..f70de97f492a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -709,6 +709,7 @@ struct dpu_vbif_qos_tbl {
* @ot_rd_limitdefault OT read limit
* @ot_wr_limitdefault OT write limit
* @xin_halt_timeout maximum time (in usec) for xin to halt
+ * @qos_rp_remap_size size of VBIF_XINL_QOS_RP_REMAP register space
* @dynamic_ot_rd_tbl dynamic OT read configuration table
* @dynamic_ot_wr_tbl dynamic OT write configuration table
* @qos_rt_tbl real-time QoS priority table
@@ -721,6 +722,7 @@ struct dpu_vbif_cfg {
u32 default_ot_rd_limit;
u32 default_ot_wr_limit;
u32 xin_halt_timeout;
+ u32 qos_rp_remap_size;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_rd_tbl;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_wr_tbl;
struct dpu_vbif_qos_tbl qos_rt_tbl;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
index b757054e1c23..046854c3fbed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
@@ -30,7 +30,7 @@
#define VBIF_XIN_HALT_CTRL00x0200
#define VBIF_XIN_HALT_CTRL10x0204
#define VBIF_XINL_QOS_RP_REMAP_000 0x0550
-#define VBIF_XINL_QOS_LVL_REMAP_000(v) (v < DPU_HW_VER_400 ? 0x570 : 0x0590)
+#define VBIF_XINL_QOS_LVL_REMAP_000(vbif) (VBIF_XINL_QOS_RP_REMAP_000 +
(vbif)->cap->qos_rp_remap_size)
static void dpu_hw_clear_errors(struct dpu_hw_vbif *vbif,
u32 *pnd_errors, u32 *src_errors)
@@ -163,7 +163,7 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
c = &vbif->hw;
- reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(c->hwversion);
+ reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(vbif);
reg_high = ((xin_id & 0x8) >> 3) * 4 + (level * 8);
reg_shift = (xin_id & 0x7) * 4;
--
2.35.1
[PATCH v3 3/7] drm/msm/dpu: remove hwversion field from data structures
The driver should not depend on hw revision for detecting features.
Instead it should use features from the hw catalog. Drop the hwversion
field from struct dpu_mdss_cfg and struct dpu_hw_blk_reg_map.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 -
15 files changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 101d9abe652b..355c7aa82582 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2002,7 +2002,6 @@ struct dpu_mdss_cfg *dpu_hw_catalog_init(u32 hw_rev)
for (i = 0; i < ARRAY_SIZE(cfg_handler); i++) {
if (cfg_handler[i].hw_rev == hw_rev) {
cfg_handler[i].cfg_init(dpu_cfg);
- dpu_cfg->hwversion = hw_rev;
return dpu_cfg;
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index f70de97f492a..4225f58d8f97 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -826,8 +826,6 @@ struct dpu_perf_cfg {
* @mdss_irqs: Bitmap with the irqs supported by the target
*/
struct dpu_mdss_cfg {
- u32 hwversion;
-
const struct dpu_caps *caps;
u32 mdp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index c33e7ef611a6..7d416bf4ae91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -61,7 +61,6 @@ static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
b->base_off = addr;
b->blk_off = m->ctl[i].base;
b->length = m->ctl[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_CTL;
return &m->ctl[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4ad8991fc7d9..6f20d6b6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -169,7 +169,6 @@ static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
b->base_off = addr;
b->blk_off = m->dsc[i].base;
b->length = m->dsc[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSC;
return &m->dsc[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 355894a3b48c..3e63bf4fa64e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -83,7 +83,6 @@ static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp
dspp,
b->base_off = addr;
b->blk_off = m->dspp[i].base;
b->length = m->dspp[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSPP;
return &m->dspp[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 61284e6c313d..01bb2d84c3a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -403,7 +403,6 @@ static void __intr_offset(struct dpu_mdss_cfg *m,
{
hw->base_off = addr;
hw->blk_off = m->mdp[0].base;
- hw->hwversion = m->hwversion;
}
struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..b2ca8d19fdd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -80,7 +80,6 @@ static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf
intf,
[PATCH v3 1/7] drm/msm/dpu: use feature bit for LM combined alpha check
Rather than checking hwversion, follow the usual patter and add special
bit to the lm->features to check whether the LM has combined or separate
alpha registers. While we are at it, rename
dpu_hw_lm_setup_blend_config_sdm845() to
dpu_hw_lm_setup_blend_config_combined_alpha().
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 19 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 +++---
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 400ebceb56bb..c3759fc4b154 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -50,11 +50,14 @@
#define DMA_CURSOR_MSM8998_MASK \
(DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
-#define MIXER_SDM845_MASK \
+#define MIXER_MSM8998_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
+#define MIXER_SDM845_MASK \
+ (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
BIT(DPU_MIXER_COMBINED_ALPHA))
+
#define MIXER_SC7180_MASK \
- (BIT(DPU_DIM_LAYER))
+ (BIT(DPU_DIM_LAYER) | BIT(DPU_MIXER_COMBINED_ALPHA))
#define PINGPONG_SDM845_MASK BIT(DPU_PINGPONG_DITHER)
@@ -936,17 +939,17 @@ static const struct dpu_lm_sub_blks msm8998_lm_sblk = {
};
static const struct dpu_lm_cfg msm8998_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_0, LM_2, DSPP_0),
- LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_1, LM_5, DSPP_1),
- LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_2, LM_0, 0),
- LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_3, LM_1, 0),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8cb6d1f25bf9..80bc09b1f1b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -145,6 +145,7 @@ enum {
* @DPU_MIXER_SOURCESPLIT Layer mixer supports source-split configuration
* @DPU_MIXER_GC Gamma correction block
* @DPU_DIM_LAYER Layer mixer supports dim layer
+ * @DPU_MIXER_COMBINED_ALPHA Layer mixer has combined alpha register
* @DPU_MIXER_MAX maximum value
*/
enum {
@@ -152,6 +153,7 @@ enum {
DPU_MIXER_SOURCESPLIT,
DPU_MIXER_GC,
DPU_DIM_LAYER,
+ DPU_MIXER_COMBINED_ALPHA,
DPU_MIXER_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 462f5082099e..25d2eba28e71 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -148,7 +148,7 @@ static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer *ctx,
u32 *misr_value)
return 0;
}
-static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
+static void dpu_hw_lm_setup_blend_config_combined_alpha(struct dpu_hw_mixer
*ctx,
u32 stage, u32 fg_alpha, u32 bg_alpha, u32 blend_op)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -204,8 +204,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (m->hwversion >= DPU_HW_VER_400)
- ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
+ if (test_bit(DPU_MIXER_COMBINED_ALPHA, &features))
+ ops->setup_blend_config =
dpu_hw_lm_setup_blend_config_combined_alpha;
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
--
2.35.1
[PATCH v3 0/7] drm/msm: clean up the hw catalog init
Replace superfluous cfg_init functions, which just assign a static config to the struct dpu_mdss_cfg, with static instances of struct dpu_mdss_cfg. Changes since v2: - Add DPU_MIXER_COMBINED_ALPHA to sc7180's mixer features mask (noted by Abhinav). Changes since v1: - Turn catalog->perf and catalog->dma_cfg to be pointers, otherwise clang complains that they are not constant. Dmitry Baryshkov (7): drm/msm/dpu: use feature bit for LM combined alpha check drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog drm/msm/dpu: remove hwversion field from data structures drm/msm/dpu: change catalog->perf to be a const pointer drm/msm/dpu: change catalog->dma_cfg to be a const pointer drm/msm/dpu: constify struct dpu_mdss_cfg drm/msm/dpu: make dpu hardware catalog static const drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 24 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 12 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 502 -- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 5 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 7 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 - .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 2 +- 27 files changed, 283 insertions(+), 359 deletions(-) -- 2.35.1
[PATCH 3/3] drm/dp_mst: Get rid of old comment in drm_atomic_get_mst_topology_state docs
We don't actually care about connection_mutex here anymore, so let's get rid of the comment mentioning it in this function's kdocs. Signed-off-by: Lyude Paul --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index d6e595b95f07..9f96132a5d74 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -5458,8 +5458,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs); * * This function wraps drm_atomic_get_priv_obj_state() passing in the MST atomic * state vtable so that the private object state returned is that of a MST - * topology object. Also, drm_atomic_get_private_obj_state() expects the caller - * to care of the locking, so warn if don't hold the connection_mutex. + * topology object. * * RETURNS: * -- 2.35.3
[PATCH 0/3] Misc drive-by fixes for MST helpers
I'm now (finally!) finishing up my work with getting rid of the legacy MST code and makng everything atomic only, and while doing that I ended up coming up with a few unrelated patches along the way. These are those patches. Lyude Paul (3): drm/display/dp_mst: Don't validate port refs in drm_dp_check_and_send_link_address() drm/display/dp_mst: Fix drm_atomic_get_mst_topology_state() drm/dp_mst: Get rid of old comment in drm_atomic_get_mst_topology_state docs drivers/gpu/drm/display/drm_dp_mst_topology.c | 27 ++- include/drm/display/drm_dp_mst_helper.h | 2 ++ 2 files changed, 10 insertions(+), 19 deletions(-) -- 2.35.3
[PATCH 2/3] drm/display/dp_mst: Fix drm_atomic_get_mst_topology_state()
I noticed a rather surprising issue here while working on removing all of
the non-atomic MST code: drm_atomic_get_mst_topology_state() doesn't check
the return value of drm_atomic_get_private_obj_state() and instead just
passes it directly to to_dp_mst_topology_state(). This means that if we
hit a deadlock or something else which would return an error code pointer,
we'll likely segfault the kernel.
This is definitely another one of those fixes where I'm astonished we
somehow managed never to discover this issue until now…
Signed-off-by: Lyude Paul
Fixes: a4370c777406 ("drm/atomic: Make private objs proper objects")
Cc: Ville Syrjälä
Cc: # v4.14+
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index d84673b3294b..d6e595b95f07 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5468,7 +5468,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
drm_atomic_state *state,
struct
drm_dp_mst_topology_mgr *mgr)
{
- return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
&mgr->base));
+ return
to_dp_mst_topology_state_safe(drm_atomic_get_private_obj_state(state,
&mgr->base));
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 10adec068b7f..fe7577e7f305 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -541,6 +541,8 @@ struct drm_dp_payload {
};
#define to_dp_mst_topology_state(x) container_of(x, struct
drm_dp_mst_topology_state, base)
+#define to_dp_mst_topology_state_safe(x) \
+ container_of_safe(x, struct drm_dp_mst_topology_state, base)
struct drm_dp_vcpi_allocation {
struct drm_dp_mst_port *port;
--
2.35.3
[PATCH 1/3] drm/display/dp_mst: Don't validate port refs in drm_dp_check_and_send_link_address()
Drive-by cleanup, we don't need to validate the port references here as we
already previously went through the effort of refactoring things such that
we're guaranteed to be able to access ->mstb and ->port safely from
drm_dp_check_and_send_link_address(), since the only two places in the
codebase that drop an MST reference in such a way that it would remove it
from the topology are both protected under probe_lock.
Thanks for that, past Lyude!
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 22 +--
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 67b3b9697da7..d84673b3294b 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2666,24 +2666,14 @@ static int drm_dp_check_and_send_link_address(struct
drm_dp_mst_topology_mgr *mg
}
list_for_each_entry(port, &mstb->ports, next) {
- struct drm_dp_mst_branch *mstb_child = NULL;
-
- if (port->input || !port->ddps)
+ if (port->input || !port->ddps || !port->mstb)
continue;
- if (port->mstb)
- mstb_child = drm_dp_mst_topology_get_mstb_validated(
- mgr, port->mstb);
-
- if (mstb_child) {
- ret = drm_dp_check_and_send_link_address(mgr,
-mstb_child);
- drm_dp_mst_topology_put_mstb(mstb_child);
- if (ret == 1)
- changed = true;
- else if (ret < 0)
- return ret;
- }
+ ret = drm_dp_check_and_send_link_address(mgr, port->mstb);
+ if (ret == 1)
+ changed = true;
+ else if (ret < 0)
+ return ret;
}
return changed;
--
2.35.3
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Thu, Jun 2, 2022 at 7:42 AM Lionel Landwerlin wrote: > > On 02/06/2022 00:18, Matthew Brost wrote: > > On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > >> On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > >>> +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the > >>> mapping in an > >>> +async worker. The binding and unbinding will work like a special GPU > >>> engine. > >>> +The binding and unbinding operations are serialized and will wait on > >>> specified > >>> +input fences before the operation and will signal the output fences upon > >>> the > >>> +completion of the operation. Due to serialization, completion of an > >>> operation > >>> +will also indicate that all previous operations are also complete. > >> I guess we should avoid saying "will immediately start binding/unbinding" > >> if > >> there are fences involved. > >> > >> And the fact that it's happening in an async worker seem to imply it's not > >> immediate. > >> > >> > >> I have a question on the behavior of the bind operation when no input fence > >> is provided. Let say I do : > >> > >> VM_BIND (out_fence=fence1) > >> > >> VM_BIND (out_fence=fence2) > >> > >> VM_BIND (out_fence=fence3) > >> > >> > >> In what order are the fences going to be signaled? > >> > >> In the order of VM_BIND ioctls? Or out of order? > >> > >> Because you wrote "serialized I assume it's : in order > >> > >> > >> One thing I didn't realize is that because we only get one "VM_BIND" > >> engine, > >> there is a disconnect from the Vulkan specification. Note that in Vulkan not every queue has to support sparse binding, so one could consider a dedicated sparse binding only queue family. > >> > >> In Vulkan VM_BIND operations are serialized but per engine. > >> > >> So you could have something like this : > >> > >> VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > >> > >> VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > >> > > Question - let's say this done after the above operations: > > > > EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) > > > > Is the exec ordered with respected to bind (i.e. would fence3 & 4 be > > signaled before the exec starts)? > > > > Matt > > > Hi Matt, > > From the vulkan point of view, everything is serialized within an > engine (we map that to a VkQueue). > > So with : > > EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > EXEC completes first then VM_BIND executes. > > > To be even clearer : > > EXEC (engine=ccs0, in_fence=fence2, out_fence=NULL) > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > > EXEC will wait until fence2 is signaled. > Once fence2 is signaled, EXEC proceeds, finishes and only after it is done, > VM_BIND executes. > > It would kind of like having the VM_BIND operation be another batch executed > from the ringbuffer buffer. > > -Lionel > > > > > >> fence1 is not signaled > >> > >> fence3 is signaled > >> > >> So the second VM_BIND will proceed before the first VM_BIND. > >> > >> > >> I guess we can deal with that scenario in userspace by doing the wait > >> ourselves in one thread per engines. > >> > >> But then it makes the VM_BIND input fences useless. I posed the same question on my series for AMD (https://patchwork.freedesktop.org/series/104578/), albeit for slightly different reasons.: if one creates a new VkMemory object, you generally want that mapped ASAP, as you can't track (in a VK_KHR_descriptor_indexing world) whether the next submit is going to use this VkMemory object and hence have to assume the worst (i.e. wait till the map/bind is complete before executing the next submission). If all binds/unbinds (or maps/unmaps) happen in-order that means an operation with input fences could delay stuff we want ASAP. Of course waiting in userspace does have disadvantages: 1) more overhead between fence signalling and the operation, potentially causing slightly bigger GPU bubbles. 2) You can't get an out fence early. Within the driver we can mostly work around this but sync_fd exports, WSI and such will be messy. 3) moving the queue to a thread might make things slightly less ideal due to scheduling delays. Removing the in-order working in the kernel generally seems like madness to me as it is very hard to keep track of the state of the virtual address space (to e.g. track umapping stuff before freeing memory or moving memory around) the one game I tried (FH5 over vkd3d-proton) does sparse mapping as follows: separate queue: 1) 0 cmdbuffer submit with 0 input semaphores and 1 output semaphore 2) sparse bind with input semaphore from 1 and 1 output semaphore 3) 0 cmdbuffer submit with input semaphore from 2 and 1 output fence 4) wait on that fence on the CPU which works very well if we just wait for the sparse bind input semaphore in userspace, but I'm still working on seeing if this is the common usecase or an outlier. > >> > >> > >> Daniel : what do you thi
Re: [PATCH v2 1/7] drm/msm/dpu: use feature bit for LM combined alpha check
On Thu, 2 Jun 2022 at 21:37, Abhinav Kumar wrote:
>
>
>
> On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
> > Rather than checking hwversion, follow the usual patter and add special
> > bit to the lm->features to check whether the LM has combined or separate
> > alpha registers. While we are at it, rename
> > dpu_hw_lm_setup_blend_config_sdm845() to
> > dpu_hw_lm_setup_blend_config_combined_alpha().
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 17 ++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 +++---
> > 3 files changed, 15 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index 400ebceb56bb..78c7d987c2ca 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -50,9 +50,12 @@
> > #define DMA_CURSOR_MSM8998_MASK \
> > (DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
> >
> > -#define MIXER_SDM845_MASK \
> > +#define MIXER_MSM8998_MASK \
> > (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
> >
> > +#define MIXER_SDM845_MASK \
> > + (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
> > BIT(DPU_MIXER_COMBINED_ALPHA))
> > +
> > #define MIXER_SC7180_MASK \
> > (BIT(DPU_DIM_LAYER))
> >
> > @@ -936,17 +939,17 @@ static const struct dpu_lm_sub_blks msm8998_lm_sblk =
> > {
> > };
> >
> > static const struct dpu_lm_cfg msm8998_lm[] = {
> > - LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_0", LM_0, 0x44000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_0, LM_2, DSPP_0),
> > - LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_1", LM_1, 0x45000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_1, LM_5, DSPP_1),
> > - LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_2", LM_2, 0x46000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_2, LM_0, 0),
> > - LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_3", LM_3, 0x47000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
> > - LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_4", LM_4, 0x48000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
> > - LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
> > + LM_BLK("lm_5", LM_5, 0x49000, MIXER_MSM8998_MASK,
> > &msm8998_lm_sblk, PINGPONG_3, LM_1, 0),
> > };
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > index 8cb6d1f25bf9..80bc09b1f1b3 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > @@ -145,6 +145,7 @@ enum {
> >* @DPU_MIXER_SOURCESPLIT Layer mixer supports source-split
> > configuration
> >* @DPU_MIXER_GC Gamma correction block
> >* @DPU_DIM_LAYER Layer mixer supports dim layer
> > + * @DPU_MIXER_COMBINED_ALPHA Layer mixer has combined alpha register
> >* @DPU_MIXER_MAX maximum value
> >*/
> > enum {
> > @@ -152,6 +153,7 @@ enum {
> > DPU_MIXER_SOURCESPLIT,
> > DPU_MIXER_GC,
> > DPU_DIM_LAYER,
> > + DPU_MIXER_COMBINED_ALPHA,
> > DPU_MIXER_MAX
> > };
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > index 462f5082099e..25d2eba28e71 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> > @@ -148,7 +148,7 @@ static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer
> > *ctx, u32 *misr_value)
> > return 0;
> > }
> >
> > -static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
> > +static void dpu_hw_lm_setup_blend_config_combined_alpha(struct
> > dpu_hw_mixer *ctx,
> > u32 stage, u32 fg_alpha, u32 bg_alpha, u32 blend_op)
> > {
> > struct dpu_hw_blk_reg_map *c = &ctx->hw;
> > @@ -204,8 +204,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg
> > *m,
> > unsigned long features)
> > {
> > ops->setup_mixer_out = dpu_hw_lm_setup_out;
> > - if (m->hwversion >= DPU_HW_VER_400)
> > - ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
> > + if (test_bit(DPU_MIXER_COMBINED_ALPHA, &features))
> > + ops->setup_blend_config =
> > dpu_hw_lm_setup_blend_config_combined_alpha;
>
> This will not work for all chipsets.
>
> In the catalog you have added BIT(DPU_MIXER_COMBINED_ALPHA) only for
> MIXER_SDM845_MASK but MIXER_SC7180_MASK is not updated.
>
> HW version of sc7180 is > DPU_HW_VER_400 so this would break both sc7180
> and sc7280.
>
> Please update all the relevant chi
Re: [Freedreno] [PATCH] drm/msm: less magic numbers in msm_mdss_enable
On Thu, 2 Jun 2022 at 21:18, Abhinav Kumar wrote:
>
>
>
> On 6/1/2022 1:04 PM, Dmitry Baryshkov wrote:
> > On Wed, 1 Jun 2022 at 20:38, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 6/1/2022 2:46 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 1 Jun 2022 at 01:01, Abhinav Kumar
> >>> wrote:
> On 5/31/2022 5:18 AM, Dmitry Baryshkov wrote:
> > Replace magic register writes in msm_mdss_enable() with version that
> > contains less magic and more variable names that can be traced back to
> > the dpu_hw_catalog or the downstream dtsi files.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/msm_mdss.c | 79
> > ++
> > 1 file changed, 71 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c
> > b/drivers/gpu/drm/msm/msm_mdss.c
> > index 0454a571adf7..2a48263cd1b5 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++ b/drivers/gpu/drm/msm/msm_mdss.c
> > @@ -21,6 +21,7 @@
> > #define HW_REV 0x0
> > #define HW_INTR_STATUS 0x0010
> >
> > +#define UBWC_DEC_HW_VERSION 0x58
> > #define UBWC_STATIC 0x144
> > #define UBWC_CTRL_2 0x150
> > #define UBWC_PREDICTION_MODE0x154
> > @@ -132,9 +133,63 @@ static int _msm_mdss_irq_domain_add(struct
> > msm_mdss *msm_mdss)
> > return 0;
> > }
> >
> > +#define UBWC_1_0 0x1000
> > +#define UBWC_2_0 0x2000
> > +#define UBWC_3_0 0x3000
> > +#define UBWC_4_0 0x4000
> > +
> > +static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss,
> > +u32 ubwc_static)
> > +{
> > + writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC);
> > +}
> > +
> > +static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss,
> > +unsigned int ubwc_version,
> > +u32 ubwc_swizzle,
> > +u32 highest_bank_bit,
> > +u32 macrotile_mode)
> > +{
> > + u32 value = (ubwc_swizzle & 0x1) |
> > + (highest_bank_bit & 0x3) << 4 |
> > + (macrotile_mode & 0x1) << 12;
> > +
> > + if (ubwc_version == UBWC_3_0)
> > + value |= BIT(10);
> > +
> > + if (ubwc_version == UBWC_1_0)
> > + value |= BIT(8);
> > +
> > + writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
> > +}
> > +
> > +static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss,
> > +unsigned int ubwc_version,
> > +u32 ubwc_swizzle,
> > +u32 ubwc_static,
> > +u32 highest_bank_bit,
> > +u32 macrotile_mode)
> > +{
> > + u32 value = (ubwc_swizzle & 0x7) |
> > + (ubwc_static & 0x1) << 3 |
> > + (highest_bank_bit & 0x7) << 4 |
> > + (macrotile_mode & 0x1) << 12;
> > +
> > + writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
> > +
> > + if (ubwc_version == UBWC_3_0) {
> > + writel_relaxed(1, msm_mdss->mmio + UBWC_CTRL_2);
> > + writel_relaxed(0, msm_mdss->mmio + UBWC_PREDICTION_MODE);
> > + } else {
> > + writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2);
> > + writel_relaxed(1, msm_mdss->mmio + UBWC_PREDICTION_MODE);
> > + }
> > +}
> > +
>
> Is it possible to unify the above functions by having the internal
> ubwc_version checks?
> >>>
> >>> Note, it's not the ubwc_version, it is the ubwc_dec_hw_version. And
> >>> also different functions take different sets of arguments.
> >>>
> It seems like msm_mdss_setup_ubwc_dec_xxx can keep growing.
>
> I have not looked into each bit programming but from the top level so
> feel free to correct if wrong but it seems both do write UBWC_STATIC
> (different values based on different UBWC versions) and write some extra
> registers based on version
> >>>
> >>> This is what both the current code and the downstream do. See
> >>> https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/zeus-s-oss/techpack/display-drivers/msm/sde/sde_hw_top.c#L312
> >>>
> >>
> >> Thanks for pointing to the downstream method for this,
> >>
> >> This is exactly what i was also suggesting to do when I mentioned
> >> unifying the above functions.
> >>
> >> So instead of having a separate function for each version why not handle
> >> all the versions in the same function like what the link you ha
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Wed, Jun 01, 2022 at 01:28:36PM -0700, Matthew Brost wrote: On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an > +async worker. The binding and unbinding will work like a special GPU engine. > +The binding and unbinding operations are serialized and will wait on specified > +input fences before the operation and will signal the output fences upon the > +completion of the operation. Due to serialization, completion of an operation > +will also indicate that all previous operations are also complete. I guess we should avoid saying "will immediately start binding/unbinding" if there are fences involved. And the fact that it's happening in an async worker seem to imply it's not immediate. Ok, will fix. This was added because in earlier design binding was deferred until next execbuff. But now it is non-deferred (immediate in that sense). But yah, this is confusing and will fix it. I have a question on the behavior of the bind operation when no input fence is provided. Let say I do : VM_BIND (out_fence=fence1) VM_BIND (out_fence=fence2) VM_BIND (out_fence=fence3) In what order are the fences going to be signaled? In the order of VM_BIND ioctls? Or out of order? Because you wrote "serialized I assume it's : in order Yes, in the order of VM_BIND/UNBIND ioctls. Note that bind and unbind will use the same queue and hence are ordered. One thing I didn't realize is that because we only get one "VM_BIND" engine, there is a disconnect from the Vulkan specification. In Vulkan VM_BIND operations are serialized but per engine. So you could have something like this : VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) fence1 is not signaled fence3 is signaled So the second VM_BIND will proceed before the first VM_BIND. I guess we can deal with that scenario in userspace by doing the wait ourselves in one thread per engines. But then it makes the VM_BIND input fences useless. Daniel : what do you think? Should be rework this or just deal with wait fences in userspace? My opinion is rework this but make the ordering via an engine param optional. e.g. A VM can be configured so all binds are ordered within the VM e.g. A VM can be configured so all binds accept an engine argument (in the case of the i915 likely this is a gem context handle) and binds ordered with respect to that engine. This gives UMDs options as the later likely consumes more KMD resources so if a different UMD can live with binds being ordered within the VM they can use a mode consuming less resources. I think we need to be careful here if we are looking for some out of (submission) order completion of vm_bind/unbind. In-order completion means, in a batch of binds and unbinds to be completed in-order, user only needs to specify in-fence for the first bind/unbind call and the our-fence for the last bind/unbind call. Also, the VA released by an unbind call can be re-used by any subsequent bind call in that in-order batch. These things will break if binding/unbinding were to be allowed to go out of order (of submission) and user need to be extra careful not to run into pre-mature triggereing of out-fence and bind failing as VA is still in use etc. Also, VM_BIND binds the provided mapping on the specified address space (VM). So, the uapi is not engine/context specific. We can however add a 'queue' to the uapi which can be one from the pre-defined queues, I915_VM_BIND_QUEUE_0 I915_VM_BIND_QUEUE_1 ... I915_VM_BIND_QUEUE_(N-1) KMD will spawn an async work queue for each queue which will only bind the mappings on that queue in the order of submission. User can assign the queue to per engine or anything like that. But again here, user need to be careful and not deadlock these queues with circular dependency of fences. I prefer adding this later an as extension based on whether it is really helping with the implementation. Daniel, any thoughts? Niranjana Matt Sorry I noticed this late. -Lionel
[PATCH] fbcon: Fix accelerated fbdev scrolling while logo is still shown
There is no need to directly skip over to the SCROLL_REDRAW case while
the logo is still shown.
When using DRM, this change has no effect because the code will reach
the SCROLL_REDRAW case immediately anyway.
But if you run an accelerated fbdev driver and have
FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is
slowed down by factors so that it feels as if you use a 9600 baud
terminal.
So, drop those unnecessary checks and speed up fbdev console
acceleration during bootup.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c2f9e5711c39..8eb5b73e98bc 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1706,8 +1706,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
case SM_UP:
if (count > vc->vc_rows)/* Maximum realistic size */
count = vc->vc_rows;
- if (logo_shown >= 0)
- goto redraw_up;
switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, t, b - t - count,
@@ -1796,8 +1794,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
case SM_DOWN:
if (count > vc->vc_rows)/* Maximum realistic size */
count = vc->vc_rows;
- if (logo_shown >= 0)
- goto redraw_down;
switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
[PATCH] fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters
The user may use the fbcon=vc:- option to tell fbcon to take over the given range (n1...n2) of consoles. The value for n1 and n2 needs to be a positive number and up to (MAX_NR_CONSOLES - 1). The given values were not fully checked against those boundaries yet. To fix the issue, convert first_fb_vc and last_fb_vc to unsigned integers and check them against the upper boundary, and make sure that first_fb_vc is smaller than last_fb_vc. Signed-off-by: Helge Deller Cc: sta...@vger.kernel.org diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 2fc1b80a26ad..c2f9e5711c39 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -115,8 +115,8 @@ static int logo_lines; enums. */ static int logo_shown = FBCON_LOGO_CANSHOW; /* console mappings */ -static int first_fb_vc; -static int last_fb_vc = MAX_NR_CONSOLES - 1; +static unsigned int first_fb_vc; +static unsigned int last_fb_vc = MAX_NR_CONSOLES - 1; static int fbcon_is_default = 1; static int primary_device = -1; static int fbcon_has_console_bind; @@ -464,10 +464,12 @@ static int __init fb_console_setup(char *this_opt) options += 3; if (*options) first_fb_vc = simple_strtoul(options, &options, 10) - 1; - if (first_fb_vc < 0) + if (first_fb_vc >= MAX_NR_CONSOLES) first_fb_vc = 0; if (*options++ == '-') last_fb_vc = simple_strtoul(options, &options, 10) - 1; + if (last_fb_vc < first_fb_vc || last_fb_vc >= MAX_NR_CONSOLES) + last_fb_vc = MAX_NR_CONSOLES - 1; fbcon_is_default = 0; continue; }
Re: [PATCH v2 6/7] drm/msm/dpu: constify struct dpu_mdss_cfg
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
Mark struct dpu_mdss_cfg instance as a const pointer. This is mostly a
preparation for the next patch.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 9 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +-
17 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 31767d0f7353..1d9d83d7b99e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -468,7 +468,7 @@ static const struct file_operations dpu_core_perf_mode_fops
= {
int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
{
struct dpu_core_perf *perf = &dpu_kms->perf;
- struct dpu_mdss_cfg *catalog = perf->catalog;
+ const struct dpu_mdss_cfg *catalog = perf->catalog;
struct dentry *entry;
entry = debugfs_create_dir("core_perf", parent);
@@ -517,7 +517,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk)
{
perf->dev = dev;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 8dfcc6db7176..e3795995e145 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -68,7 +68,7 @@ struct dpu_core_perf_tune {
struct dpu_core_perf {
struct drm_device *dev;
struct dentry *debugfs_root;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
struct clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -119,7 +119,7 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf);
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
- struct dpu_mdss_cfg *catalog,
+ const struct dpu_mdss_cfg *catalog,
struct clk *core_clk);
struct dpu_kms;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 52516eb20cb8..460df2a4831c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1207,7 +1207,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
mutex_unlock(&dpu_enc->enc_lock);
}
-static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog,
+static enum dpu_intf dpu_encoder_get_intf(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
@@ -1224,7 +1224,7 @@ static enum dpu_intf dpu_encoder_get_intf(struct
dpu_mdss_cfg *catalog,
return INTF_MAX;
}
-static enum dpu_wb dpu_encoder_get_wb(struct dpu_mdss_cfg *catalog,
+static enum dpu_wb dpu_encoder_get_wb(const struct dpu_mdss_cfg *catalog,
enum dpu_intf_type type, u32 controller_id)
{
int i = 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 1e4a4822fbf4..4088c9e17d50 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -103,7 +103,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
{
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
- struct dpu_mdss_cfg *catalog;
+ const struct dpu_mdss_cfg *catalog;
const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1
Re: [PATCH v2 5/7] drm/msm/dpu: change catalog->dma_cfg to be a const pointer
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
Change dpu_mdss_cfg::dma_cfg to be a const pointer rather than embedding
the dpu_reg_dma_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a7040ca5da72..5470b8b14b0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1780,7 +1780,7 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sdm845_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1811,7 +1811,7 @@ static void sc7180_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &sc7180_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
@@ -1844,7 +1844,7 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sm8150_perf_data,
.mdss_irqs = IRQ_SDM845_MASK,
};
@@ -1875,7 +1875,7 @@ static void sc8180x_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sm8150_regdma,
+ .dma_cfg = &sm8150_regdma,
.perf = &sc8180x_perf_data,
.mdss_irqs = IRQ_SC8180X_MASK,
};
@@ -1910,7 +1910,7 @@ static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.wb_count = ARRAY_SIZE(sm8250_wb),
.wb = sm8250_wb,
.reg_dma_count = 1,
- .dma_cfg = sm8250_regdma,
+ .dma_cfg = &sm8250_regdma,
.perf = &sm8250_perf_data,
.mdss_irqs = IRQ_SM8250_MASK,
};
@@ -1965,7 +1965,7 @@ static void qcm2290_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
- .dma_cfg = sdm845_regdma,
+ .dma_cfg = &sdm845_regdma,
.perf = &qcm2290_perf_data,
.mdss_irqs = IRQ_SC7180_MASK,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 64ed96b2fa3d..60b403ac9f0f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -859,7 +859,7 @@ struct dpu_mdss_cfg {
const struct dpu_wb_cfg *wb;
u32 reg_dma_count;
- struct dpu_reg_dma_cfg dma_cfg;
+ const struct dpu_reg_dma_cfg *dma_cfg;
u32 ad_count;
Re: [PATCH v2 4/7] drm/msm/dpu: change catalog->perf to be a const pointer
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
Change dpu_mdss_cfg::perf to be a const pointer rather than embedding
the dpu_perf_cfg struct into the struct dpu_mdss_cfg.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 20 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 16 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 -
5 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index a7492dd6ed65..31767d0f7353 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -53,7 +53,7 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
crtc_plane_bw += pstate->plane_fetch_bw;
}
- bw_factor = kms->catalog->perf.bw_inefficiency_factor;
+ bw_factor = kms->catalog->perf->bw_inefficiency_factor;
if (bw_factor) {
crtc_plane_bw *= bw_factor;
do_div(crtc_plane_bw, 100);
@@ -90,7 +90,7 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
crtc_clk = max(pstate->plane_clk, crtc_clk);
}
- clk_factor = kms->catalog->perf.clk_inefficiency_factor;
+ clk_factor = kms->catalog->perf->clk_inefficiency_factor;
if (clk_factor) {
crtc_clk *= clk_factor;
do_div(crtc_clk, 100);
@@ -128,7 +128,7 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
} else {
perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
- perf->max_per_pipe_ib = kms->catalog->perf.min_dram_ib;
+ perf->max_per_pipe_ib = kms->catalog->perf->min_dram_ib;
perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
@@ -189,7 +189,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
bw = DIV_ROUND_UP_ULL(bw_sum_of_intfs, 1000);
DRM_DEBUG_ATOMIC("calculated bandwidth=%uk\n", bw);
- threshold = kms->catalog->perf.max_bw_high;
+ threshold = kms->catalog->perf->max_bw_high;
DRM_DEBUG_ATOMIC("final threshold bw limit = %d\n", threshold);
@@ -413,7 +413,7 @@ static ssize_t _dpu_core_perf_mode_write(struct file *file,
const char __user *user_buf, size_t count, loff_t *ppos)
{
struct dpu_core_perf *perf = file->private_data;
- struct dpu_perf_cfg *cfg = &perf->catalog->perf;
+ const struct dpu_perf_cfg *cfg = perf->catalog->perf;
u32 perf_mode = 0;
int ret;
@@ -480,15 +480,15 @@ int dpu_core_perf_debugfs_init(struct dpu_kms *dpu_kms, struct dentry *parent)
debugfs_create_u32("enable_bw_release", 0600, entry,
(u32 *)&perf->enable_bw_release);
debugfs_create_u32("threshold_low", 0600, entry,
- (u32 *)&catalog->perf.max_bw_low);
+ (u32 *)&catalog->perf->max_bw_low);
debugfs_create_u32("threshold_high", 0600, entry,
- (u32 *)&catalog->perf.max_bw_high);
+ (u32 *)&catalog->perf->max_bw_high);
debugfs_create_u32("min_core_ib", 0600, entry,
- (u32 *)&catalog->perf.min_core_ib);
+ (u32 *)&catalog->perf->min_core_ib);
debugfs_create_u32("min_llcc_ib", 0600, entry,
- (u32 *)&catalog->perf.min_llcc_ib);
+ (u32 *)&catalog->perf->min_llcc_ib);
debugfs_create_u32("min_dram_ib", 0600, entry,
- (u32 *)&catalog->perf.min_dram_ib);
+ (u32 *)&catalog->perf->min_dram_ib);
debugfs_create_file("perf_mode", 0600, entry,
(u32 *)perf, &dpu_core_perf_mode_fops);
debugfs_create_u64("fix_core_clk_rate", 0600, entry,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 4829d1ce0cf8..1e4a4822fbf4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -104,7 +104,7 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc)
struct dpu_hw_wb *hw_wb;
struct dpu_hw_wb_qos_cfg qos_cfg;
struct dpu_mdss_cfg *catalog;
- struct dpu_qos_lut_tbl *qos_lut_tb;
+ const struct dpu_qos_lut_tbl *qos_lut_tb;
if (!phys_enc || !phys_enc->dpu_kms || !phys_enc->dpu_kms->catalog) {
DPU_ERROR("invalid parameter(s)\n");
@@ -118,11 +118,11 @@ static void dpu_encoder_phys_wb_set_qos(struct
dpu_encoder_phys *phys_enc
Re: [PATCH v2 3/7] drm/msm/dpu: remove hwversion field from data structures
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
The driver should not depend on hw revision for detecting features.
Instead it should use features from the hw catalog. Drop the hwversion
field from struct dpu_mdss_cfg and struct dpu_hw_blk_reg_map.
Signed-off-by: Dmitry Baryshkov
Since the previous two patches remove all the current users of
hwversion, this one should be fine.
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 -
15 files changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cff6fe3a85ac..367279371e8d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2002,7 +2002,6 @@ struct dpu_mdss_cfg *dpu_hw_catalog_init(u32 hw_rev)
for (i = 0; i < ARRAY_SIZE(cfg_handler); i++) {
if (cfg_handler[i].hw_rev == hw_rev) {
cfg_handler[i].cfg_init(dpu_cfg);
- dpu_cfg->hwversion = hw_rev;
return dpu_cfg;
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index f70de97f492a..4225f58d8f97 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -826,8 +826,6 @@ struct dpu_perf_cfg {
* @mdss_irqs: Bitmap with the irqs supported by the target
*/
struct dpu_mdss_cfg {
- u32 hwversion;
-
const struct dpu_caps *caps;
u32 mdp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index c33e7ef611a6..7d416bf4ae91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -61,7 +61,6 @@ static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
b->base_off = addr;
b->blk_off = m->ctl[i].base;
b->length = m->ctl[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_CTL;
return &m->ctl[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 4ad8991fc7d9..6f20d6b6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -169,7 +169,6 @@ static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
b->base_off = addr;
b->blk_off = m->dsc[i].base;
b->length = m->dsc[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSC;
return &m->dsc[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 355894a3b48c..3e63bf4fa64e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -83,7 +83,6 @@ static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp
dspp,
b->base_off = addr;
b->blk_off = m->dspp[i].base;
b->length = m->dspp[i].len;
- b->hwversion = m->hwversion;
b->log_mask = DPU_DBG_MASK_DSPP;
return &m->dspp[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 61284e6c313d..01bb2d84c3a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -403,7 +403,6 @@ static void __intr_offset(struct dpu_mdss_cfg *m,
{
hw->base_off = addr;
hw->blk_off = m->mdp[0].base;
- hw->hwversion = m->hwversion;
}
struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..b
Re: [PATCH v2 2/7] drm/msm/dpu: move VBIF_XINL_QOS_LVL_REMAP size to hw_catalog
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
Rather than detecting VBIF_XINL_QOS_LVL_REMAP_000 based on the
hwversion, push the offset to the hw_catalog.
Signed-off-by: Dmitry Baryshkov
This one is fine because sc7180 and sc7280 use sdm845_vbif.
All chipsets listed in the catalog are covered.
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c| 4 ++--
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 78c7d987c2ca..cff6fe3a85ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1339,6 +1339,7 @@ static const struct dpu_vbif_cfg msm8998_vbif[] = {
.default_ot_wr_limit = 32,
.features = BIT(DPU_VBIF_QOS_REMAP) | BIT(DPU_VBIF_QOS_OTLIM),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x20,
.dynamic_ot_rd_tbl = {
.count = ARRAY_SIZE(msm8998_ot_rdwr_cfg),
.cfg = msm8998_ot_rdwr_cfg,
@@ -1366,6 +1367,7 @@ static const struct dpu_vbif_cfg sdm845_vbif[] = {
.base = 0, .len = 0x1040,
.features = BIT(DPU_VBIF_QOS_REMAP),
.xin_halt_timeout = 0x4000,
+ .qos_rp_remap_size = 0x40,
.qos_rt_tbl = {
.npriority_lvl = ARRAY_SIZE(sdm845_rt_pri_lvl),
.priority_lvl = sdm845_rt_pri_lvl,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 80bc09b1f1b3..f70de97f492a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -709,6 +709,7 @@ struct dpu_vbif_qos_tbl {
* @ot_rd_limitdefault OT read limit
* @ot_wr_limitdefault OT write limit
* @xin_halt_timeout maximum time (in usec) for xin to halt
+ * @qos_rp_remap_size size of VBIF_XINL_QOS_RP_REMAP register space
* @dynamic_ot_rd_tbl dynamic OT read configuration table
* @dynamic_ot_wr_tbl dynamic OT write configuration table
* @qos_rt_tbl real-time QoS priority table
@@ -721,6 +722,7 @@ struct dpu_vbif_cfg {
u32 default_ot_rd_limit;
u32 default_ot_wr_limit;
u32 xin_halt_timeout;
+ u32 qos_rp_remap_size;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_rd_tbl;
struct dpu_vbif_dynamic_ot_tbl dynamic_ot_wr_tbl;
struct dpu_vbif_qos_tbl qos_rt_tbl;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
index b757054e1c23..046854c3fbed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
@@ -30,7 +30,7 @@
#define VBIF_XIN_HALT_CTRL0 0x0200
#define VBIF_XIN_HALT_CTRL1 0x0204
#define VBIF_XINL_QOS_RP_REMAP_0000x0550
-#define VBIF_XINL_QOS_LVL_REMAP_000(v) (v < DPU_HW_VER_400 ? 0x570 : 0x0590)
+#define VBIF_XINL_QOS_LVL_REMAP_000(vbif) (VBIF_XINL_QOS_RP_REMAP_000 +
(vbif)->cap->qos_rp_remap_size)
static void dpu_hw_clear_errors(struct dpu_hw_vbif *vbif,
u32 *pnd_errors, u32 *src_errors)
@@ -163,7 +163,7 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
c = &vbif->hw;
- reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(c->hwversion);
+ reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(vbif);
reg_high = ((xin_id & 0x8) >> 3) * 4 + (level * 8);
reg_shift = (xin_id & 0x7) * 4;
Re: [PATCH v2 1/7] drm/msm/dpu: use feature bit for LM combined alpha check
On 6/2/2022 6:30 AM, Dmitry Baryshkov wrote:
Rather than checking hwversion, follow the usual patter and add special
bit to the lm->features to check whether the LM has combined or separate
alpha registers. While we are at it, rename
dpu_hw_lm_setup_blend_config_sdm845() to
dpu_hw_lm_setup_blend_config_combined_alpha().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 17 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 +++---
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 400ebceb56bb..78c7d987c2ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -50,9 +50,12 @@
#define DMA_CURSOR_MSM8998_MASK \
(DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
-#define MIXER_SDM845_MASK \
+#define MIXER_MSM8998_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
+#define MIXER_SDM845_MASK \
+ (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER) |
BIT(DPU_MIXER_COMBINED_ALPHA))
+
#define MIXER_SC7180_MASK \
(BIT(DPU_DIM_LAYER))
@@ -936,17 +939,17 @@ static const struct dpu_lm_sub_blks msm8998_lm_sblk = {
};
static const struct dpu_lm_cfg msm8998_lm[] = {
- LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_0, LM_2, DSPP_0),
- LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_1, LM_5, DSPP_1),
- LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_2, LM_0, 0),
- LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_MAX, 0, 0),
- LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_MSM8998_MASK,
&msm8998_lm_sblk, PINGPONG_3, LM_1, 0),
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8cb6d1f25bf9..80bc09b1f1b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -145,6 +145,7 @@ enum {
* @DPU_MIXER_SOURCESPLIT Layer mixer supports source-split configuration
* @DPU_MIXER_GC Gamma correction block
* @DPU_DIM_LAYER Layer mixer supports dim layer
+ * @DPU_MIXER_COMBINED_ALPHA Layer mixer has combined alpha register
* @DPU_MIXER_MAX maximum value
*/
enum {
@@ -152,6 +153,7 @@ enum {
DPU_MIXER_SOURCESPLIT,
DPU_MIXER_GC,
DPU_DIM_LAYER,
+ DPU_MIXER_COMBINED_ALPHA,
DPU_MIXER_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 462f5082099e..25d2eba28e71 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -148,7 +148,7 @@ static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer *ctx,
u32 *misr_value)
return 0;
}
-static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
+static void dpu_hw_lm_setup_blend_config_combined_alpha(struct dpu_hw_mixer
*ctx,
u32 stage, u32 fg_alpha, u32 bg_alpha, u32 blend_op)
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
@@ -204,8 +204,8 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (m->hwversion >= DPU_HW_VER_400)
- ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
+ if (test_bit(DPU_MIXER_COMBINED_ALPHA, &features))
+ ops->setup_blend_config =
dpu_hw_lm_setup_blend_config_combined_alpha;
This will not work for all chipsets.
In the catalog you have added BIT(DPU_MIXER_COMBINED_ALPHA) only for
MIXER_SDM845_MASK but MIXER_SC7180_MASK is not updated.
HW version of sc7180 is > DPU_HW_VER_400 so this would break both sc7180
and sc7280.
Please update all the relevant chipset masks.
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
Re: [Freedreno] [PATCH] drm/msm: less magic numbers in msm_mdss_enable
On 6/1/2022 1:04 PM, Dmitry Baryshkov wrote:
On Wed, 1 Jun 2022 at 20:38, Abhinav Kumar wrote:
On 6/1/2022 2:46 AM, Dmitry Baryshkov wrote:
On Wed, 1 Jun 2022 at 01:01, Abhinav Kumar wrote:
On 5/31/2022 5:18 AM, Dmitry Baryshkov wrote:
Replace magic register writes in msm_mdss_enable() with version that
contains less magic and more variable names that can be traced back to
the dpu_hw_catalog or the downstream dtsi files.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 79 ++
1 file changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 0454a571adf7..2a48263cd1b5 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -21,6 +21,7 @@
#define HW_REV 0x0
#define HW_INTR_STATUS 0x0010
+#define UBWC_DEC_HW_VERSION 0x58
#define UBWC_STATIC 0x144
#define UBWC_CTRL_2 0x150
#define UBWC_PREDICTION_MODE0x154
@@ -132,9 +133,63 @@ static int _msm_mdss_irq_domain_add(struct msm_mdss
*msm_mdss)
return 0;
}
+#define UBWC_1_0 0x1000
+#define UBWC_2_0 0x2000
+#define UBWC_3_0 0x3000
+#define UBWC_4_0 0x4000
+
+static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss,
+u32 ubwc_static)
+{
+ writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC);
+}
+
+static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss,
+unsigned int ubwc_version,
+u32 ubwc_swizzle,
+u32 highest_bank_bit,
+u32 macrotile_mode)
+{
+ u32 value = (ubwc_swizzle & 0x1) |
+ (highest_bank_bit & 0x3) << 4 |
+ (macrotile_mode & 0x1) << 12;
+
+ if (ubwc_version == UBWC_3_0)
+ value |= BIT(10);
+
+ if (ubwc_version == UBWC_1_0)
+ value |= BIT(8);
+
+ writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
+}
+
+static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss,
+unsigned int ubwc_version,
+u32 ubwc_swizzle,
+u32 ubwc_static,
+u32 highest_bank_bit,
+u32 macrotile_mode)
+{
+ u32 value = (ubwc_swizzle & 0x7) |
+ (ubwc_static & 0x1) << 3 |
+ (highest_bank_bit & 0x7) << 4 |
+ (macrotile_mode & 0x1) << 12;
+
+ writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
+
+ if (ubwc_version == UBWC_3_0) {
+ writel_relaxed(1, msm_mdss->mmio + UBWC_CTRL_2);
+ writel_relaxed(0, msm_mdss->mmio + UBWC_PREDICTION_MODE);
+ } else {
+ writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2);
+ writel_relaxed(1, msm_mdss->mmio + UBWC_PREDICTION_MODE);
+ }
+}
+
Is it possible to unify the above functions by having the internal
ubwc_version checks?
Note, it's not the ubwc_version, it is the ubwc_dec_hw_version. And
also different functions take different sets of arguments.
It seems like msm_mdss_setup_ubwc_dec_xxx can keep growing.
I have not looked into each bit programming but from the top level so
feel free to correct if wrong but it seems both do write UBWC_STATIC
(different values based on different UBWC versions) and write some extra
registers based on version
This is what both the current code and the downstream do. See
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/zeus-s-oss/techpack/display-drivers/msm/sde/sde_hw_top.c#L312
Thanks for pointing to the downstream method for this,
This is exactly what i was also suggesting to do when I mentioned
unifying the above functions.
So instead of having a separate function for each version why not handle
all the versions in the same function like what the link you have shown
does.
I wouldn't like that. The downstream uses hw_catalog to pass all
possible parameters. We do not, so we'd have a whole set of artificial
values.
Now that you brought that up, why cannot even upstream dpu start using
catalog for ubwc settings?
/* struct dpu_mdp_cfg : MDP TOP-BLK instance info
* @id:index identifying this block
* @base: register base offset to mdss
* @features bit mask identifying sub-blocks/features
* @highest_bank_bit: UBWC parameter
* @ubwc_static: ubwc static configuration
* @ubwc_swizzle: ubwc default swizzle setting
* @clk_ctrls clock control register definition
*/
struct dpu_mdp_cfg {
DPU_HW_BLK_INFO;
u32 highest_bank_bit;
u32 ubwc_swizzle;
struct dpu_clk_ctrl_reg clk_ctrls[DPU_CLK_CTRL_MAX];
};
We already do seem to have a couple of parame
[PATCH] drm/sun4i: sun8i: Add the ability to keep scaler enabled for VI layer
According to DE2.0/DE3.0 manual VI scaler enable register is double
buffered, but de facto it doesn't, or the hardware has the shadow
register latching issues which causes single-frame picture corruption
after changing the state of scaler enable register.
Allow the user to keep the scaler always enabled, preventing the UI
glitches on the transition from scaled to unscaled state.
NOTE:
UI layer scaler has more registers with double-buffering issue and can't
be workarounded in the same manner.
You may find a python test and a demo video for this issue at [1]
[1]: https://github.com/GloDroid/glodroid_tests/issues/4
Signed-off-by: Roman Stratiienko
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 12
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 71ab0a00b4de..15cad0330f66 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -27,6 +27,18 @@
#include "sun8i_vi_layer.h"
#include "sunxi_engine.h"
+/* According to DE2.0/DE3.0 manual VI scaler enable register is double
+ * buffered, but de facto it doesn't, or the hardware has the shadow
+ * register latching issues which causes single-frame picture corruption
+ * after changing the state of scaler enable register.
+ * Allow the user to keep the scaler always enabled, preventing the UI
+ * glitches on the transition from scaled to unscaled state.
+ */
+int sun8i_vi_keep_scaler_enabled;
+MODULE_PARM_DESC(keep_vi_scaler_enabled,
+"Keep VI scaler enabled (1 = enabled, 0 = disabled
(default))");
+module_param_named(keep_vi_scaler_enabled, sun8i_vi_keep_scaler_enabled, int,
0644);
+
struct de2_fmt_info {
u32 drm_fmt;
u32 de2_fmt;
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 662ba1018cc4..f005ab883503 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -17,6 +17,8 @@
#include "sun8i_vi_layer.h"
#include "sun8i_vi_scaler.h"
+extern int sun8i_vi_keep_scaler_enabled;
+
static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer, int channel,
int overlay, bool enable, unsigned int zpos)
{
@@ -149,7 +151,7 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
*/
subsampled = format->hsub > 1 || format->vsub > 1;
- if (insize != outsize || subsampled || hphase || vphase) {
+ if (insize != outsize || subsampled || hphase || vphase ||
sun8i_vi_keep_scaler_enabled) {
unsigned int scanline, required;
struct drm_display_mode *mode;
u32 hscale, vscale, fps;
--
2.30.2
Re: [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
On 6/2/22 19:12, David Gow wrote: > On Mon, May 30, 2022 at 9:29 AM José Expósito > wrote: [snip] >> >> A .kuniconfig example is present in the cover letter. (...) > > FYI: it's also possible to run these tests under UML with the extra options: > CONFIG_VIRTIO_UML=y > CONFIG_UML_PCI_OVER_VIRTIO=y > Oh, very interesting. I didn't notice before that his example had --arch=x86_64 > I suspect it's probably better not to add those to your .kunitconfig, > as they're UML-specific and will therefore break other architectures, > but it does mean the tests can be run with, for example: > > ./tools/testing/kunit/kunit.py run --kunitconfig > drivers/gpu/drm/.kunitconfig --kconfig_add CONFIG_VIRTIO_UML=y > --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y > > Or, without the .kunitconfig: > ./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_DRM=y > --kconfig_add CONFIG_DRM_FORMAR_HELPER_TEST=y --kconfig_add > CONFIG_VIRTIO_UML=y --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y > 'drm-*' > I wonder if would make sense to have for example an arch/um/.kunitconfig with those symbols and maybe others and then the tests could also be run with something like: ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/.kunitconfig \ --kunitconfig=arch/um/.kunitconfig -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
[PATCH] drm/i915/guc: Check ctx while waiting for response
We are seeing error message of "No response for request". Some cases happened
while waiting for response and reset/suspend action was triggered. In this
case, no response is not an error, active requests will be cancelled.
This patch will handle this condition and change the error message into
debug message.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index f01325cd1b62..a30a388877e2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -467,7 +467,7 @@ static int ct_write(struct intel_guc_ct *ct,
* * 0 response received (status is valid)
* * -ETIMEDOUT no response within hardcoded timeout
*/
-static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
+static int wait_for_ct_request_update(struct ct_request *req, u32 *status,
struct intel_guc_ct *ct)
{
int err;
@@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct ct_request
*req, u32 *status)
#define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
#define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
#define done \
- (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+ (!intel_guc_ct_enabled(ct) || FIELD_GET(GUC_HXG_MSG_0_ORIGIN,
READ_ONCE(req->status)) == \
GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
if (err)
err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
#undef done
+ if (!intel_guc_ct_enabled(ct))
+ err = -ECANCELED;
*status = req->status;
return err;
@@ -703,11 +705,15 @@ static int ct_send(struct intel_guc_ct *ct,
intel_guc_notify(ct_to_guc(ct));
- err = wait_for_ct_request_update(&request, status);
+ err = wait_for_ct_request_update(&request, status, ct);
g2h_release_space(ct, GUC_CTB_HXG_MSG_MAX_LEN);
if (unlikely(err)) {
- CT_ERROR(ct, "No response for request %#x (fence %u)\n",
-action[0], request.fence);
+ if (unlikely(err == ECANCELED))
+ CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB
is disabled\n",
+ action[0], request.fence);
+ else
+ CT_ERROR(ct, "No response for request %#x (fence %u)\n",
+ action[0], request.fence);
goto unlink;
}
@@ -771,8 +777,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
ret = ct_send(ct, action, len, response_buf, response_buf_size,
&status);
if (unlikely(ret < 0)) {
- CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
-action[0], ERR_PTR(ret), status);
+ if (likely(ret != ECANCELED))
+ CT_ERROR(ct, "Sending action %#x failed (%pe)
status=%#X\n",
+ action[0], ERR_PTR(ret), status);
} else if (unlikely(ret)) {
CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
action[0], ret, ret);
--
2.36.0
Re: [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Hello David, On 6/2/22 19:07, David Gow wrote: > On Thu, Jun 2, 2022 at 9:27 AM Javier Martinez Canillas [snip] >> >> And doing that will also allow you to get rid of this, since just selecting >> CONFIG_DRM_KUNIT_TEST=y would be enough for the tests built and run by KUnit. >> > > This is definitely something other KUnit tests (apparmor, elf, etc) > are doing, and it's generally fine. You do lose the ability to build > the tests as a separate module, though. (This is not usually a big > problem, but there are some cases where it's useful.) > > That being said, I don't think 'select' is enough of a problem that > you should feel the need to refactor in this way just to avoid it. Oh, yes I didn't want to imply that this was the main reason but just pointed out that wouldn't even be needed if done that way. And it is something that we want to do anyway IMO, since as mentioned it would allow to test the static functions, which are the majority the format helpers in that file. > Given most of the other DRM drivers (as well as DRM_DEBUG_SELFTEST) > are select-ing DRM_KMS_HELPER, it seems like a sensible enough thing > to continue doing for the KUnit test. As Daniel pointed out, as a > hidden option it was clearly always meant to be select-ed anyway. > Yes, it can be done from the DRM_KUNIT_TEST symbol or just have it set (and any other needed DRM helper libraries tested by other suites) in the .kunitconfig file. I don't think is that important, since at the end that dependency will have to be maintained in some place. > Cheers, > -- David > -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: How should "max bpc" and "Colorspace" KMS property work?
On Thu, Jun 02, 2022 at 07:08:33PM +0200, Sebastian Wick wrote: > On Thu, Jun 2, 2022 at 6:40 PM Ville Syrjälä > wrote: > > > > On Thu, Jun 02, 2022 at 10:47:59AM +0300, Pekka Paalanen wrote: > > > On Wed, 1 Jun 2022 17:06:25 +0300 > > > Ville Syrjälä wrote: > > > > > > > On Wed, Jun 01, 2022 at 10:21:26AM +0300, Pekka Paalanen wrote: > > > > > On Tue, 31 May 2022 20:37:31 +0300 > > > > > Ville Syrjälä wrote: > > > > > > > > > > > On Wed, May 25, 2022 at 01:36:47PM +0300, Pekka Paalanen wrote: > > > > > > > On Wed, 25 May 2022 09:23:51 + > > > > > > > Simon Ser wrote: > > > > > > > > > > > > > > > On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Mind that "max bpc" is always in auto. It's only an upper > > > > > > > > > > limit, with > > > > > > > > > > the assumption that the driver can choose less. > > > > > > > > > > > > > > > > > > It seems to me like the "max bpc" property is just kind of > > > > > > > > > bad API, > > > > > > > > > and trying to tweak it to cater to more use cases as we > > > > > > > > > discover them > > > > > > > > > will take us down a rabbit hole. It seems better to replace > > > > > > > > > it with > > > > > > > > > new properties which allow user space to determine the current > > > > > > > > > effective bpc and to explicitly control it. > > > > > > > > > > > > > > > > +1, this sounds much more robust, and allows better control by > > > > > > > > user-space. > > > > > > > > User-space needs to have fallback logic for other state as well > > > > > > > > anyways. > > > > > > > > If the combinatorial explosion is too much, we should think > > > > > > > > about optimizing > > > > > > > > the KMS implementation, or improve the uAPI. > > > > > > > > > > > > > > +1 as well, with some recommendations added and the running off > > > > > > > to the > > > > > > > sunset: > > > > > > > > > > > > > > Use two separate KMS properties for reporting current vs. > > > > > > > programming desired. The KMS property reporting the current value > > > > > > > must be read-only (immutable). This preserves the difference > > > > > > > between > > > > > > > what userspace wanted and what it got, making it possible to read > > > > > > > back both without confusing them. It also allows preserving > > > > > > > driver behaviour > > > > > > > > > > > > I don't see much real point in a property to report the current bpc. > > > > > > That can't be used to do anything atomically. So I suppose plymouth > > > > > > would be the only user. > > > > > > > > > > Hi Ville, > > > > > > > > > > I think also professional color managed display servers would need it. > > > > > > > > > > If they detect that the link bpc is no longer the same as it was when > > > > > the monitor was profiled, the profile will need to be re-verified by > > > > > measuring the monitor again. > > > > > > > > > > See "Color calibration auditing system" notes in > > > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/467 > > > > > description. > > > > > > > > > > > So IMO if someone really need explicit control over this then we > > > > > > should just expose properties to set things explicitly. So we'd > > > > > > need at least props for the actual bpc and some kind of color > > > > > > encoding property (RGB/YCbCr 4:4:4/4:2:2:/4:2:0, etc.). And someone > > > > > > would really need to figure out how DSC would interact with those. > > > > > > > > > > I believe there still must be "auto" setting for bpc, and a separate > > > > > feedback property, so that userspace can use "auto" to see what it can > > > > > get without doing thousands of TEST_ONLY commits plus a few "link > > > > > status" failure handlings in order to find a working configuration > > > > > (I'm > > > > > assuming we have many more properties than just "max bpc" to figure > > > > > out). After "auto" has told userspace what actually works without > > > > > blind > > > > > trial and error, then userspace can program than value explicitly to > > > > > make sure it doesn't change accidentally in the future. > > > > > > > > Yeah we need "auto", but IMO mainly just to keep the current userspace > > > > working. Using that to probe what's possible doesn't sound particularly > > > > workable since you can't use it with TEST_ONLY commits. Also change to > > > > some other property could still cause the whole thing to fail after the > > > > max bpc has been probed so not sure it really buys you anything. > > > > > > Hi Ville, > > > > > > earlier in this thread I drafted how the property-pair with "auto" > > > could be made useful also with TEST_ONLY commits: > > > > > > > Thinking even further, about the problem of TEST_ONLY commits not > > > > telling you what "auto" settings would actually give you; there could > > > > be a new/extended KMS ioctl that would be the same as commit now, but > > > > allow the kernel to return another set of KMS state back with > > > > TEST_ONLY. Like reading bac
Re: [PATCH v1 06/13] drm/probe-helper: make .get_modes() optional, add default action
On Tue, May 24, 2022 at 01:39:28PM +0300, Jani Nikula wrote:
> Add default action when .get_modes() not set. This also defines what a
> .get_modes() hook should do.
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_probe_helper.c | 14 +-
> include/drm/drm_modeset_helper_vtables.h | 4
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 836bcd5b4cb6..9df17f0ae225 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -360,7 +360,19 @@ static int drm_helper_probe_get_modes(struct
> drm_connector *connector)
> connector->helper_private;
> int count;
>
> - count = connector_funcs->get_modes(connector);
> + if (connector_funcs->get_modes) {
> + count = connector_funcs->get_modes(connector);
> + } else {
> + const struct drm_edid *drm_edid;
> +
> + /* Note: This requires connector->ddc is set */
> + drm_edid = drm_edid_read(connector);
> +
> + /* Update modes etc. from the EDID */
> + count = drm_edid_connector_update(connector, drm_edid);
> +
> + drm_edid_free(drm_edid);
> + }
Not really a huge fan of this automagic fallback. I think I'd prefer
to keep it mandatory and just provide this as a helper for drivers to
plug into the right spot. Otherwise I'm sure I'll forget how this works
and then I'll be confused when I see a connector withput any apparent
.get_modes() implementation.
>
> /*
>* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index fafa70ac1337..b4402bc64e57 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -894,6 +894,10 @@ struct drm_connector_helper_funcs {
>* libraries always call this with the &drm_mode_config.connection_mutex
>* held. Because of this it's safe to inspect &drm_connector->state.
>*
> + * This callback is optional. By default, it reads the EDID using
> + * drm_edid_read() and updates the connector display info, modes, and
> + * properties using drm_edid_connector_update().
> + *
>* RETURNS:
>*
>* The number of modes added by calling drm_mode_probed_add().
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [PATCH v1 04/13] drm/edid: add drm_edid_connector_update()
On Tue, May 24, 2022 at 01:39:26PM +0300, Jani Nikula wrote:
> Add a new function drm_edid_connector_update() to replace the
> combination of calls drm_connector_update_edid_property() and
> drm_add_edid_modes(). Usually they are called in the drivers in this
> order, however the former needs information from the latter.
>
> This is all in drm_edid.c simply to keep struct drm_edid opaque.
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_connector.c | 2 +
> drivers/gpu/drm/drm_edid.c | 71 +++--
> include/drm/drm_edid.h | 2 +
> 3 files changed, 71 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1c48d162c77e..ae9c640a641a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2088,6 +2088,8 @@ EXPORT_SYMBOL(drm_connector_set_tile_property);
> * set the connector's tile property here. See
> drm_connector_set_tile_property()
> * for more details.
> *
> + * This function is deprecated. Use drm_edid_connector_update() instead.
> + *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0d640e7dcff7..09328298aabf 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6127,8 +6127,8 @@ static int add_displayid_detailed_modes(struct
> drm_connector *connector,
> return num_modes;
> }
>
> -static int drm_edid_connector_update(struct drm_connector *connector,
> - const struct drm_edid *drm_edid)
> +static int _drm_edid_connector_update(struct drm_connector *connector,
> + const struct drm_edid *drm_edid)
> {
> int num_modes = 0;
> u32 quirks;
> @@ -6191,6 +6191,67 @@ static int drm_edid_connector_update(struct
> drm_connector *connector,
> return num_modes;
> }
>
> +static void _drm_update_tile_info(struct drm_connector *connector,
> + const struct drm_edid *drm_edid);
> +
> +/**
> + * drm_edid_connector_update - Update connector information from EDID
> + * @connector: Connector
> + * @drm_edid: EDID
> + *
> + * Update the connector mode list, display info, ELD, HDR metadata, relevant
> + * properties, etc. from the passed in EDID.
> + *
> + * If EDID is NULL, reset the information.
> + *
> + * Return: The number of modes added or 0 if we couldn't find any.
> + */
> +int drm_edid_connector_update(struct drm_connector *connector,
> + const struct drm_edid *drm_edid)
> +{
> + struct drm_device *dev = connector->dev;
> + const struct edid *old_edid = connector->edid_blob_ptr ?
> + connector->edid_blob_ptr->data : NULL;
> + const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
> + size_t size = drm_edid ? drm_edid->size : 0;
> + int count, ret;
> +
> + count = _drm_edid_connector_update(connector, drm_edid);
> +
> + _drm_update_tile_info(connector, drm_edid);
> +
> + if (old_edid && !drm_edid_are_equal(edid, old_edid)) {
> + connector->epoch_counter++;
> +
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID changed, epoch counter
> %llu\n",
> + connector->base.id, connector->name,
> + connector->epoch_counter);
There was some recent discussion on the blob IDs changing willy nilly.
We could avoid some of that by bailing out here if nothing changed.
But that's not really something that should be done in this patch.
> + }
> +
> + ret = drm_property_replace_global_blob(dev, &connector->edid_blob_ptr,
> +size, edid,
> +&connector->base,
> +dev->mode_config.edid_property);
> + if (ret)
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID property update failed
> (%d)\n",
> + connector->base.id, connector->name, ret);
> +
> + ret = drm_object_property_set_value(&connector->base,
> +
> dev->mode_config.non_desktop_property,
> +
> connector->display_info.non_desktop);
> + if (ret)
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Non-desktop property update
> failed (%d)\n",
> + connector->base.id, connector->name, ret);
> +
> + ret = drm_connector_set_tile_property(connector);
> + if (ret)
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Tile property update failed
> (%d)\n",
> + connector->base.id, connector->name, ret);
I was a bit confused why this function is needed, until I recalled that
the EDID read thing you introduce in the earlier patch doesn't do
any of this (unlike the old function). Woul
Re: How should "max bpc" and "Colorspace" KMS property work?
On Thu, Jun 2, 2022 at 6:40 PM Ville Syrjälä wrote: > > On Thu, Jun 02, 2022 at 10:47:59AM +0300, Pekka Paalanen wrote: > > On Wed, 1 Jun 2022 17:06:25 +0300 > > Ville Syrjälä wrote: > > > > > On Wed, Jun 01, 2022 at 10:21:26AM +0300, Pekka Paalanen wrote: > > > > On Tue, 31 May 2022 20:37:31 +0300 > > > > Ville Syrjälä wrote: > > > > > > > > > On Wed, May 25, 2022 at 01:36:47PM +0300, Pekka Paalanen wrote: > > > > > > On Wed, 25 May 2022 09:23:51 + > > > > > > Simon Ser wrote: > > > > > > > > > > > > > On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer > > > > > > > wrote: > > > > > > > > > > > > > > > > Mind that "max bpc" is always in auto. It's only an upper > > > > > > > > > limit, with > > > > > > > > > the assumption that the driver can choose less. > > > > > > > > > > > > > > > > It seems to me like the "max bpc" property is just kind of bad > > > > > > > > API, > > > > > > > > and trying to tweak it to cater to more use cases as we > > > > > > > > discover them > > > > > > > > will take us down a rabbit hole. It seems better to replace it > > > > > > > > with > > > > > > > > new properties which allow user space to determine the current > > > > > > > > effective bpc and to explicitly control it. > > > > > > > > > > > > > > +1, this sounds much more robust, and allows better control by > > > > > > > user-space. > > > > > > > User-space needs to have fallback logic for other state as well > > > > > > > anyways. > > > > > > > If the combinatorial explosion is too much, we should think about > > > > > > > optimizing > > > > > > > the KMS implementation, or improve the uAPI. > > > > > > > > > > > > +1 as well, with some recommendations added and the running off to > > > > > > the > > > > > > sunset: > > > > > > > > > > > > Use two separate KMS properties for reporting current vs. > > > > > > programming desired. The KMS property reporting the current value > > > > > > must be read-only (immutable). This preserves the difference between > > > > > > what userspace wanted and what it got, making it possible to read > > > > > > back both without confusing them. It also allows preserving driver > > > > > > behaviour > > > > > > > > > > I don't see much real point in a property to report the current bpc. > > > > > That can't be used to do anything atomically. So I suppose plymouth > > > > > would be the only user. > > > > > > > > Hi Ville, > > > > > > > > I think also professional color managed display servers would need it. > > > > > > > > If they detect that the link bpc is no longer the same as it was when > > > > the monitor was profiled, the profile will need to be re-verified by > > > > measuring the monitor again. > > > > > > > > See "Color calibration auditing system" notes in > > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/467 description. > > > > > > > > > So IMO if someone really need explicit control over this then we > > > > > should just expose properties to set things explicitly. So we'd > > > > > need at least props for the actual bpc and some kind of color > > > > > encoding property (RGB/YCbCr 4:4:4/4:2:2:/4:2:0, etc.). And someone > > > > > would really need to figure out how DSC would interact with those. > > > > > > > > I believe there still must be "auto" setting for bpc, and a separate > > > > feedback property, so that userspace can use "auto" to see what it can > > > > get without doing thousands of TEST_ONLY commits plus a few "link > > > > status" failure handlings in order to find a working configuration (I'm > > > > assuming we have many more properties than just "max bpc" to figure > > > > out). After "auto" has told userspace what actually works without blind > > > > trial and error, then userspace can program than value explicitly to > > > > make sure it doesn't change accidentally in the future. > > > > > > Yeah we need "auto", but IMO mainly just to keep the current userspace > > > working. Using that to probe what's possible doesn't sound particularly > > > workable since you can't use it with TEST_ONLY commits. Also change to > > > some other property could still cause the whole thing to fail after the > > > max bpc has been probed so not sure it really buys you anything. > > > > Hi Ville, > > > > earlier in this thread I drafted how the property-pair with "auto" > > could be made useful also with TEST_ONLY commits: > > > > > Thinking even further, about the problem of TEST_ONLY commits not > > > telling you what "auto" settings would actually give you; there could > > > be a new/extended KMS ioctl that would be the same as commit now, but > > > allow the kernel to return another set of KMS state back with > > > TEST_ONLY. Like reading back all KMS state after commit was done for > > > real. The "current" KMS properties would be part of that set, and tell > > > userspace what would happen in a real commit. > > > > I do believe the combinatorial explosion of the KMS state search space > > to find a working configuration is going to be a v
Re: [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid
On Thu, 02 Jun 2022, Ville Syrjälä wrote:
> On Tue, May 24, 2022 at 01:39:23PM +0300, Jani Nikula wrote:
>> Add drm_edid based block count and data access helper functions that
>> take the EDID allocated size into account.
>>
>> At the moment, the allocated size should always match the EDID size
>> indicated by the extension count, but this will change in the future.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 42 +++---
>> 1 file changed, 35 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 929fc0e46751..682d954a9e42 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const
>> struct edid *edid, int index)
>> return edid_block_data(edid, index + 1);
>> }
>>
>> +static int drm_edid_block_count(const struct drm_edid *drm_edid)
>> +{
>> +int num_blocks;
>> +
>> +/* Starting point */
>> +num_blocks = edid_block_count(drm_edid->edid);
>> +
>> +/* Limit by allocated size */
>> +num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
>
> Hmm. Is there a particular reason we couldn't just always
> return drm_edid->size/EDID_LENGTH here? That is, why would we not
> set drm_edid->size to always reflect the actual size of the EDID?
Basically playing it safe for obscure cases and the future. For example
EDIDs originating from firmware, debugfs or i915 opregion could have a
bigger size than indicated by the extension count, if we want to go to a
direction where it's really just a blob with size.
BR,
Jani.
>
>> +
>> +return num_blocks;
>> +}
>> +
>> +static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
>> +{
>> +return drm_edid_block_count(drm_edid) - 1;
>> +}
>> +
>> +static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int
>> index)
>> +{
>> +return edid_block_data(drm_edid->edid, index);
>> +}
>> +
>> +static const void *drm_edid_extension_block_data(const struct drm_edid
>> *drm_edid,
>> + int index)
>> +{
>> +return edid_extension_block_data(drm_edid->edid, index);
>> +}
>> +
>> /*
>> * Initializer helper for legacy interfaces, where we have no choice but to
>> * trust edid size. Not for general purpose use.
>> @@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct
>> drm_edid_iter *iter)
>> if (!iter->drm_edid)
>> return NULL;
>>
>> -if (iter->index < edid_block_count(iter->drm_edid->edid))
>> -block = edid_block_data(iter->drm_edid->edid, iter->index++);
>> +if (iter->index < drm_edid_block_count(iter->drm_edid))
>> +block = drm_edid_block_data(iter->drm_edid, iter->index++);
>>
>> return block;
>> }
>> @@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector
>> *connector,
>> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
>>int ext_id, int *ext_index)
>> {
>> -const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
>> const u8 *edid_ext = NULL;
>> int i;
>>
>> /* No EDID or EDID extensions */
>> -if (!edid || !edid_extension_block_count(edid))
>> +if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
>> return NULL;
>>
>> /* Find CEA extension */
>> -for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
>> -edid_ext = edid_extension_block_data(edid, i);
>> +for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++)
>> {
>> +edid_ext = drm_edid_extension_block_data(drm_edid, i);
>> if (edid_block_tag(edid_ext) == ext_id)
>> break;
>> }
>>
>> -if (i >= edid_extension_block_count(edid))
>> +if (i >= drm_edid_extension_block_count(drm_edid))
>> return NULL;
>>
>> *ext_index = i + 1;
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 07/14] leds: flashlight: mt6370: Add Mediatek MT6370 flashlight support
Thank you for the valuable suggestion.
Andy Shevchenko 於 2022年6月1日 週三 下午5:57寫道：
>
> On Tue, May 31, 2022 at 1:32 PM ChiaEn Wu wrote:
> >
> > From: Alice Chen
> >
> > Add Mediatek MT6370 flashlight support
>
> Same comments about the commit message.
>
> ...
>
> > +#include
> > +#include
> > +#include
>
> + blank line?
Thanks, this will be refined in the new version.
>
> > +#include
>
> + blank line
Thanks, this will be refined in the new version.
>
> > +enum {
> > + MT6370_LED_FLASH1,
> > + MT6370_LED_FLASH2,
> > + MT6370_MAX_LEDS
> > +};
>
> ...
>
> > + struct mt6370_led *led = container_of(fl_cdev, struct mt6370_led,
> > + flash);
>
> > + struct mt6370_led *led = container_of(fl_cdev, struct mt6370_led,
> > + flash);
>
> Make a helper out of this
>
> #define to_mt637_led() container_of()
>
> and reuse.
Thanks, this will be refined in the new version.
>
> ...
>
> > + /*
> > +* For the flash turn on/off, HW rampping up/down time is 5ms/500us,
>
> ramping
>
> > +* respectively
>
> Period!
Thanks, this will be refined in the new version.
>
> > +*/
>
> ...
>
> > + const char * const states[] = { "off", "keep", "on" };
> > + const char *str;
> > + int ret;
> > +
> > + if (!fwnode_property_read_string(init_data->fwnode,
> > +"default-state", &str)) {
> > + ret = match_string(states, ARRAY_SIZE(states), str);
> > + if (ret < 0)
> > + ret = STATE_OFF;
> > +
> > + led->default_state = ret;
> > + }
>
> fwnode_property_match_string()?
Sorry, but I think the use of this function is different from my target.
I want to read the string of the "default-state" property and figure
out if the string is in the states array.
But the fwnode_property_match_string aimed to figure out if the state
in the property array.
One is a property array and another one is a state array.
>
> ...
>
> > + if (!count || count > MT6370_MAX_LEDS) {
> > + dev_err(&pdev->dev,
> > + "No child node or node count over max led number %lu\n",
> > count);
> > + return -EINVAL;
>
> return dev_err_probe(...);
Thanks, will refine in the new version
>
> > + }
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Sincerely,
Alice Chen
[PATCH] fbdev: simplefb: Check before clk_put() not needed
clk_put() already checks the clk ptr using !clk and IS_ERR()
so there is no need to check it again before calling it.
Signed-off-by: Yihao Han
---
drivers/video/fbdev/simplefb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 2c198561c338..f96ce8801be4 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -237,8 +237,7 @@ static int simplefb_clocks_get(struct simplefb_par *par,
if (IS_ERR(clock)) {
if (PTR_ERR(clock) == -EPROBE_DEFER) {
while (--i >= 0) {
- if (par->clks[i])
- clk_put(par->clks[i]);
+ clk_put(par->clks[i]);
}
kfree(par->clks);
return -EPROBE_DEFER;
--
2.17.1
Re: [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid
On Tue, May 24, 2022 at 01:39:23PM +0300, Jani Nikula wrote:
> Add drm_edid based block count and data access helper functions that
> take the EDID allocated size into account.
>
> At the moment, the allocated size should always match the EDID size
> indicated by the extension count, but this will change in the future.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 42 +++---
> 1 file changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 929fc0e46751..682d954a9e42 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const
> struct edid *edid, int index)
> return edid_block_data(edid, index + 1);
> }
>
> +static int drm_edid_block_count(const struct drm_edid *drm_edid)
> +{
> + int num_blocks;
> +
> + /* Starting point */
> + num_blocks = edid_block_count(drm_edid->edid);
> +
> + /* Limit by allocated size */
> + num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
Hmm. Is there a particular reason we couldn't just always
return drm_edid->size/EDID_LENGTH here? That is, why would we not
set drm_edid->size to always reflect the actual size of the EDID?
> +
> + return num_blocks;
> +}
> +
> +static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
> +{
> + return drm_edid_block_count(drm_edid) - 1;
> +}
> +
> +static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int
> index)
> +{
> + return edid_block_data(drm_edid->edid, index);
> +}
> +
> +static const void *drm_edid_extension_block_data(const struct drm_edid
> *drm_edid,
> + int index)
> +{
> + return edid_extension_block_data(drm_edid->edid, index);
> +}
> +
> /*
> * Initializer helper for legacy interfaces, where we have no choice but to
> * trust edid size. Not for general purpose use.
> @@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct
> drm_edid_iter *iter)
> if (!iter->drm_edid)
> return NULL;
>
> - if (iter->index < edid_block_count(iter->drm_edid->edid))
> - block = edid_block_data(iter->drm_edid->edid, iter->index++);
> + if (iter->index < drm_edid_block_count(iter->drm_edid))
> + block = drm_edid_block_data(iter->drm_edid, iter->index++);
>
> return block;
> }
> @@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector
> *connector,
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index)
> {
> - const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
> const u8 *edid_ext = NULL;
> int i;
>
> /* No EDID or EDID extensions */
> - if (!edid || !edid_extension_block_count(edid))
> + if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
> return NULL;
>
> /* Find CEA extension */
> - for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
> - edid_ext = edid_extension_block_data(edid, i);
> + for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++)
> {
> + edid_ext = drm_edid_extension_block_data(drm_edid, i);
> if (edid_block_tag(edid_ext) == ext_id)
> break;
> }
>
> - if (i >= edid_extension_block_count(edid))
> + if (i >= drm_edid_extension_block_count(drm_edid))
> return NULL;
>
> *ext_index = i + 1;
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: How should "max bpc" and "Colorspace" KMS property work?
On Thu, Jun 02, 2022 at 10:47:59AM +0300, Pekka Paalanen wrote: > On Wed, 1 Jun 2022 17:06:25 +0300 > Ville Syrjälä wrote: > > > On Wed, Jun 01, 2022 at 10:21:26AM +0300, Pekka Paalanen wrote: > > > On Tue, 31 May 2022 20:37:31 +0300 > > > Ville Syrjälä wrote: > > > > > > > On Wed, May 25, 2022 at 01:36:47PM +0300, Pekka Paalanen wrote: > > > > > On Wed, 25 May 2022 09:23:51 + > > > > > Simon Ser wrote: > > > > > > > > > > > On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer > > > > > > wrote: > > > > > > > > > > > > > > Mind that "max bpc" is always in auto. It's only an upper > > > > > > > > limit, with > > > > > > > > the assumption that the driver can choose less. > > > > > > > > > > > > > > It seems to me like the "max bpc" property is just kind of bad > > > > > > > API, > > > > > > > and trying to tweak it to cater to more use cases as we discover > > > > > > > them > > > > > > > will take us down a rabbit hole. It seems better to replace it > > > > > > > with > > > > > > > new properties which allow user space to determine the current > > > > > > > effective bpc and to explicitly control it. > > > > > > > > > > > > +1, this sounds much more robust, and allows better control by > > > > > > user-space. > > > > > > User-space needs to have fallback logic for other state as well > > > > > > anyways. > > > > > > If the combinatorial explosion is too much, we should think about > > > > > > optimizing > > > > > > the KMS implementation, or improve the uAPI. > > > > > > > > > > +1 as well, with some recommendations added and the running off to the > > > > > sunset: > > > > > > > > > > Use two separate KMS properties for reporting current vs. > > > > > programming desired. The KMS property reporting the current value > > > > > must be read-only (immutable). This preserves the difference between > > > > > what userspace wanted and what it got, making it possible to read > > > > > back both without confusing them. It also allows preserving driver > > > > > behaviour > > > > > > > > I don't see much real point in a property to report the current bpc. > > > > That can't be used to do anything atomically. So I suppose plymouth > > > > would be the only user. > > > > > > Hi Ville, > > > > > > I think also professional color managed display servers would need it. > > > > > > If they detect that the link bpc is no longer the same as it was when > > > the monitor was profiled, the profile will need to be re-verified by > > > measuring the monitor again. > > > > > > See "Color calibration auditing system" notes in > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/467 description. > > > > > > > So IMO if someone really need explicit control over this then we > > > > should just expose properties to set things explicitly. So we'd > > > > need at least props for the actual bpc and some kind of color > > > > encoding property (RGB/YCbCr 4:4:4/4:2:2:/4:2:0, etc.). And someone > > > > would really need to figure out how DSC would interact with those. > > > > > > I believe there still must be "auto" setting for bpc, and a separate > > > feedback property, so that userspace can use "auto" to see what it can > > > get without doing thousands of TEST_ONLY commits plus a few "link > > > status" failure handlings in order to find a working configuration (I'm > > > assuming we have many more properties than just "max bpc" to figure > > > out). After "auto" has told userspace what actually works without blind > > > trial and error, then userspace can program than value explicitly to > > > make sure it doesn't change accidentally in the future. > > > > Yeah we need "auto", but IMO mainly just to keep the current userspace > > working. Using that to probe what's possible doesn't sound particularly > > workable since you can't use it with TEST_ONLY commits. Also change to > > some other property could still cause the whole thing to fail after the > > max bpc has been probed so not sure it really buys you anything. > > Hi Ville, > > earlier in this thread I drafted how the property-pair with "auto" > could be made useful also with TEST_ONLY commits: > > > Thinking even further, about the problem of TEST_ONLY commits not > > telling you what "auto" settings would actually give you; there could > > be a new/extended KMS ioctl that would be the same as commit now, but > > allow the kernel to return another set of KMS state back with > > TEST_ONLY. Like reading back all KMS state after commit was done for > > real. The "current" KMS properties would be part of that set, and tell > > userspace what would happen in a real commit. > > I do believe the combinatorial explosion of the KMS state search space > to find a working configuration is going to be a very real problem > sooner or later. That's seems like an orthogonal issue that would need some kind of new uapi approach that let's you get some state back out from TEST_ONLY commits. > > > Now that
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Thu, Jun 02, 2022 at 08:42:13AM +0300, Lionel Landwerlin wrote: > On 02/06/2022 00:18, Matthew Brost wrote: > > On Wed, Jun 01, 2022 at 05:25:49PM +0300, Lionel Landwerlin wrote: > > > On 17/05/2022 21:32, Niranjana Vishwanathapura wrote: > > > > +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the > > > > mapping in an > > > > +async worker. The binding and unbinding will work like a special GPU > > > > engine. > > > > +The binding and unbinding operations are serialized and will wait on > > > > specified > > > > +input fences before the operation and will signal the output fences > > > > upon the > > > > +completion of the operation. Due to serialization, completion of an > > > > operation > > > > +will also indicate that all previous operations are also complete. > > > I guess we should avoid saying "will immediately start binding/unbinding" > > > if > > > there are fences involved. > > > > > > And the fact that it's happening in an async worker seem to imply it's not > > > immediate. > > > > > > > > > I have a question on the behavior of the bind operation when no input > > > fence > > > is provided. Let say I do : > > > > > > VM_BIND (out_fence=fence1) > > > > > > VM_BIND (out_fence=fence2) > > > > > > VM_BIND (out_fence=fence3) > > > > > > > > > In what order are the fences going to be signaled? > > > > > > In the order of VM_BIND ioctls? Or out of order? > > > > > > Because you wrote "serialized I assume it's : in order > > > > > > > > > One thing I didn't realize is that because we only get one "VM_BIND" > > > engine, > > > there is a disconnect from the Vulkan specification. > > > > > > In Vulkan VM_BIND operations are serialized but per engine. > > > > > > So you could have something like this : > > > > > > VM_BIND (engine=rcs0, in_fence=fence1, out_fence=fence2) > > > > > > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > > > > Question - let's say this done after the above operations: > > > > EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) > > > > Is the exec ordered with respected to bind (i.e. would fence3 & 4 be > > signaled before the exec starts)? > > > > Matt > > > Hi Matt, > > From the vulkan point of view, everything is serialized within an engine (we > map that to a VkQueue). > > So with : > > EXEC (engine=ccs0, in_fence=NULL, out_fence=NULL) > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > EXEC completes first then VM_BIND executes. > > > To be even clearer : > > EXEC (engine=ccs0, in_fence=fence2, out_fence=NULL) > VM_BIND (engine=ccs0, in_fence=fence3, out_fence=fence4) > > > EXEC will wait until fence2 is signaled. > Once fence2 is signaled, EXEC proceeds, finishes and only after it is done, > VM_BIND executes. > > It would kind of like having the VM_BIND operation be another batch executed > from the ringbuffer buffer. > Yea this makes sense. I think of VM_BINDs as more or less just another version of an EXEC and this fits with that. In practice I don't think we can share a ring but we should be able to present an engine (again likely a gem context in i915) to the user that orders VM_BINDs / EXECs if that is what Vulkan expects, at least I think. Hopefully Niranjana + Daniel agree. Matt > -Lionel > > > > > > > fence1 is not signaled > > > > > > fence3 is signaled > > > > > > So the second VM_BIND will proceed before the first VM_BIND. > > > > > > > > > I guess we can deal with that scenario in userspace by doing the wait > > > ourselves in one thread per engines. > > > > > > But then it makes the VM_BIND input fences useless. > > > > > > > > > Daniel : what do you think? Should be rework this or just deal with wait > > > fences in userspace? > > > > > > > > > Sorry I noticed this late. > > > > > > > > > -Lionel > > > > > > >
Re: [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Hello José, On 5/30/22 12:20, José Expósito wrote: > Test the conversion from XRGB to RGB332. > > What is tested? > > - Different values for the X in XRGB to make sure it is ignored > - Different clip values: Single pixel and full and partial buffer > - Well know colors: White, black, red, green, blue, magenta, yellow >and cyan > - Other colors: Randomly picked > - Destination pitch > > Suggested-by: Javier Martinez Canillas > Signed-off-by: José Expósito > --- Thanks a lot for working on this! It's very cool to see the first KUnit tests added to DRM :) > drivers/gpu/drm/Kconfig | 12 ++ > drivers/gpu/drm/Makefile | 3 + > drivers/gpu/drm/drm_format_helper_test.c | 166 +++ > 3 files changed, 181 insertions(+) > create mode 100644 drivers/gpu/drm/drm_format_helper_test.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index e88c497fa010..d92be6faef15 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -76,6 +76,18 @@ config DRM_KMS_HELPER > help > CRTC helpers for KMS drivers. > > +config DRM_FORMAR_HELPER_TEST I wonder if we want this level of detail for the test Kconfig symbols. Maybe we could just have a DRM_KUNIT_TEST symbol that will enable all the KUnit test suites for DRM ? > + bool "drm_format_helper tests" if !KUNIT_ALL_TESTS > + depends on DRM && KUNIT=y > + select DRM_KMS_HELPER Daniel didn't like this `select DRM_KMS_HELPER` and I think that we can avoid it if instead drm_format_helper_test.c is included in drm_format_helper.c, i.e: diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c index a3ccd8bc966f..d63e02da528f 100644 --- a/drivers/gpu/drm/drm_format_helper.c +++ b/drivers/gpu/drm/drm_format_helper.c @@ -692,3 +692,7 @@ void drm_fb_xrgb_to_mono(void *dst, unsigned int dst_pitch, const void *vadd kfree(src32); } EXPORT_SYMBOL(drm_fb_xrgb_to_mono); + +#ifdef DRM_KUNIT_TEST +#include "drm_format_helper_test.c" +#endif This also has the advantage that will allow to have KUnit tests for the static functions that are only available in the drm_format_helper.c compilation unit. > obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ > +obj-$(CONFIG_DRM_FORMAR_HELPER_TEST) += drm_kms_helper.o \ > + drm_format_helper_test.o And doing that will also allow you to get rid of this, since just selecting CONFIG_DRM_KUNIT_TEST=y would be enough for the tests built and run by KUnit. > +CFLAGS_drm_format_helper_test.o += $(DISABLE_STRUCTLEAK_PLUGIN) > A comment on why this is needed would useful. -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
[PATCH] drm/tegra: dc: rgb: Fix refcount leak in tegra_dc_rgb_probe
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
So add of_node_put() in error paths.
Fixes: format:d8f4a9eda006 ("drm: Add NVIDIA Tegra20 support")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/tegra/rgb.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index ff8fce36d2aa..cef2b1b72385 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -196,12 +196,16 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc)
int err;
np = of_get_child_by_name(dc->dev->of_node, "rgb");
- if (!np || !of_device_is_available(np))
- return -ENODEV;
+ if (!np || !of_device_is_available(np)) {
+ err = -ENODEV;
+ goto err_put_node;
+ }
rgb = devm_kzalloc(dc->dev, sizeof(*rgb), GFP_KERNEL);
- if (!rgb)
- return -ENOMEM;
+ if (!rgb) {
+ err = -ENOMEM;
+ goto err_put_node;
+ }
rgb->output.dev = dc->dev;
rgb->output.of_node = np;
@@ -209,31 +213,34 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc)
err = tegra_output_probe(&rgb->output);
if (err < 0)
- return err;
+ goto err_put_node;
+
rgb->clk = devm_clk_get(dc->dev, NULL);
if (IS_ERR(rgb->clk)) {
dev_err(dc->dev, "failed to get clock\n");
- return PTR_ERR(rgb->clk);
+ err = PTR_ERR(rgb->clk);
+ goto err_put_node;
}
rgb->clk_parent = devm_clk_get(dc->dev, "parent");
if (IS_ERR(rgb->clk_parent)) {
dev_err(dc->dev, "failed to get parent clock\n");
- return PTR_ERR(rgb->clk_parent);
+ err = PTR_ERR(rgb->clk_parent);
+ goto err_put_node;
}
err = clk_set_parent(rgb->clk, rgb->clk_parent);
if (err < 0) {
dev_err(dc->dev, "failed to set parent clock: %d\n", err);
- return err;
+ goto err_put_node;
}
rgb->pll_d_out0 = clk_get_sys(NULL, "pll_d_out0");
if (IS_ERR(rgb->pll_d_out0)) {
err = PTR_ERR(rgb->pll_d_out0);
dev_err(dc->dev, "failed to get pll_d_out0: %d\n", err);
- return err;
+ goto err_put_node;
}
if (dc->soc->has_pll_d2_out0) {
@@ -241,13 +248,17 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc)
if (IS_ERR(rgb->pll_d2_out0)) {
err = PTR_ERR(rgb->pll_d2_out0);
dev_err(dc->dev, "failed to get pll_d2_out0: %d\n",
err);
- return err;
+ goto err_put_node;
}
}
dc->rgb = &rgb->output;
return 0;
+
+err_put_node:
+ of_node_put(np);
+ return err;
}
int tegra_dc_rgb_remove(struct tegra_dc *dc)
--
2.25.1
Re: DRM Master ignoring hotplug event during display switching (QT)
Hi Daniel, On Wed, Mar 30, 2022 at 3:27 PM Daniel Vetter wrote: > > On Wed, Mar 30, 2022 at 10:52:54AM +0200, Maxime Ripard wrote: > > On Tue, Mar 29, 2022 at 11:38:32PM +0530, Jagan Teki wrote: > > > Hi all, > > > > > > I have implemented runtime display switching in the MIPI switch design > > > where LVDS and HDMI bridges are selected with the help of runtime > > > GPIO. > > > > > > Initial discussion on the same can be found here, > > > https://www.spinics.net/lists/dri-devel/msg318524.html > > > > > > The implementation has been done by creating each connector at > > > runtime. The default boot will create the LVDS connector and based on > > > the HDMI plug-in the ISR. > > > > > > 1. forcing the LVDS to disconnect > > > 2. call drm_kms_helper_hotplug_event > > > 3. detach the bridge chain > > > 4. attach the new bridge chain (HDMI) > > > 5. call drm_kms_helper_hotplug_event > > > > > > do the reverse when we unplug the HDMI cable. > > > > > > So, the bridge chains are attached and detached based on GPIO > > > Interrupt which is indeed identified based on the physical HDMIA > > > connector. > > > > > > Pipeline for LVDS, > > > mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge > > > > > > Pipeline for HDMI, > > > mxfsb => nwl-dsi => display-switch => adv7511 => display-connector > > > > > > With this, implementation and I can able switch the displays with > > > default DRM (without specific DRM applications) where the LVDS is ON > > > by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI > > > unplug the HDMI OFF/LVDS ON. > > > > > > However, with QT5 I can see the DRM Master ignoring hotplug event by > > > returning 0 on drm_master_internal_acquire in > > > drm_fb_helper_hotplug_event. With this the hotplug returned early so > > > it cannot able to disconnect and connect the new switching connector. > > > > > > Any help? > > > > I'm not sure why you started another discussion with pretty much the > > same content, but you can't rely on userspace handling the hotplug > > event. You'll have to deal with the case where it just doesn't. > > Well I missed the old thread, so I'm replying here. > > You should not handle this at all from a hotplug. > > The way kms works is roughly as follows: > > 1. hw output state changes > 2. driver detects this (either through hpd interrupt or polling) > 3. driver sends out hotplug uevent > > That's it. Nothing else, no bridge rebinding, no link retaining is > required. > > Then either userspace or fbcon emulation reacts to this hotplug event by > doing an atomic modeset, where it hopefully disables the old output and > re-enables the new output. Your atomic_check needs to validate that > everything is all right (i.e. not enabling both at the same time). > > Note that if you change stuff underneath, then that tends to seriously > upset atomic users. Also you should try to continue supporting at least > page flips with the wrong config, compositors otherwise tend to crash. > > This also means that if userspace doesn't handle hotplug events, then you > might end up with a black screen. That's ok. We try to avoid that when > it's practical (e.g. dp sst link retraining), but not when it's too hard > (dp mst hot-replug relies on userspace restoring everything). > > Finally exchanging the bridge chain isn't supported, there's no locking > for that since it's assumed to be invariant over the lifetim of the > drm_device instance. The simplest way to make that happen right now is to > have 2 drm_encoder instances, one with the lvds bridge chain, the other > with the hdmi bridge chain, and select the right encoder/bridge chain > depending upon which output userspace picks. I've created 2 instances of encoders. endpoint 0 for HDMI bridge chain and endpoint 1 for LVDS bridge chain. Each bridge chain uses a respective encoder instance in order to start attaching the bridge like below. 1. find the bridge at endpoint 0 2. drm_bridge_attach(&mxsfb->encoder[0], mxsfb->bridge[0], NULL, 0) and repeat for endpoint 1 The bridge chain established fine for endpoint 0 but returned -EBUSY while the bridge chain attached for endpoint 1. looks like bridge->dev is still being used in endpoint 0 even though we have a separate bridge point from mxsfb. Any thought on how to establish the dual bridge chain here? Thanks, Jagan.
[PATCH 6/6] drm: Remove legacy cursor hotspot code
From: Zack Rusin
Atomic modesetting support mouse cursor offsets via the hotspot
properties that are creates on cursor planes. All drivers which
support hotspot are atomic and the legacy code has been implemented
in terms of the atomic properties as well.
Due to the above the lagacy cursor hotspot code is no longer used or
needed and can be removed.
Signed-off-by: Zack Rusin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 3 ---
include/drm/drm_framebuffer.h | 12
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index bb28d1eaf985..d38b5301b5dd 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1041,9 +1041,6 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc,
return PTR_ERR(fb);
}
- fb->hot_x = req->hot_x;
- fb->hot_y = req->hot_y;
-
if (plane->hotspot_x_property && plane->state)
plane->state->hotspot_x = req->hot_x;
if (plane->hotspot_y_property && plane->state)
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index f67c5b7bcb68..c306ae2e2d47 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -188,18 +188,6 @@ struct drm_framebuffer {
* DRM_MODE_FB_MODIFIERS.
*/
int flags;
- /**
-* @hot_x: X coordinate of the cursor hotspot. Used by the legacy cursor
-* IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
-* universal plane.
-*/
- int hot_x;
- /**
-* @hot_y: Y coordinate of the cursor hotspot. Used by the legacy cursor
-* IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
-* universal plane.
-*/
- int hot_y;
/**
* @filp_head: Placed on &drm_file.fbs, protected by &drm_file.fbs_lock.
*/
--
2.34.1
[PATCH 4/6] drm/vboxvideo: Create mouse hotspot properties on cursor planes
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Drivers need to create those properties on cursor planes
which require the mouse hotspot coordinates.
Add the code creating hotspot properties and port away from old legacy
hotspot API. The legacy hotspot paths have an implementation that works
with new atomic properties so there's no reason to keep them and it
makes sense to unify both paths.
Signed-off-by: Zack Rusin
Cc: Hans de Goede
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index 4017b0a621fc..4c0a01a18f5a 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -427,8 +427,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
VBOX_MOUSE_POINTER_ALPHA;
hgsmi_update_pointer_shape(vbox->guest_pool, flags,
- min_t(u32, max(fb->hot_x, 0), width),
- min_t(u32, max(fb->hot_y, 0), height),
+ min_t(u32, max(new_state->hotspot_x, 0),
width),
+ min_t(u32, max(new_state->hotspot_y, 0),
height),
width, height, vbox->cursor_data, data_size);
mutex_unlock(&vbox->hw_mutex);
@@ -575,6 +575,7 @@ static struct vbox_crtc *vbox_crtc_init(struct drm_device
*dev, unsigned int i)
ret = PTR_ERR(cursor);
goto clean_primary;
}
+ drm_plane_create_hotspot_properties(cursor);
} else {
DRM_WARN("VirtualBox host is too old, no cursor support\n");
}
--
2.34.1
[PATCH 5/6] drm/virtio: Create mouse hotspot properties on cursor planes
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Drivers need to create those properties on cursor planes
which require the mouse hotspot coordinates.
Add the code creating hotspot properties and port away from old legacy
hotspot API. The legacy hotspot paths have an implementation that works
with new atomic properties so there's no reason to keep them and it
makes sense to unify both paths.
Signed-off-by: Zack Rusin
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel Vetter
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
drivers/gpu/drm/virtio/virtgpu_plane.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f73352e7b832..848ac2314399 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -288,6 +288,7 @@ static int vgdev_output_init(struct virtio_gpu_device
*vgdev, int index)
drm_connector_attach_encoder(connector, encoder);
drm_connector_register(connector);
+ drm_plane_create_hotspot_properties(cursor);
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 6d3cc9e238a4..21c8adf51c6c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -331,16 +331,16 @@ static void virtio_gpu_cursor_plane_update(struct
drm_plane *plane,
DRM_DEBUG("update, handle %d, pos +%d+%d, hot %d,%d\n", handle,
plane->state->crtc_x,
plane->state->crtc_y,
- plane->state->fb ? plane->state->fb->hot_x : 0,
- plane->state->fb ? plane->state->fb->hot_y : 0);
+ plane->state->hotspot_x,
+ plane->state->hotspot_y);
output->cursor.hdr.type =
cpu_to_le32(VIRTIO_GPU_CMD_UPDATE_CURSOR);
output->cursor.resource_id = cpu_to_le32(handle);
if (plane->state->fb) {
output->cursor.hot_x =
- cpu_to_le32(plane->state->fb->hot_x);
+ cpu_to_le32(plane->state->hotspot_x);
output->cursor.hot_y =
- cpu_to_le32(plane->state->fb->hot_y);
+ cpu_to_le32(plane->state->hotspot_y);
} else {
output->cursor.hot_x = cpu_to_le32(0);
output->cursor.hot_y = cpu_to_le32(0);
--
2.34.1
[PATCH 3/6] drm/qxl: Create mouse hotspot properties on cursor planes
From: Zack Rusin Atomic modesetting got support for mouse hotspots via the hotspot properties. Drivers need to create those properties on cursor planes which require the mouse hotspot coordinates. Add the code creating hotspot properties and port away from old legacy hotspot API. The legacy hotspot paths have an implementation that works with new atomic properties so there's no reason to keep them and it makes sense to unify both paths. Signed-off-by: Zack Rusin Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org --- drivers/gpu/drm/qxl/qxl_display.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 9a64fa4c7530..4b578f9960cd 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -508,8 +508,8 @@ static int qxl_primary_apply_cursor(struct qxl_device *qdev, cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release); cmd->type = QXL_CURSOR_SET; - cmd->u.set.position.x = plane_state->crtc_x + fb->hot_x; - cmd->u.set.position.y = plane_state->crtc_y + fb->hot_y; + cmd->u.set.position.x = plane_state->crtc_x + plane_state->hotspot_x; + cmd->u.set.position.y = plane_state->crtc_y + plane_state->hotspot_y; cmd->u.set.shape = qxl_bo_physical_address(qdev, qcrtc->cursor_bo, 0); @@ -552,8 +552,8 @@ static int qxl_primary_move_cursor(struct qxl_device *qdev, cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release); cmd->type = QXL_CURSOR_MOVE; - cmd->u.position.x = plane_state->crtc_x + fb->hot_x; - cmd->u.position.y = plane_state->crtc_y + fb->hot_y; + cmd->u.position.x = plane_state->crtc_x + plane_state->hotspot_x; + cmd->u.position.y = plane_state->crtc_y + plane_state->hotspot_y; qxl_release_unmap(qdev, release, &cmd->release_info); qxl_release_fence_buffer_objects(release); @@ -849,8 +849,8 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane, struct qxl_bo *old_cursor_bo = qcrtc->cursor_bo; qcrtc->cursor_bo = qxl_create_cursor(qdev, user_bo, -new_state->fb->hot_x, -new_state->fb->hot_y); +new_state->hotspot_x, +new_state->hotspot_y); qxl_free_cursor(old_cursor_bo); } @@ -1002,6 +1002,7 @@ static int qdev_crtc_init(struct drm_device *dev, int crtc_id) qxl_crtc->index = crtc_id; drm_crtc_helper_add(&qxl_crtc->base, &qxl_crtc_helper_funcs); + drm_plane_create_hotspot_properties(cursor); return 0; clean_cursor: -- 2.34.1
[PATCH 2/6] drm/vmwgfx: Create mouse hotspot properties on cursor planes
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Drivers need to create those properties on cursor planes
which require the mouse hotspot coordinates.
Add the code creating hotspot properties and port away from old legacy
hotspot API. The legacy hotspot paths have an implementation that works
with new atomic properties so there's no reason to keep them and it
makes sense to unify both paths.
Signed-off-by: Zack Rusin
Cc: Martin Krastev
Cc: Maaz Mombasawala
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 ++
4 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 693028c31b6b..a4cd312fee46 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -652,13 +652,8 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
struct vmw_plane_state *vps = vmw_plane_state_to_vps(new_state);
s32 hotspot_x, hotspot_y;
- hotspot_x = du->hotspot_x;
- hotspot_y = du->hotspot_y;
-
- if (new_state->fb) {
- hotspot_x += new_state->fb->hot_x;
- hotspot_y += new_state->fb->hot_y;
- }
+ hotspot_x = du->hotspot_x + new_state->hotspot_x;
+ hotspot_y = du->hotspot_y + new_state->hotspot_y;
du->cursor_surface = vps->surf;
du->cursor_bo = vps->bo;
@@ -2270,8 +2265,6 @@ int vmw_du_crtc_gamma_set(struct drm_crtc *crtc,
int i;
for (i = 0; i < size; i++) {
- DRM_DEBUG("%d r/g/b = 0x%04x / 0x%04x / 0x%04x\n", i,
- r[i], g[i], b[i]);
vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 0, r[i] >> 8);
vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 1, g[i] >> 8);
vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 2, b[i] >> 8);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index e4347faccee0..43e89c6755b2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -474,6 +474,8 @@ static int vmw_ldu_init(struct vmw_private *dev_priv,
unsigned unit)
(&connector->base,
dev_priv->implicit_placement_property,
1);
+ if (vmw_cmd_supported(dev_priv))
+ drm_plane_create_hotspot_properties(&cursor->base);
return 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index c89ad3a2d141..8d46b0cbe640 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -932,6 +932,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv,
unsigned unit)
dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(&connector->base,
dev->mode_config.suggested_y_property, 0);
+ drm_plane_create_hotspot_properties(&cursor->base);
return 0;
err_free_unregister:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index eb014b97d156..d940b9a525e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1822,6 +1822,8 @@ static int vmw_stdu_init(struct vmw_private *dev_priv,
unsigned unit)
dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(&connector->base,
dev->mode_config.suggested_y_property, 0);
+ drm_plane_create_hotspot_properties(&cursor->base);
+
return 0;
err_free_unregister:
--
2.34.1
[PATCH 1/6] drm/atomic: Add support for mouse hotspots
From: Zack Rusin
Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but the functionality was not implemented in the new atomic
paths.
Due to the lack of hotspots in the atomic paths userspace compositors
completely disable atomic modesetting for drivers that require it (i.e.
all paravirtualized drivers).
This change adds hotspot properties to the atomic codepaths throughtout
the DRM core and will allow enabling atomic modesetting for virtualized
drivers in the userspace.
Signed-off-by: Zack Rusin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_state_helper.c | 14
drivers/gpu/drm/drm_atomic_uapi.c | 20 +++
drivers/gpu/drm/drm_plane.c | 43 +++
include/drm/drm_plane.h | 15
4 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3b6d3bdbd099..bc8735998099 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -273,6 +273,20 @@ void __drm_atomic_helper_plane_state_reset(struct
drm_plane_state *plane_state,
plane_state->normalized_zpos = val;
}
}
+
+ if (plane->hotspot_x_property) {
+ if (!drm_object_property_get_default_value(&plane->base,
+
plane->hotspot_x_property,
+ &val))
+ plane_state->hotspot_x = val;
+ }
+
+ if (plane->hotspot_y_property) {
+ if (!drm_object_property_get_default_value(&plane->base,
+
plane->hotspot_y_property,
+ &val))
+ plane_state->hotspot_y = val;
+ }
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 434f3d4cb8a2..76a5d5221442 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -574,6 +574,22 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
+ } else if (property == plane->hotspot_x_property) {
+ if (plane->type != DRM_PLANE_TYPE_CURSOR) {
+ drm_dbg_atomic(plane->dev,
+ "[PLANE:%d:%s] is not a cursor plane:
0x%llx\n",
+ plane->base.id, plane->name, val);
+ return -EINVAL;
+ }
+ state->hotspot_x = val;
+ } else if (property == plane->hotspot_y_property) {
+ if (plane->type != DRM_PLANE_TYPE_CURSOR) {
+ drm_dbg_atomic(plane->dev,
+ "[PLANE:%d:%s] is not a cursor plane:
0x%llx\n",
+ plane->base.id, plane->name, val);
+ return -EINVAL;
+ }
+ state->hotspot_y = val;
} else {
drm_dbg_atomic(plane->dev,
"[PLANE:%d:%s] unknown property [PROP:%d:%s]]\n",
@@ -634,6 +650,10 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->scaling_filter;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
+ } else if (property == plane->hotspot_x_property) {
+ *val = state->hotspot_x;
+ } else if (property == plane->hotspot_y_property) {
+ *val = state->hotspot_y;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 726f2f163c26..bb28d1eaf985 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1043,6 +1043,11 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc,
fb->hot_x = req->hot_x;
fb->hot_y = req->hot_y;
+
+ if (plane->hotspot_x_property && plane->state)
+ plane->state->hotspot_x = req->hot_x;
+ if (plane->hotspot_y_property && plane->state)
+ plane->state->hotspot_y = req->hot_y;
} else {
fb = NULL;
}
@@ -1571,3 +1576,41 @@ int drm_plane_create_scaling_filter_property(struct
drm_plane *plane,
return 0;
}
EXPORT_SYMBO
[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
From: Zack Rusin Support for setting mouse cursor hotspot never made the transition from the legacy kms to atomic. This left virtualized drivers, all which are atomic, in a weird spot because all userspace compositors put those drivers on deny-lists for atomic kms due to the fact that mouse clicks were incorrectly routed, e.g: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-kms-impl-device-atomic.c#L1188 https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/drm/drm_gpu.cpp#L156 So even though all the virtualized drm drivers are atomic, none of them could be used with atomic kms because of the missing mouse cursor hotspot support. The first change adds support for mouse cursor hotspots to drm core atomic via the HOTSPOT_X and HOTSPOT_Y properties and implements it in the legacy paths. The next few changes add support for the mouse hotspot properties to all the drivers which required hotspots. And the final change removes the legacy hotspot code because it's unused. A sample mutter patch which makes gnome-shell work with all the virtualized drivers with atomic kms is here: https://gitlab.gnome.org/zackr/mutter/-/commit/2aa61b50507a24f34d514fa65b7bcf07e910f459 I'll have a similar patch for kwin. This gets virtualized drivers working correctly with atomic kms, but the hotspot codepaths aren't fool proof, e.g.: - there's no way of currently validating that the drm drivers actually did anything with the information and no way of testing it via igt, - all userspace code needs to hardcore a list of drivers which require hotspots because there's no way to query from drm "does this driver require hotspot" Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Gurchetan Singh Cc: Chia-I Wu Cc: Hans de Goede Zack Rusin (6): drm/atomic: Add support for mouse hotspots drm/vmwgfx: Create mouse hotspot properties on cursor planes drm/qxl: Create mouse hotspot properties on cursor planes drm/vboxvideo: Create mouse hotspot properties on cursor planes drm/virtio: Create mouse hotspot properties on cursor planes drm: Remove legacy cursor hotspot code drivers/gpu/drm/drm_atomic_state_helper.c | 14 drivers/gpu/drm/drm_atomic_uapi.c | 20 +++ drivers/gpu/drm/drm_plane.c | 44 +-- drivers/gpu/drm/qxl/qxl_display.c | 13 +++ drivers/gpu/drm/vboxvideo/vbox_mode.c | 5 +-- drivers/gpu/drm/virtio/virtgpu_display.c | 1 + drivers/gpu/drm/virtio/virtgpu_plane.c| 8 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 2 ++ drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 ++ include/drm/drm_framebuffer.h | 12 --- include/drm/drm_plane.h | 15 13 files changed, 113 insertions(+), 35 deletions(-) -- 2.34.1
Re: [PATCH 1/2] dt-bindings: backlight: rt4831: Add the new property for ocp level selection
Krzysztof Kozlowski 於 2022年6月2日 週四 下午9:58寫道： > > On 02/06/2022 15:56, Rob Herring wrote: > > On Thu, May 26, 2022 at 12:32:12PM +0200, Krzysztof Kozlowski wrote: > >> On 26/05/2022 10:13, ChiYuan Huang wrote: > >>> Krzysztof Kozlowski 於 2022年5月26日 週四 > >>> 下午4:06寫道： > > On 26/05/2022 05:16, cy_huang wrote: > > From: ChiYuan Huang > > > > Add the new property for ocp level selection. > > > > Signed-off-by: ChiYuan Huang > > --- > > .../bindings/leds/backlight/richtek,rt4831-backlight.yaml | 8 > > > > include/dt-bindings/leds/rt4831-backlight.h | 5 > > + > > 2 files changed, 13 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml > > > > b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml > > index e0ac686..c1c59de 100644 > > --- > > a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml > > +++ > > b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml > > @@ -47,6 +47,14 @@ properties: > > minimum: 0 > > maximum: 3 > > > > + richtek,bled-ocp-sel: > > Skip "sel" as it is a shortcut of selection. Name instead: > "richtek,backlight-ocp" > > >>> OK, if so, do I need to rename all properties from 'bled' to 'backlight' ? > >>> If only this property is naming as 'backlight'. it may conflict with > >>> the others like as "richtek,bled-ovp-sel". > >> > >> Ah, no, no need. > >> > > > +description: | > > + Backlight OCP level selection, currently support > > 0.9A/1.2A/1.5A/1.8A > > Could you explain here what is OCP (unfold the acronym)? > >>> Yes. And the full name is 'over current protection'. > >> > >> Thanks and this leads to second thing - you encode register value > >> instead of logical value. This must be a logical value in mA, so > >> "richtek,bled-ocp-microamp". > > > > We already have common properties for setting current of LEDs. We should > > use that here I think. > > It might not be exactly the same. We have "led-max-microamp" which is > the maximum allowed current. I guess over-current protection level is > slightly higher (e.g. led-max-microamp + 1). IOW, led-max-microamp is > something which still can be set and used by system/hardware. OCP should > not. > Yap, you're right. >From the modern backlight IC design, it uses the boost converter architecture. This OCP level is to limit the inductor current when the internal MOS switch turn on. Details can refer to the below wiki link https://en.wikipedia.org/wiki/Boost_converter And based on it, OVP is used to limit the inductor output voltage. Each channel maximum current is based on the IC affordable limit. It is more like as what you said 'led-max-microamp'. So boost voltage level may depend on the LED VF. The different series of LED may cause different boost voltage. RT4831's OVP/OCP is not just the protection, more like as the limit. > > Best regards, > Krzysztof
