Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Wed, 05 Jun 2024, Chris Bainbridge wrote:
> On Tue, Jun 04, 2024 at 10:02:29AM +0800, kernel test robot wrote:
>> Hi Mario,
>>
>> kernel test robot noticed the following build errors:
>>
>> [auto build test ERROR on drm-misc/drm-misc-next]
>> [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
>> drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
>> linus/master v6.10-rc2 next-20240603]
>> [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#_base_tree_information]
>>
>> url:
>> https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-client-Detect-when-ACPI-lid-is-closed-during-initialization/20240529-050440
>> base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
>> patch link:
>> https://lore.kernel.org/r/20240528210319.1242-1-mario.limonciello%40amd.com
>> patch subject: [PATCH v2] drm/client: Detect when ACPI lid is closed during
>> initialization
>> config: i386-randconfig-053-20240604
>> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/config)
>> compiler: gcc-9 (Ubuntu 9.5.0-4ubuntu2) 9.5.0
>> reproduce (this is a W=1 build):
>> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version
>> of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot
>> | Closes:
>> https://lore.kernel.org/oe-kbuild-all/202406040928.eu1griwv-...@intel.com/
>>
>> All errors (new ones prefixed by >>):
>>
>>ld: drivers/gpu/drm/drm_client_modeset.o: in function
>> `drm_client_match_edp_lid':
>> >> drivers/gpu/drm/drm_client_modeset.c:281:(.text+0x221b): undefined
>> >> reference to `acpi_lid_open'
>>
>>
>> vim +281 drivers/gpu/drm/drm_client_modeset.c
>>
>>260
>>261 static void drm_client_match_edp_lid(struct drm_device *dev,
>>262struct drm_connector
>> **connectors,
>>263unsigned int
>> connector_count,
>>264bool *enabled)
>>265 {
>>266 int i;
>>267
>>268 for (i = 0; i < connector_count; i++) {
>>269 struct drm_connector *connector = connectors[i];
>>270
>>271 switch (connector->connector_type) {
>>272 case DRM_MODE_CONNECTOR_LVDS:
>>273 case DRM_MODE_CONNECTOR_eDP:
>>274 if (!enabled[i])
>>275 continue;
>>276 break;
>>277 default:
>>278 continue;
>>279 }
>>280
>> > 281 if (!acpi_lid_open()) {
>>282 drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid
>> is closed, disabling\n",
>>283 connector->base.id,
>> connector->name);
>>284 enabled[i] = false;
>>285 }
>>286 }
>>287 }
>>288
>>
>> --
>> 0-DAY CI Kernel Test Service
>> https://github.com/intel/lkp-tests/wiki
>
> The failed config has CONFIG_ACPI_BUTTON=m. The build failure can be
> fixed with:
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index b76438c31761..0271e66f44f8 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -271,11 +271,13 @@ static void drm_client_match_edp_lid(struct drm_device
> *dev,
> if (connector->connector_type != DRM_MODE_CONNECTOR_eDP ||
> !enabled[i])
> continue;
>
> +#if defined(CONFIG_ACPI_BUTTON)
> if (!acpi_lid_open()) {
> drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> disabling\n",
> connector->base.id, connector->name);
> enabled[i] = false;
> }
> +#endif
> }
> }
No. This is because
CONFIG_DRM=y
CONFIG_ACPI_BUTTON=m
The pedantically correct fix is probably having DRM
depends on ACPI_BUTTON || ACPI_BUTTON=n
but seeing how i915 and xe just
select ACPI_BUTTON if ACPI
and nouveau basically uses acpi_lid_open() it if it's reachable with no
regard to kconfig, it's anyone's guess what will work.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH 1/3] dt-bindings: Add vendor prefix for PrimeView
On 06/06/2024 09:28, Primoz Fiser wrote: > The Prime View International (PVI) is a LCD panel manufacturer. > Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. For bindings, the preferred subjects are explained here: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters dt-bindings: vendor-prefixes: > Signed-off-by: Primoz Fiser > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index fbf47f0bacf1..2bdfeaa3cc8f 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1154,6 +1154,8 @@ patternProperties: > description: Poslab Technology Co., Ltd. >"^pov,.*": > description: Point of View International B.V. > + "^primeview,.*": > +description: Prime View International (PVI) Keep things sorted. Best regards, Krzysztof
Re: [PATCH 2/3] dt-bindings: display: simple: Add PrimeView PM070WL4 panel
On 06/06/2024 09:28, Primoz Fiser wrote: > Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string. > > Signed-off-by: Primoz Fiser > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 5067f5c0a272..671da4991a5d 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -276,6 +276,8 @@ properties: >- osddisplays,osd070t1718-19ts > # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel >- osddisplays,osd101t2045-53ts > +# PrimeView PM070WL4 7.0" 800x480 TFT LCD panel > + - primeview,pm070wl4 Keep things sorted. Best regards, Krzysztof
[PATCH] arm/komeda: Compile DEFINE_SHOW_ATTRIBUTE() only when CONFIG_DEBUG_FS is enabled
We do not call komeda_debugfs_init() and the debugfs core function
declaration if CONFIG_DEBUG_FS is not defined, but we should not
compile it either because the debugfs core function declaration is
not included.
Reported-by: k2ci
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 14ee79becacb..7ada8e6f407c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -21,6 +21,7 @@
#include "komeda_dev.h"
+#ifdef CONFIG_DEBUG_FS
static int komeda_register_show(struct seq_file *sf, void *x)
{
struct komeda_dev *mdev = sf->private;
@@ -43,7 +44,6 @@ static int komeda_register_show(struct seq_file *sf, void *x)
DEFINE_SHOW_ATTRIBUTE(komeda_register);
-#ifdef CONFIG_DEBUG_FS
static void komeda_debugfs_init(struct komeda_dev *mdev)
{
if (!debugfs_initialized())
--
2.25.1
Re: [PATCH v7 07/13] PCI: Move dev-enabled status bit to struct pci_dev
On Wed, 2024-06-05 at 16:11 -0500, Bjorn Helgaas wrote:
> On Wed, Jun 05, 2024 at 10:15:59AM +0200, Philipp Stanner wrote:
> > The bit describing whether the PCI device is currently enabled is
> > stored
> > in struct pci_devres. Besides this struct being subject of a
> > cleanup
> > process, struct pci_device is in general the right place to store
> > this
> > information, since it is not devres-specific.
> >
> > Move the 'enabled' boolean bit to struct pci_dev.
>
> I think this (and the similar 'pinned' patch) appeared in v6.
Yes. This patch and its brothers serve to remove members from
struct pci_devres step by step, so it can ultimately be removed, so
that we won't have a generic devres struct anymore, but actual
resource-specific structs.
>
> It sounds plausible to have this in struct pci_dev, but it's
> confusing
> to have both:
>
> pci_dev.enabled
> pci_dev.enable_cnt, used by pci_is_enabled()
>
> I haven't looked hard enough to see whether both are required. If
> they are, I think we should rename "enabled" to something descriptive
> enough to make it obviously different from "enable_cnt".
I took a look at it and I think we can actually drop "enabled" and use
"enable_cnt" for everything. That would even simplify things more, I'd
say.
Let me provide that in v8.
P.
>
> > Signed-off-by: Philipp Stanner
> > ---
> > drivers/pci/devres.c | 11 ---
> > drivers/pci/pci.c | 17 ++---
> > drivers/pci/pci.h | 1 -
> > include/linux/pci.h | 1 +
> > 4 files changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/pci/devres.c b/drivers/pci/devres.c
> > index 572a4e193879..ea590caf8995 100644
> > --- a/drivers/pci/devres.c
> > +++ b/drivers/pci/devres.c
> > @@ -398,7 +398,7 @@ static void pcim_release(struct device *gendev,
> > void *res)
> > if (this->restore_intx)
> > pci_intx(dev, this->orig_intx);
> >
> > - if (this->enabled && !this->pinned)
> > + if (!this->pinned)
> > pci_disable_device(dev);
> > }
> >
> > @@ -441,14 +441,11 @@ int pcim_enable_device(struct pci_dev *pdev)
> > dr = get_pci_dr(pdev);
> > if (unlikely(!dr))
> > return -ENOMEM;
> > - if (dr->enabled)
> > - return 0;
> >
> > rc = pci_enable_device(pdev);
> > - if (!rc) {
> > + if (!rc)
> > pdev->is_managed = 1;
> > - dr->enabled = 1;
> > - }
> > +
> > return rc;
> > }
> > EXPORT_SYMBOL(pcim_enable_device);
> > @@ -466,7 +463,7 @@ void pcim_pin_device(struct pci_dev *pdev)
> > struct pci_devres *dr;
> >
> > dr = find_pci_dr(pdev);
> > - WARN_ON(!dr || !dr->enabled);
> > + WARN_ON(!dr || !pdev->enabled);
> > if (dr)
> > dr->pinned = 1;
> > }
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 8dd711b9a291..04accdfab7ce 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -2011,6 +2011,9 @@ static int do_pci_enable_device(struct
> > pci_dev *dev, int bars)
> > u16 cmd;
> > u8 pin;
> >
> > + if (dev->enabled)
> > + return 0;
> > +
> > err = pci_set_power_state(dev, PCI_D0);
> > if (err < 0 && err != -EIO)
> > return err;
> > @@ -2025,7 +2028,7 @@ static int do_pci_enable_device(struct
> > pci_dev *dev, int bars)
> > pci_fixup_device(pci_fixup_enable, dev);
> >
> > if (dev->msi_enabled || dev->msix_enabled)
> > - return 0;
> > + goto success_out;
> >
> > pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
> > if (pin) {
> > @@ -2035,6 +2038,8 @@ static int do_pci_enable_device(struct
> > pci_dev *dev, int bars)
> > cmd &
> > ~PCI_COMMAND_INTX_DISABLE);
> > }
> >
> > +success_out:
> > + dev->enabled = true;
> > return 0;
> > }
> >
> > @@ -2193,6 +2198,9 @@ static void do_pci_disable_device(struct
> > pci_dev *dev)
> > {
> > u16 pci_command;
> >
> > + if (!dev->enabled)
> > + return;
> > +
> > pci_read_config_word(dev, PCI_COMMAND, &pci_command);
> > if (pci_command & PCI_COMMAND_MASTER) {
> > pci_command &= ~PCI_COMMAND_MASTER;
> > @@ -2200,6 +2208,7 @@ static void do_pci_disable_device(struct
> > pci_dev *dev)
> > }
> >
> > pcibios_disable_device(dev);
> > + dev->enabled = false;
> > }
> >
> > /**
> > @@ -2227,12 +2236,6 @@ void pci_disable_enabled_device(struct
> > pci_dev *dev)
> > */
> > void pci_disable_device(struct pci_dev *dev)
> > {
> > - struct pci_devres *dr;
> > -
> > - dr = find_pci_dr(dev);
> > - if (dr)
> > - dr->enabled = 0;
> > -
> > dev_WARN_ONCE(&dev->dev, atomic_read(&dev->enable_cnt) <=
> > 0,
> > "disabling already-disabled device");
> >
> > diff
[PATCH 1/3] dt-bindings: Add vendor prefix for PrimeView
The Prime View International (PVI) is a LCD panel manufacturer. Signed-off-by: Primoz Fiser --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index fbf47f0bacf1..2bdfeaa3cc8f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1154,6 +1154,8 @@ patternProperties: description: Poslab Technology Co., Ltd. "^pov,.*": description: Point of View International B.V. + "^primeview,.*": +description: Prime View International (PVI) "^powertip,.*": description: Powertip Tech. Corp. "^powervr,.*": -- 2.25.1
[PATCH 3/3] drm/panel: simple: Add PrimeView PM070WL4 support
Add support for PrimeView PM070WL4 7.0" (800x480) TFT-LCD panel.
Datasheet can be found at [1].
[1] https://www.beyondinfinite.com/lcd/Library/Pvi/PM070WL4-V1.0.pdf
Signed-off-by: Primoz Fiser
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..ea1a7ba3a5b6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3513,6 +3513,32 @@ static const struct panel_desc pda_91_00156_a0 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode primeview_pm070wl4_mode = {
+ .clock = 32000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 42,
+ .hsync_end = 800 + 42 + 128,
+ .htotal = 800 + 42 + 128 + 86,
+ .vdisplay = 480,
+ .vsync_start = 480 + 10,
+ .vsync_end = 480 + 10 + 2,
+ .vtotal = 480 + 10 + 2 + 33,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc primeview_pm070wl4 = {
+ .modes = &primeview_pm070wl4_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode powertip_ph128800t006_zhc01_mode = {
.clock = 66500,
.hdisplay = 1280,
@@ -4719,6 +4745,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "pda,91-00156-a0",
.data = &pda_91_00156_a0,
+ }, {
+ .compatible = "primeview,pm070wl4",
+ .data = &primeview_pm070wl4,
}, {
.compatible = "powertip,ph128800t006-zhc01",
.data = &powertip_ph128800t006_zhc01,
--
2.25.1
[PATCH 2/3] dt-bindings: display: simple: Add PrimeView PM070WL4 panel
Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string. Signed-off-by: Primoz Fiser --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 5067f5c0a272..671da4991a5d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -276,6 +276,8 @@ properties: - osddisplays,osd070t1718-19ts # One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel - osddisplays,osd101t2045-53ts +# PrimeView PM070WL4 7.0" 800x480 TFT LCD panel + - primeview,pm070wl4 # POWERTIP PH128800T006-ZHC01 10.1" WXGA TFT LCD panel - powertip,ph128800t006-zhc01 # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel -- 2.25.1
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add PrimeView
The Prime View International (PVI) is a LCD panel manufacturer. Signed-off-by: Primoz Fiser --- Changes in v2: - fix subject line - sort alphabetically Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index fbf47f0bacf1..69cedce51628 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1160,6 +1160,8 @@ patternProperties: description: PowerVR (deprecated, use img) "^powkiddy,.*": description: Powkiddy + "^primeview,.*": +description: Prime View International (PVI) "^primux,.*": description: Primux Trading, S.L. "^probox2,.*": -- 2.25.1
[PATCH v2 2/3] dt-bindings: display: simple: Add PrimeView PM070WL4 panel
Add PrimeView PM070WL4 7.0" 800x480 TFT LCD panel compatible string. Signed-off-by: Primoz Fiser --- Changes in v2: - sort alphabetically .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 5067f5c0a272..4dedcfe8b5a3 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -280,6 +280,8 @@ properties: - powertip,ph128800t006-zhc01 # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel - powertip,ph800480t013-idf02 +# PrimeView PM070WL4 7.0" 800x480 TFT LCD panel + - primeview,pm070wl4 # QiaoDian XianShi Corporation 4"3 TFT LCD panel - qiaodian,qd43003c0-40 # Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel -- 2.25.1
[PATCH v2 3/3] drm/panel: simple: Add PrimeView PM070WL4 support
Add support for PrimeView PM070WL4 7.0" (800x480) TFT-LCD panel.
Datasheet can be found at [1].
[1] https://www.beyondinfinite.com/lcd/Library/Pvi/PM070WL4-V1.0.pdf
Signed-off-by: Primoz Fiser
---
Changes in v2:
- sort alphabetically
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..80cca841db15 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3567,6 +3567,32 @@ static const struct panel_desc
powertip_ph800480t013_idf02 = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode primeview_pm070wl4_mode = {
+ .clock = 32000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 42,
+ .hsync_end = 800 + 42 + 128,
+ .htotal = 800 + 42 + 128 + 86,
+ .vdisplay = 480,
+ .vsync_start = 480 + 10,
+ .vsync_end = 480 + 10 + 2,
+ .vtotal = 480 + 10 + 2 + 33,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc primeview_pm070wl4 = {
+ .modes = &primeview_pm070wl4_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -4725,6 +4751,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "powertip,ph800480t013-idf02",
.data = &powertip_ph800480t013_idf02,
+ }, {
+ .compatible = "primeview,pm070wl4",
+ .data = &primeview_pm070wl4,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
--
2.25.1
Re: [PATCH] arm/komeda: Compile DEFINE_SHOW_ATTRIBUTE() only when CONFIG_DEBUG_FS is enabled
On Thu, 06 Jun 2024, pengfuyuan wrote:
> We do not call komeda_debugfs_init() and the debugfs core function
> declaration if CONFIG_DEBUG_FS is not defined, but we should not
> compile it either because the debugfs core function declaration is
> not included.
>
> Reported-by: k2ci
> Signed-off-by: pengfuyuan
An interesting alternative might actually be to remove *all* the
CONFIG_DEBUG_FS conditional compilation from the file. Since the debugfs
functions have no-op stubs for CONFIG_DEBUG_FS=n, the compiler will
optimize the rest away, because they're no longer referenced. (For the
same reason, I don't think this patch has an impact for code size.)
The upside for removing conditional compilation is that you'll actually
do build testing for both CONFIG_DEBUG_FS config values. Assuming most
developers have it enabled, there's not a lot of testing going on for
CONFIG_DEBUG_FS=n, and you might introduce build failures with the
conditional compilation.
Of course, up to Liviu to decide.
BR,
Jani.
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 14ee79becacb..7ada8e6f407c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -21,6 +21,7 @@
>
> #include "komeda_dev.h"
>
> +#ifdef CONFIG_DEBUG_FS
> static int komeda_register_show(struct seq_file *sf, void *x)
> {
> struct komeda_dev *mdev = sf->private;
> @@ -43,7 +44,6 @@ static int komeda_register_show(struct seq_file *sf, void
> *x)
>
> DEFINE_SHOW_ATTRIBUTE(komeda_register);
>
> -#ifdef CONFIG_DEBUG_FS
> static void komeda_debugfs_init(struct komeda_dev *mdev)
> {
> if (!debugfs_initialized())
--
Jani Nikula, Intel
Re: [PATCH v2] [drm/meson] meson_plane: Add error handling v2(re-aligned)
On 29/11/2023 12:34, Haoran Liu wrote:
This patch adds robust error handling to the meson_plane_create
function in drivers/gpu/drm/meson/meson_plane.c. The function
previously lacked proper handling for potential failure scenarios
of the drm_universal_plane_init call.
Signed-off-by: Haoran Liu
---
drivers/gpu/drm/meson/meson_plane.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 815dfe30492b..b43ac61201f3 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -534,6 +534,7 @@ int meson_plane_create(struct meson_drm *priv)
struct meson_plane *meson_plane;
struct drm_plane *plane;
const uint64_t *format_modifiers = format_modifiers_default;
+ int ret;
meson_plane = devm_kzalloc(priv->drm->dev, sizeof(*meson_plane),
GFP_KERNEL);
@@ -548,12 +549,16 @@ int meson_plane_create(struct meson_drm *priv)
else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
format_modifiers = format_modifiers_afbc_g12a;
- drm_universal_plane_init(priv->drm, plane, 0xFF,
-&meson_plane_funcs,
-supported_drm_formats,
-ARRAY_SIZE(supported_drm_formats),
-format_modifiers,
-DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane");
+ ret = drm_universal_plane_init(priv->drm, plane, 0xFF,
+ &meson_plane_funcs,
+ supported_drm_formats,
+ ARRAY_SIZE(supported_drm_formats),
+ format_modifiers,
+ DRM_PLANE_TYPE_PRIMARY,
"meson_primary_plane");
+ if (ret) {
+ devm_kfree(priv->drm->dev, meson_plane);
+ return ret;
+ }
drm_plane_helper_add(plane, &meson_plane_helper_funcs);
Reviewed-by: Neil Armstrong
[PATCH] drm/omap: dss: Support all VOUT ports
Allow function dss_dpi_select_source_dra7xx() to set the channel in the
dra7xx DSS_CONTROL register for any VOUT port, not just VOUT1 (port 0).
Signed-off-by: Primoz Fiser
---
drivers/gpu/drm/omapdrm/dss/dss.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 98e164d7..f5a484ef0f48 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -796,7 +796,9 @@ static int dss_dpi_select_source_dra7xx(struct dss_device
*dss, int port,
{
switch (port) {
case 0:
- return dss_dpi_select_source_omap5(dss, port, channel);
+ if (channel != OMAP_DSS_CHANNEL_LCD)
+ return -EINVAL;
+ break;
case 1:
if (channel != OMAP_DSS_CHANNEL_LCD2)
return -EINVAL;
@@ -809,7 +811,7 @@ static int dss_dpi_select_source_dra7xx(struct dss_device
*dss, int port,
return -EINVAL;
}
- return 0;
+ return dss_dpi_select_source_omap5(dss, port, channel);
}
int dss_dpi_select_source(struct dss_device *dss, int port,
--
2.25.1
Re: [PATCH v3 6/7] drm/drm_file: add display of driver's internal memory size
On 06/06/2024 02:49, Adrián Larumbe wrote:
Some drivers must allocate a considerable amount of memory for bookkeeping
structures and GPU's MCU-kernel shared communication regions. These are
often created as a result of the invocation of the driver's ioctl()
interface functions, so it is sensible to consider them as being owned by
the render context associated with an open drm file.
However, at the moment drm_show_memory_stats only traverses the UM-exposed
drm objects for which a handle exists. Private driver objects and memory
regions, though connected to a render context, are unaccounted for in their
fdinfo numbers.
Add a new drm_memory_stats 'internal' memory category.
Because deciding what constitutes an 'internal' object and where to find
these are driver-dependent, calculation of this size must be done through a
driver-provided function pointer, which becomes the third argument of
drm_show_memory_stats. Drivers which have no interest in exposing the size
of internal memory objects can keep passing NULL for unaltered behaviour.
Signed-off-by: Adrián Larumbe
Please Cc people who were previously involved in defining
drm-usage-stats.rst. I added Rob, but I am not sure if I forgot someone
from the top of my head.
Internal as a category sounds potentially useful. One reservation I have
though is itdoes not necessarily fit with the others but is something
semantically different from them.
In i915 I had the similar desire to account for internal objects and
have approached it by similarly tracking them outside the DRM idr but
counting them under the existing respective categories and memory
regions. Ie. internal objects can also be purgeable or not, etc, and can
be backed by either system memory or device local memory.
Advantage is it is more accurate in those aspect and does not require
adding a new category.
Downside of this is that 'internal' is bunched with the explicit
userspace objects so perhaps less accurate in this other aspect.
Regards,
Tvrtko
---
Documentation/gpu/drm-usage-stats.rst | 4
drivers/gpu/drm/drm_file.c | 9 +++--
drivers/gpu/drm/msm/msm_drv.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
include/drm/drm_file.h | 7 ++-
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 6dc299343b48..0da5ebecd232 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -157,6 +157,10 @@ The total size of buffers that are purgeable.
The total size of buffers that are active on one or more engines.
+- drm-internal-: [KiB|MiB]
+
+The total size of GEM objects that aren't exposed to user space.
+
Implementation Details
==
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 638ffaf5..d1c13eed8d34 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -874,9 +874,10 @@ void drm_print_memory_stats(struct drm_printer *p,
enum drm_gem_object_status supported_status,
const char *region)
{
- print_size(p, "total", region, stats->private + stats->shared);
+ print_size(p, "total", region, stats->private + stats->shared +
stats->internal);
print_size(p, "shared", region, stats->shared);
print_size(p, "active", region, stats->active);
+ print_size(p, "internal", region, stats->internal);
if (supported_status & DRM_GEM_OBJECT_RESIDENT)
print_size(p, "resident", region, stats->resident);
@@ -890,11 +891,12 @@ EXPORT_SYMBOL(drm_print_memory_stats);
* drm_show_memory_stats - Helper to collect and show standard fdinfo memory
stats
* @p: the printer to print output to
* @file: the DRM file
+ * @func: driver-specific function pointer to count the size of internal
objects
*
* Helper to iterate over GEM objects with a handle allocated in the specified
* file.
*/
-void drm_show_memory_stats(struct drm_printer *p, struct drm_file *file)
+void drm_show_memory_stats(struct drm_printer *p, struct drm_file *file,
internal_bos func)
{
struct drm_gem_object *obj;
struct drm_memory_stats status = {};
@@ -940,6 +942,9 @@ void drm_show_memory_stats(struct drm_printer *p, struct
drm_file *file)
}
spin_unlock(&file->table_lock);
+ if (func)
+ func(&status, file);
+
drm_print_memory_stats(p, &status, supported_status, "memory");
}
EXPORT_SYMBOL(drm_show_memory_stats);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c33f4e3f822..f97d3cdc4f50 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -880,7 +880,7 @@ static void msm_show_fdinfo(struct drm_printer *p, struct
drm_file *file)
msm_gpu_show_fdinfo(priv->gpu, file->driver_priv, p);
- drm_s
Re: [PATCH v2 3/3] drm/panel: simple: Add PrimeView PM070WL4 support
On 06/06/2024 10:01, Primoz Fiser wrote:
Add support for PrimeView PM070WL4 7.0" (800x480) TFT-LCD panel.
Datasheet can be found at [1].
[1] https://www.beyondinfinite.com/lcd/Library/Pvi/PM070WL4-V1.0.pdf
Signed-off-by: Primoz Fiser
---
Changes in v2:
- sort alphabetically
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..80cca841db15 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3567,6 +3567,32 @@ static const struct panel_desc
powertip_ph800480t013_idf02 = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode primeview_pm070wl4_mode = {
+ .clock = 32000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 42,
+ .hsync_end = 800 + 42 + 128,
+ .htotal = 800 + 42 + 128 + 86,
+ .vdisplay = 480,
+ .vsync_start = 480 + 10,
+ .vsync_end = 480 + 10 + 2,
+ .vtotal = 480 + 10 + 2 + 33,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc primeview_pm070wl4 = {
+ .modes = &primeview_pm070wl4_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -4725,6 +4751,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "powertip,ph800480t013-idf02",
.data = &powertip_ph800480t013_idf02,
+ }, {
+ .compatible = "primeview,pm070wl4",
+ .data = &primeview_pm070wl4,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
Reviewed-by: Neil Armstrong
Re: [PATCH v4 06/13] drm/msm/dpu: split dpu_plane_atomic_check()
On Thu, 6 Jun 2024 at 02:47, Abhinav Kumar wrote:
>
>
>
> On 6/5/2024 4:32 PM, Dmitry Baryshkov wrote:
> > On Thu, 6 Jun 2024 at 02:19, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> >>> Split dpu_plane_atomic_check() function into two pieces:
> >>>
> >>> dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
> >>> without touching the associated pipe,
> >>>
> >>> and
> >>>
> >>> dpu_plane_atomic_check_pipes(), which takes into account used pipes.
> >>>
> >>> Signed-off-by: Dmitry Baryshkov
> >>> ---
> >>>drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 184 ++
> >>>1 file changed, 117 insertions(+), 67 deletions(-)
> >>>
> >>
> >> One thing which seemed odd to me is even dpu_plane_atomic_check_nopipe()
> >> does use pipe_cfg even though its named "nopipe".
> >>
> >> Perhaps were you targetting a split of SW planes vs SSPP atomic_check?
> >>
> >> I tried applying this patch on top of msm-next to more closely review
> >> the split up but it does not apply. So, I will review this patch a
> >> little better after it is re-spun. But will proceed with remaining patches.
> >>
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> >>> index 6360052523b5..187ac2767a2b 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> >>> @@ -788,50 +788,22 @@ static int dpu_plane_atomic_check_pipe(struct
> >>> dpu_plane *pdpu,
> >>>#define MAX_UPSCALE_RATIO 20
> >>>#define MAX_DOWNSCALE_RATIO 4
> >>>
> >>> -static int dpu_plane_atomic_check(struct drm_plane *plane,
> >>> - struct drm_atomic_state *state)
> >>> +static int dpu_plane_atomic_check_nopipe(struct drm_plane *plane,
> >>> + struct drm_plane_state
> >>> *new_plane_state,
> >>> + const struct drm_crtc_state
> >>> *crtc_state)
> >>>{
> >>> - struct drm_plane_state *new_plane_state =
> >>> drm_atomic_get_new_plane_state(state,
> >>> -
> >>> plane);
> >>>int ret = 0, min_scale, max_scale;
> >>>struct dpu_plane *pdpu = to_dpu_plane(plane);
> >>>struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
> >>>u64 max_mdp_clk_rate = kms->perf.max_core_clk_rate;
> >>>struct dpu_plane_state *pstate =
> >>> to_dpu_plane_state(new_plane_state);
> >>> - struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
> >>> - struct dpu_sw_pipe *pipe = &pstate->pipe;
> >>> - struct dpu_sw_pipe *r_pipe = &pstate->r_pipe;
> >>> - const struct drm_crtc_state *crtc_state = NULL;
> >>> - const struct dpu_format *fmt;
> >>>struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg;
> >>>struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->r_pipe_cfg;
> >>>struct drm_rect fb_rect = { 0 };
> >>>uint32_t max_linewidth;
> >>> - unsigned int rotation;
> >>> - uint32_t supported_rotations;
> >>> - const struct dpu_sspp_cfg *pipe_hw_caps;
> >>> - const struct dpu_sspp_sub_blks *sblk;
> >>>
> >>> - if (new_plane_state->crtc)
> >>> - crtc_state = drm_atomic_get_new_crtc_state(state,
> >>> -
> >>> new_plane_state->crtc);
> >>> -
> >>> - pipe->sspp = dpu_rm_get_sspp(&dpu_kms->rm, pdpu->pipe);
> >>> - r_pipe->sspp = NULL;
> >>> -
> >>> - if (!pipe->sspp)
> >>> - return -EINVAL;
> >>> -
> >>> - pipe_hw_caps = pipe->sspp->cap;
> >>> - sblk = pipe->sspp->cap->sblk;
> >>> -
> >>> - if (sblk->scaler_blk.len) {
> >>> - min_scale = FRAC_16_16(1, MAX_UPSCALE_RATIO);
> >>> - max_scale = MAX_DOWNSCALE_RATIO << 16;
> >>> - } else {
> >>> - min_scale = 1 << 16;
> >>> - max_scale = 1 << 16;
> >>> - }
> >>> + min_scale = FRAC_16_16(1, MAX_UPSCALE_RATIO);
> >>> + max_scale = MAX_DOWNSCALE_RATIO << 16;
> >>>
> >>>ret = drm_atomic_helper_check_plane_state(new_plane_state,
> >>> crtc_state,
> >>> min_scale,
> >>> @@ -844,11 +816,6 @@ static int dpu_plane_atomic_check(struct drm_plane
> >>> *plane,
> >>>if (!new_plane_state->visible)
> >>>return 0;
> >>>
> >>> - pipe->multirect_index = DPU_SSPP_RECT_SOLO;
> >>> - pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
> >>> - r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
> >>> - r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
> >>> -
> >>>pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
> >>>if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
> >>>DPU_ERROR("> %d plane stages assigned\n",
> >>> @@ -872,8 +839,6 @@ static int dpu_plane_atomic_check(struct drm_plane
Re: [PATCH v4 06/13] drm/msm/dpu: split dpu_plane_atomic_check()
On Thu, 6 Jun 2024 at 11:53, Dmitry Baryshkov
wrote:
>
> On Thu, 6 Jun 2024 at 02:47, Abhinav Kumar wrote:
> >
> >
> >
> > On 6/5/2024 4:32 PM, Dmitry Baryshkov wrote:
> > > On Thu, 6 Jun 2024 at 02:19, Abhinav Kumar
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > >>> Split dpu_plane_atomic_check() function into two pieces:
> > >>>
> > >>> dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
> > >>> without touching the associated pipe,
> > >>>
> > >>> and
> > >>>
> > >>> dpu_plane_atomic_check_pipes(), which takes into account used pipes.
> > >>>
> > >>> Signed-off-by: Dmitry Baryshkov
> > >>> ---
> > >>>drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 184
> > >>> ++
> > >>>1 file changed, 117 insertions(+), 67 deletions(-)
> > >>>
> > >>> + if (new_plane_state->crtc)
> > >>> + crtc_state = drm_atomic_get_new_crtc_state(state,
> > >>> +
> > >>> new_plane_state->crtc);
> > >>> +
> > >>> + if (pdpu->pipe != SSPP_NONE) {
> > >>
> > >> This check was not present iirc, why did you have to add this?
> > >> RM will return the same SSPP unless freed. So why this additional check?
> > >
> > > If pdpu->pipe is not SSPP_NONE, then virtual planes are disabled and
> > > there is a fixed 1:1 relationship between planes and SSPP blocks.
> > >
> >
> > True, pdpu->pipe is currently assigned in dpu_plane_init(), so we will
> > always be hitting this condition.
> >
> > Perhaps the patches later on are changing that, so shouldnt this part
> > come along with those?
>
> Ack, I'll move it to patch 5.
Patch 8, of course.
--
With best wishes
Dmitry
[PATCH RESEND v5] drm/mediatek: dpi/dsi: fix possible_crtcs calculation
mtk_find_possible_crtcs() assumes that the main path will always have
the CRTC with id 0, the ext id 1 and the third id 2. This is only true
if the paths are all available. But paths are optional (see also
comment in mtk_drm_kms_init()), e.g. the main path might not be enabled
or available at all. Then the CRTC IDs will shift one up, e.g. ext will
be 0 and the third path will be 1.
To fix that, dynamically calculate the IDs by the presence of the paths.
While at it, make the return code a signed one and return -ENODEV if no
path is found and handle the error in the callers.
Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
---
You can find v4 at [1]. Unfortunately, it was never applied and in the
meantime there was a change in mtk_find_possible_crtcs(). So I've
dropped Nícolas Reviewed and Tested-by tags and Angelos Reviewed-by
tag.
[1] https://lore.kernel.org/r/20230905084922.3908121-2-mwa...@kernel.org/
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 105
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 5 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +-
4 files changed, 78 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index 17b036411292..9a8c1cace8a0 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -514,29 +514,42 @@ static bool mtk_ddp_comp_find(struct device *dev,
return false;
}
-static unsigned int mtk_ddp_comp_find_in_route(struct device *dev,
- const struct mtk_drm_route
*routes,
- unsigned int num_routes,
- struct mtk_ddp_comp *ddp_comp)
+static int mtk_ddp_comp_find_in_route(struct device *dev,
+ const struct mtk_drm_route *routes,
+ unsigned int num_routes,
+ struct mtk_ddp_comp *ddp_comp)
{
- int ret;
unsigned int i;
- if (!routes) {
- ret = -EINVAL;
- goto err;
- }
+ if (!routes)
+ return -EINVAL;
for (i = 0; i < num_routes; i++)
if (dev == ddp_comp[routes[i].route_ddp].dev)
return BIT(routes[i].crtc_id);
- ret = -ENODEV;
-err:
+ return -ENODEV;
+}
- DRM_INFO("Failed to find comp in ddp table, ret = %d\n", ret);
+static bool mtk_ddp_path_available(const unsigned int *path,
+ unsigned int path_len,
+ struct device_node **comp_node)
+{
+ unsigned int i;
- return 0;
+ if (!path || !path_len)
+ return false;
+
+ for (i = 0U; i < path_len; i++) {
+ /* OVL_ADAPTOR doesn't have a device node */
+ if (path[i] == DDP_COMPONENT_DRM_OVL_ADAPTOR)
+ continue;
+
+ if (!comp_node[path[i]])
+ return false;
+ }
+
+ return true;
}
int mtk_ddp_comp_get_id(struct device_node *node,
@@ -554,32 +567,52 @@ int mtk_ddp_comp_get_id(struct device_node *node,
return -EINVAL;
}
-unsigned int mtk_find_possible_crtcs(struct drm_device *drm, struct device
*dev)
+int mtk_find_possible_crtcs(struct drm_device *drm, struct device *dev)
{
struct mtk_drm_private *private = drm->dev_private;
- unsigned int ret = 0;
-
- if (mtk_ddp_comp_find(dev,
- private->data->main_path,
- private->data->main_len,
- private->ddp_comp))
- ret = BIT(0);
- else if (mtk_ddp_comp_find(dev,
- private->data->ext_path,
- private->data->ext_len,
- private->ddp_comp))
- ret = BIT(1);
- else if (mtk_ddp_comp_find(dev,
- private->data->third_path,
- private->data->third_len,
- private->ddp_comp))
- ret = BIT(2);
- else
- ret = mtk_ddp_comp_find_in_route(dev,
-private->data->conn_routes,
-private->data->num_conn_routes,
-private->ddp_comp);
+ const struct mtk_mmsys_driver_data *data;
+ struct mtk_drm_private *priv_n;
+ int i = 0, j;
+ int ret;
+ for (j = 0; j < private->data->mmsys_dev_num; j++) {
+ priv_n = private->all_drm_private[j];
+ data = priv_n->data;
+
+
Re: [PATCH v2] [drm/meson] meson_plane: Add error handling v2(re-aligned)
Hi, On Wed, 29 Nov 2023 03:34:05 -0800, Haoran Liu wrote: > This patch adds robust error handling to the meson_plane_create > function in drivers/gpu/drm/meson/meson_plane.c. The function > previously lacked proper handling for potential failure scenarios > of the drm_universal_plane_init call. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] meson_plane: Add error handling v2(re-aligned) https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3c28b239620e249b68beeca17f429e317fa6b8d4 -- Neil
[PATCH v8 01/16] soc: mediatek: Disable 9-bit alpha in ETHDR
From: Hsiao Chien Sung When 9-bit alpha is enabled, its value will be converted from 0-255 to 0-256 (255 = not defined). This is designed for special HDR related calculation, which should be disabled by default, otherwise, alpha blending will not work correctly. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Hsiao Chien Sung --- drivers/soc/mediatek/mtk-mmsys.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c index f370f4ec4b88..938240714e54 100644 --- a/drivers/soc/mediatek/mtk-mmsys.c +++ b/drivers/soc/mediatek/mtk-mmsys.c @@ -236,6 +236,7 @@ void mtk_mmsys_mixer_in_config(struct device *dev, int idx, bool alpha_sel, u16 mtk_mmsys_update_bits(mmsys, MT8195_VDO1_MIXER_IN1_ALPHA + (idx - 1) * 4, ~0, alpha << 16 | alpha, cmdq_pkt); + mtk_mmsys_update_bits(mmsys, MT8195_VDO1_HDR_TOP_CFG, BIT(15 + idx), 0, cmdq_pkt); mtk_mmsys_update_bits(mmsys, MT8195_VDO1_HDR_TOP_CFG, BIT(19 + idx), alpha_sel << (19 + idx), cmdq_pkt); mtk_mmsys_update_bits(mmsys, MT8195_VDO1_MIXER_IN1_PAD + (idx - 1) * 4, -- 2.18.0
[PATCH v8 11/16] drm/mediatek: Support "Pre-multiplied" blending in OVL
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 40 +
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 54a6f11aa867..de1633988921 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -52,13 +52,16 @@
#define GMC_THRESHOLD_HIGH ((1 << GMC_THRESHOLD_BITS) / 4)
#define GMC_THRESHOLD_LOW ((1 << GMC_THRESHOLD_BITS) / 8)
+#define OVL_CON_CLRFMT_MAN BIT(23)
#define OVL_CON_BYTE_SWAP BIT(24)
-#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
+#define OVL_CON_RGB_SWAP BIT(25)
#define OVL_CON_CLRFMT_RGB (1 << 12)
#define OVL_CON_CLRFMT_RGBA(2 << 12)
#define OVL_CON_CLRFMT_ARGB(3 << 12)
#define OVL_CON_CLRFMT_UYVY(4 << 12)
#define OVL_CON_CLRFMT_YUYV(5 << 12)
+#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
+#define OVL_CON_CLRFMT_PARGB (OVL_CON_CLRFMT_ARGB |
OVL_CON_CLRFMT_MAN)
#define OVL_CON_CLRFMT_RGB565(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
0 : OVL_CON_CLRFMT_RGB)
#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
@@ -72,6 +75,8 @@
#defineOVL_CON_VIRT_FLIP BIT(9)
#defineOVL_CON_HORZ_FLIP BIT(10)
+#define OVL_COLOR_ALPHAGENMASK(31, 24)
+
static inline bool is_10bit_rgb(u32 fmt)
{
switch (fmt) {
@@ -296,7 +301,13 @@ void mtk_ovl_config(struct device *dev, unsigned int w,
if (w != 0 && h != 0)
mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, &ovl->cmdq_reg,
ovl->regs,
DISP_REG_OVL_ROI_SIZE);
- mtk_ddp_write_relaxed(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_ROI_BGCLR);
+
+ /*
+* The background color must be opaque black (ARGB),
+* otherwise the alpha blending will have no effect
+*/
+ mtk_ddp_write_relaxed(cmdq_pkt, OVL_COLOR_ALPHA, &ovl->cmdq_reg,
+ ovl->regs, DISP_REG_OVL_ROI_BGCLR);
mtk_ddp_write(cmdq_pkt, 0x1, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_RST);
mtk_ddp_write(cmdq_pkt, 0x0, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_RST);
@@ -372,7 +383,8 @@ void mtk_ovl_layer_off(struct device *dev, unsigned int idx,
DISP_REG_OVL_RDMA_CTRL(idx));
}
-static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
+ unsigned int blend_mode)
{
/* The return value in switch "MEM_MODE_INPUT_FORMAT_XXX"
* is defined in mediatek HW data sheet.
@@ -391,21 +403,35 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl
*ovl, unsigned int fmt)
return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
+ return blend_mode == DRM_MODE_BLEND_COVERAGE ?
+ OVL_CON_CLRFMT_ARGB :
+ OVL_CON_CLRFMT_PARGB;
case DRM_FORMAT_RGBX1010102:
case DRM_FORMAT_RGBA1010102:
return OVL_CON_CLRFMT_ARGB;
case DRM_FORMAT_BGRX:
case DRM_FORMAT_BGRA:
+ return OVL_CON_BYTE_SWAP |
+ (blend_mode == DRM_MODE_BLEND_COVERAGE ?
+ OVL_CON_CLRFMT_ARGB :
+ OVL_CON_CLRFMT_PARGB);
case DRM_FORMAT_BGRX1010102:
case DRM_FORMAT_BGRA1010102:
return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+ return blend_mode == DRM_MODE_BLEND_COVERAGE ?
+ OVL_CON_CLRFMT_RGBA :
+ OVL_CON_CLRFMT_PARGB;
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_ARGB2101010:
return OVL_CON_CLRFMT_RGBA;
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
+ return OVL_CON_RGB_SWAP |
+ (blend_mode == DRM_MODE_BLEND_COVERAGE ?
+ OVL_CON_CLRFMT_RGBA :
+ OVL_CON_CLRFMT_PARGB);
case DRM_FORMAT_XBGR2101010:
case DRM_FORMAT_ABGR2101010:
return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
@@ -448,9 +474,11 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
return;
}
- con = ovl_fmt_convert(ovl, fmt);
- if (state->base.fb && state->base.fb->format->has_alpha)
- con |= OVL_CON_AEN | OVL_CON_ALPHA;
+ con = ovl_fmt_convert(ovl, fmt, blend_mode);
+ if (state->b
[PATCH v8 03/16] drm/mediatek: Add missing plane settings when async update
From: Hsiao Chien Sung
Fix an issue that plane coordinate was not saved when
calling async update.
Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
update")
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c
b/drivers/gpu/drm/mediatek/mtk_plane.c
index 4625deb21d40..a74b26d35985 100644
--- a/drivers/gpu/drm/mediatek/mtk_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_plane.c
@@ -227,6 +227,8 @@ static void mtk_plane_atomic_async_update(struct drm_plane
*plane,
plane->state->src_y = new_state->src_y;
plane->state->src_h = new_state->src_h;
plane->state->src_w = new_state->src_w;
+ plane->state->dst.x1 = new_state->dst.x1;
+ plane->state->dst.y1 = new_state->dst.y1;
mtk_plane_update_new_state(new_state, new_plane_state);
swap(plane->state->fb, new_state->fb);
--
2.18.0
[PATCH v8 10/16] drm/mediatek: Support "None" blending in Mixer
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index 4ffd0a064861..bcced62e455d 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -3,6 +3,7 @@
* Copyright (c) 2021 MediaTek Inc.
*/
+#include
#include
#include
#include
@@ -154,6 +155,7 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned
int idx,
unsigned int offset = (pending->x & 1) << 31 | pending->y << 16 |
pending->x;
unsigned int align_width = ALIGN_DOWN(pending->width, 2);
unsigned int alpha_con = 0;
+ bool replace_src_a = false;
dev_dbg(dev, "%s+ idx:%d", __func__, idx);
@@ -173,8 +175,16 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned
int idx,
if (state->base.fb && state->base.fb->format->has_alpha)
alpha_con = MIXER_ALPHA_AEN | MIXER_ALPHA;
- mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1, alpha_con ? false :
true,
- DEFAULT_9BIT_ALPHA,
+ if (state->base.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
+ (state->base.fb && !state->base.fb->format->has_alpha)) {
+ /*
+* Mixer doesn't support CONST_BLD mode,
+* use a trick to make the output equivalent
+*/
+ replace_src_a = true;
+ }
+
+ mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1, replace_src_a,
MIXER_ALPHA,
pending->x & 1 ? MIXER_INX_MODE_EVEN_EXTEND :
MIXER_INX_MODE_BYPASS, align_width / 2 - 1,
cmdq_pkt);
--
2.18.0
[PATCH v8 02/16] drm/mediatek: Add OVL compatible name for MT8195
From: Hsiao Chien Sung
Add OVL compatible name for MT8195.
Without this commit, DRM won't work after modifying the device tree.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b5f605751b0a..8e047043202b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -743,6 +743,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8192-disp-ovl",
.data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8195-disp-ovl",
+ .data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
.data = (void *)MTK_DISP_OVL_2L },
{ .compatible = "mediatek,mt8192-disp-ovl-2l",
--
2.18.0
[PATCH v8 16/16] drm/mediatek: Support CRC in OVL adaptor
From: Hsiao Chien Sung
We choose Mixer as CRC generator in OVL adaptor since
its frame done event will trigger vblanks, we can know
when is safe to retrieve CRC of the frame.
In OVL adaptor, there's no image procession after Mixer,
unlike the OVL in VDOSYS0, Mixer's CRC will include all
the effects that are applied to the frame.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 5 ++
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 5 ++
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 35 +
drivers/gpu/drm/mediatek/mtk_ethdr.c | 72 +++
drivers/gpu/drm/mediatek/mtk_ethdr.h | 7 ++
5 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index 07c3b5c5e14e..473460ab3a7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -408,6 +408,11 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
.clk_enable = mtk_ovl_adaptor_clk_enable,
.clk_disable = mtk_ovl_adaptor_clk_disable,
.config = mtk_ovl_adaptor_config,
+ .crc_cnt = mtk_ovl_adaptor_crc_cnt,
+ .crc_entry = mtk_ovl_adaptor_crc_entry,
+ .crc_read = mtk_ovl_adaptor_crc_read,
+ .crc_start = mtk_ovl_adaptor_crc_start,
+ .crc_stop = mtk_ovl_adaptor_crc_stop,
.start = mtk_ovl_adaptor_start,
.stop = mtk_ovl_adaptor_stop,
.layer_nr = mtk_ovl_adaptor_layer_nr,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index a03d7a10847a..0ef32bc3b996 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -140,6 +140,11 @@ const u32 *mtk_ovl_adaptor_get_formats(struct device *dev);
size_t mtk_ovl_adaptor_get_num_formats(struct device *dev);
enum drm_mode_status mtk_ovl_adaptor_mode_valid(struct device *dev,
const struct drm_display_mode
*mode);
+size_t mtk_ovl_adaptor_crc_cnt(struct device *dev);
+u32 *mtk_ovl_adaptor_crc_entry(struct device *dev);
+void mtk_ovl_adaptor_crc_read(struct device *dev);
+void mtk_ovl_adaptor_crc_start(struct device *dev);
+void mtk_ovl_adaptor_crc_stop(struct device *dev);
void mtk_rdma_bypass_shadow(struct device *dev);
int mtk_rdma_clk_enable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 2b62d6475918..02a617ac8265 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -207,6 +207,41 @@ void mtk_ovl_adaptor_layer_config(struct device *dev,
unsigned int idx,
mtk_ethdr_layer_config(ethdr, idx, state, cmdq_pkt);
}
+size_t mtk_ovl_adaptor_crc_cnt(struct device *dev)
+{
+ struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+ return
mtk_ethdr_crc_cnt(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+u32 *mtk_ovl_adaptor_crc_entry(struct device *dev)
+{
+ struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+ return
mtk_ethdr_crc_entry(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+void mtk_ovl_adaptor_crc_read(struct device *dev)
+{
+ struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+ mtk_ethdr_crc_read(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+void mtk_ovl_adaptor_crc_start(struct device *dev)
+{
+ struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+ mtk_ethdr_crc_start(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
+void mtk_ovl_adaptor_crc_stop(struct device *dev)
+{
+ struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+ mtk_ethdr_crc_stop(ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0]);
+}
+
void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index d01f65819816..1e6a51979ec6 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -25,6 +25,9 @@
#define MIX_FME_CPL_INTEN BIT(1)
#define MIX_INTSTA 0x8
#define MIX_EN 0xc
+#define MIX_TRIG 0x10
+#define MIX_TRIG_CRC_ENBIT(8)
+#define MIX_TRIG_CRC_RST BIT(9)
#define MIX_RST0x14
#define MIX_ROI_SIZE 0x18
#define MIX_DATAPATH_CON 0x1c
@@ -40,6 +43,11 @@
#define PREMULTI_SOURCE(3 << 12)
#define MIX_L_SRC_SIZE(n) (0x30 + 0x18 * (n))
#define MIX_L_SRC_OFFSET(n)(0x34 + 0x18 * (n)
[PATCH v8 09/16] drm/mediatek: Support "None" blending in OVL
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 738244a6164e..54a6f11aa867 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -38,6 +38,7 @@
#define DISP_REG_OVL_PITCH_MSB(n) (0x0040 + 0x20 * (n))
#define OVL_PITCH_MSB_2ND_SUBBUF BIT(16)
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
+#define OVL_CONST_BLENDBIT(28)
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
#define DISP_REG_OVL_ADDR_MT2701 0x0040
@@ -428,6 +429,8 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
unsigned int fmt = pending->format;
unsigned int offset = (pending->y << 16) | pending->x;
unsigned int src_size = (pending->height << 16) | pending->width;
+ unsigned int blend_mode = state->base.pixel_blend_mode;
+ unsigned int ignore_pixel_alpha = 0;
unsigned int con;
bool is_afbc = pending->modifier != DRM_FORMAT_MOD_LINEAR;
union overlay_pitch {
@@ -449,6 +452,15 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
if (state->base.fb && state->base.fb->format->has_alpha)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
+ /* CONST_BLD must be enabled for XRGB formats although the alpha channel
+* can be ignored, or OVL will still read the value from memory.
+* For RGB888 related formats, whether CONST_BLD is enabled or not won't
+* affect the result. Therefore we use !has_alpha as the condition.
+*/
+ if (blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
+ (state->base.fb && !state->base.fb->format->has_alpha))
+ ignore_pixel_alpha = OVL_CONST_BLEND;
+
if (pending->rotation & DRM_MODE_REFLECT_Y) {
con |= OVL_CON_VIRT_FLIP;
addr += (pending->height - 1) * pending->pitch;
@@ -464,8 +476,8 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
mtk_ddp_write_relaxed(cmdq_pkt, con, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_CON(idx));
- mtk_ddp_write_relaxed(cmdq_pkt, overlay_pitch.split_pitch.lsb,
&ovl->cmdq_reg, ovl->regs,
- DISP_REG_OVL_PITCH(idx));
+ mtk_ddp_write_relaxed(cmdq_pkt, overlay_pitch.split_pitch.lsb |
ignore_pixel_alpha,
+ &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_PITCH(idx));
mtk_ddp_write_relaxed(cmdq_pkt, src_size, &ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_SRC_SIZE(idx));
mtk_ddp_write_relaxed(cmdq_pkt, offset, &ovl->cmdq_reg, ovl->regs,
--
2.18.0
[PATCH v8 12/16] drm/mediatek: Support "Pre-multiplied" blending in Mixer
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index bcced62e455d..d01f65819816 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#define MIX_SRC_L0_EN BIT(0)
#define MIX_L_SRC_CON(n) (0x28 + 0x18 * (n))
#define NON_PREMULTI_SOURCE(2 << 12)
+#define PREMULTI_SOURCE(3 << 12)
#define MIX_L_SRC_SIZE(n) (0x30 + 0x18 * (n))
#define MIX_L_SRC_OFFSET(n)(0x34 + 0x18 * (n))
#define MIX_FUNC_DCM0 0x120
@@ -172,8 +174,12 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned
int idx,
return;
}
- if (state->base.fb && state->base.fb->format->has_alpha)
- alpha_con = MIXER_ALPHA_AEN | MIXER_ALPHA;
+ alpha_con |= MIXER_ALPHA_AEN | (state->base.alpha & MIXER_ALPHA);
+
+ if (state->base.pixel_blend_mode != DRM_MODE_BLEND_COVERAGE)
+ alpha_con |= PREMULTI_SOURCE;
+ else
+ alpha_con |= NON_PREMULTI_SOURCE;
if (state->base.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
(state->base.fb && !state->base.fb->format->has_alpha)) {
@@ -191,8 +197,7 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned
int idx,
mtk_ddp_write(cmdq_pkt, pending->height << 16 | align_width,
&mixer->cmdq_base,
mixer->regs, MIX_L_SRC_SIZE(idx));
mtk_ddp_write(cmdq_pkt, offset, &mixer->cmdq_base, mixer->regs,
MIX_L_SRC_OFFSET(idx));
- mtk_ddp_write_mask(cmdq_pkt, alpha_con, &mixer->cmdq_base, mixer->regs,
MIX_L_SRC_CON(idx),
- 0x1ff);
+ mtk_ddp_write(cmdq_pkt, alpha_con, &mixer->cmdq_base, mixer->regs,
MIX_L_SRC_CON(idx));
mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &mixer->cmdq_base, mixer->regs,
MIX_SRC_CON,
BIT(idx));
}
--
2.18.0
[PATCH v8 06/16] drm/mediatek: Turn off the layers with zero width or height
From: Hsiao Chien Sung
We found that IGT (Intel GPU Tool) will try to commit layers with
zero width or height and lead to undefined behaviors in hardware.
Disable the layers in such a situation.
Fixes: 777b7bc86a0a ("UPSTREAM: drm/mediatek: Add ovl_adaptor support for
MT8195")
Fixes: fa97fe71f6f9 ("UPSTREAM: drm/mediatek: Add ETHDR support for MT8195")
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 2 +-
drivers/gpu/drm/mediatek/mtk_ethdr.c| 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 02dd7dcdfedb..2b62d6475918 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -158,7 +158,7 @@ void mtk_ovl_adaptor_layer_config(struct device *dev,
unsigned int idx,
merge = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_MERGE0 + idx];
ethdr = ovl_adaptor->ovl_adaptor_comp[OVL_ADAPTOR_ETHDR0];
- if (!pending->enable) {
+ if (!pending->enable || !pending->width || !pending->height) {
mtk_merge_stop_cmdq(merge, cmdq_pkt);
mtk_mdp_rdma_stop(rdma_l, cmdq_pkt);
mtk_mdp_rdma_stop(rdma_r, cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
b/drivers/gpu/drm/mediatek/mtk_ethdr.c
index 156c6ff547e8..4ffd0a064861 100644
--- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
+++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
@@ -160,7 +160,12 @@ void mtk_ethdr_layer_config(struct device *dev, unsigned
int idx,
if (idx >= 4)
return;
- if (!pending->enable) {
+ if (!pending->enable || !pending->width || !pending->height) {
+ /*
+* instead of disabling layer with MIX_SRC_CON directly
+* set the size to 0 to avoid screen shift due to mixer
+* mode switch (hardware behavior)
+*/
mtk_ddp_write(cmdq_pkt, 0, &mixer->cmdq_base, mixer->regs,
MIX_L_SRC_SIZE(idx));
return;
}
--
2.18.0
[PATCH v8 04/16] drm/mediatek: Add DRM_MODE_ROTATE_0 to rotation property
From: Hsiao Chien Sung
Always add DRM_MODE_ROTATE_0 to rotation property to meet
IGT's (Intel GPU Tools) requirement.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 6 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 17 +
drivers/gpu/drm/mediatek/mtk_plane.c| 2 +-
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
index 26236691ce4c..f7fe2e08dc8e 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
@@ -192,7 +192,11 @@ unsigned int mtk_ddp_comp_supported_rotations(struct
mtk_ddp_comp *comp)
if (comp->funcs && comp->funcs->supported_rotations)
return comp->funcs->supported_rotations(comp->dev);
- return 0;
+ /*
+* In order to pass IGT tests, DRM_MODE_ROTATE_0 is required when
+* rotation is not supported.
+*/
+ return DRM_MODE_ROTATE_0;
}
static inline unsigned int mtk_ddp_comp_layer_nr(struct mtk_ddp_comp *comp)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index b552a02d7eae..862ab683ed1b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -296,27 +296,20 @@ int mtk_ovl_layer_check(struct device *dev, unsigned int
idx,
struct mtk_plane_state *mtk_state)
{
struct drm_plane_state *state = &mtk_state->base;
- unsigned int rotation = 0;
- rotation = drm_rotation_simplify(state->rotation,
-DRM_MODE_ROTATE_0 |
-DRM_MODE_REFLECT_X |
-DRM_MODE_REFLECT_Y);
- rotation &= ~DRM_MODE_ROTATE_0;
-
- /* We can only do reflection, not rotation */
- if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
+ /* check if any unsupported rotation is set */
+ if (state->rotation & ~mtk_ovl_supported_rotations(dev))
return -EINVAL;
/*
* TODO: Rotating/reflecting YUV buffers is not supported at this time.
* Only RGB[AX] variants are supported.
+* Since DRM_MODE_ROTATE_0 means "no rotation", we should not
+* reject layers with this property.
*/
- if (state->fb->format->is_yuv && rotation != 0)
+ if (state->fb->format->is_yuv && (state->rotation & ~DRM_MODE_ROTATE_0))
return -EINVAL;
- state->rotation = rotation;
-
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c
b/drivers/gpu/drm/mediatek/mtk_plane.c
index a74b26d35985..1723d4333f37 100644
--- a/drivers/gpu/drm/mediatek/mtk_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_plane.c
@@ -338,7 +338,7 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane
*plane,
return err;
}
- if (supported_rotations & ~DRM_MODE_ROTATE_0) {
+ if (supported_rotations) {
err = drm_plane_create_rotation_property(plane,
DRM_MODE_ROTATE_0,
supported_rotations);
--
2.18.0
[PATCH v8 13/16] drm/mediatek: Support alpha blending in display driver
From: Hsiao Chien Sung
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
For more information, there are three pixel blend modes in DRM driver:
"None", "Pre-multiplied", and "Coverage".
To understand the difference between these modes, let's take a look at
the following two approaches to do alpha blending:
1. Straight:
dst.RGB = src.RGB * src.A + dst.RGB * (1 - src.A)
This is straightforward and easy to understand, when the source layer is
compositing with the destination layer, it's alpha will affect the
result. This is also known as "post-multiplied", or "Coverage" mode.
2. Pre-multiplied:
dst.RGB = src.RGB + dst.RGB * (1 - src.A)
Since the source RGB have already multiplied its alpha, only destination
RGB need to multiply it. This is the "Pre-multiplied" mode in DRM.
For the "None" blend mode in DRM, it means the pixel alpha is ignored
when compositing the layers, only the constant alpha for the composited
layer will take effects.
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_plane.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c
b/drivers/gpu/drm/mediatek/mtk_plane.c
index 1723d4333f37..5bf757a3ef20 100644
--- a/drivers/gpu/drm/mediatek/mtk_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_plane.c
@@ -346,6 +346,17 @@ int mtk_plane_init(struct drm_device *dev, struct
drm_plane *plane,
DRM_INFO("Create rotation property failed\n");
}
+ err = drm_plane_create_alpha_property(plane);
+ if (err)
+ DRM_ERROR("failed to create property: alpha\n");
+
+ err = drm_plane_create_blend_mode_property(plane,
+ BIT(DRM_MODE_BLEND_PREMULTI)
|
+ BIT(DRM_MODE_BLEND_COVERAGE)
|
+
BIT(DRM_MODE_BLEND_PIXEL_NONE));
+ if (err)
+ DRM_ERROR("failed to create property: blend_mode\n");
+
drm_plane_helper_add(plane, &mtk_plane_helper_funcs);
return 0;
--
2.18.0
[PATCH v8 05/16] drm/mediatek: Set DRM mode configs accordingly
From: Hsiao Chien Sung
Set DRM mode configs limitation according to the hardware capabilities
and pass the IGT checks as below:
- The test "graphics.IgtKms.kms_plane" requires a frame buffer with
width of 4512 pixels (> 4096).
- The test "graphics.IgtKms.kms_cursor_crc" checks if the cursor size is
defined, and run the test with cursor size from 1x1 to 512x512.
Please notice that the test conditions may change as IGT is updated.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 22 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 8e047043202b..c9cad3a82737 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -294,6 +294,9 @@ static const struct mtk_mmsys_driver_data
mt8188_vdosys0_driver_data = {
.conn_routes = mt8188_mtk_ddp_main_routes,
.num_conn_routes = ARRAY_SIZE(mt8188_mtk_ddp_main_routes),
.mmsys_dev_num = 2,
+ .max_width = 8191,
+ .min_width = 1,
+ .min_height = 1,
};
static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
@@ -308,6 +311,9 @@ static const struct mtk_mmsys_driver_data
mt8195_vdosys0_driver_data = {
.main_path = mt8195_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
.mmsys_dev_num = 2,
+ .max_width = 8191,
+ .min_width = 1,
+ .min_height = 1,
};
static const struct mtk_mmsys_driver_data mt8195_vdosys1_driver_data = {
@@ -315,6 +321,9 @@ static const struct mtk_mmsys_driver_data
mt8195_vdosys1_driver_data = {
.ext_len = ARRAY_SIZE(mt8195_mtk_ddp_ext),
.mmsys_id = 1,
.mmsys_dev_num = 2,
+ .max_width = 8191,
+ .min_width = 2, /* 2-pixel align when ethdr is bypassed */
+ .min_height = 1,
};
static const struct of_device_id mtk_drm_of_ids[] = {
@@ -493,6 +502,15 @@ static int mtk_drm_kms_init(struct drm_device *drm)
for (j = 0; j < private->data->mmsys_dev_num; j++) {
priv_n = private->all_drm_private[j];
+ if (priv_n->data->max_width)
+ drm->mode_config.max_width =
priv_n->data->max_width;
+
+ if (priv_n->data->min_width)
+ drm->mode_config.min_width =
priv_n->data->min_width;
+
+ if (priv_n->data->min_height)
+ drm->mode_config.min_height =
priv_n->data->min_height;
+
if (i == CRTC_MAIN && priv_n->data->main_len) {
ret = mtk_crtc_create(drm,
priv_n->data->main_path,
priv_n->data->main_len, j,
@@ -520,6 +538,10 @@ static int mtk_drm_kms_init(struct drm_device *drm)
}
}
+ /* IGT will check if the cursor size is configured */
+ drm->mode_config.cursor_width = drm->mode_config.max_width;
+ drm->mode_config.cursor_height = drm->mode_config.max_height;
+
/* Use OVL device for all DMA memory allocations */
crtc = drm_crtc_from_index(drm, 0);
if (crtc)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 78d698ede1bf..6cfa790e8df5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -46,6 +46,10 @@ struct mtk_mmsys_driver_data {
bool shadow_register;
unsigned int mmsys_id;
unsigned int mmsys_dev_num;
+
+ int max_width;
+ int min_width;
+ int min_height;
};
struct mtk_drm_private {
--
2.18.0
[PATCH v8 14/16] drm/mediatek: Support CRC in display driver
From: Hsiao Chien Sung
Register CRC related function pointers to support
CRC retrieval.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 280
drivers/gpu/drm/mediatek/mtk_crtc.h | 38
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 5 +
3 files changed, 323 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c
b/drivers/gpu/drm/mediatek/mtk_crtc.c
index 6f34f573e127..be7cf61b9f9b 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "mtk_crtc.h"
#include "mtk_ddp_comp.h"
@@ -69,6 +70,9 @@ struct mtk_crtc {
/* lock for display hardware access */
struct mutexhw_lock;
boolconfig_updating;
+
+ struct mtk_ddp_comp *crc_provider;
+ struct drm_vblank_work crc_work;
};
struct mtk_crtc_state {
@@ -703,6 +707,88 @@ static void mtk_crtc_update_output(struct drm_crtc *crtc,
}
}
+static void mtk_crtc_crc_work(struct kthread_work *base)
+{
+ struct drm_vblank_work *work = to_drm_vblank_work(base);
+ struct mtk_crtc *mtk_crtc =
+ container_of(work, typeof(*mtk_crtc), crc_work);
+ struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
+
+ if (!comp) {
+ DRM_WARN("%s(crtc-%d): no crc provider\n",
+__func__, drm_crtc_index(&mtk_crtc->base));
+ return;
+ }
+
+ if (mtk_crtc->base.crc.opened) {
+ u64 vblank = drm_crtc_vblank_count(&mtk_crtc->base);
+
+ comp->funcs->crc_read(comp->dev);
+
+ /* could take more than 50ms to finish */
+ drm_crtc_add_crc_entry(&mtk_crtc->base, true, vblank,
+ comp->funcs->crc_entry(comp->dev));
+
+ drm_vblank_work_schedule(&mtk_crtc->crc_work, vblank + 1, true);
+ } else {
+ comp->funcs->crc_stop(comp->dev);
+ }
+}
+
+static int mtk_crtc_set_crc_source(struct drm_crtc *crtc, const char *src)
+{
+ struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
+
+ if (!comp) {
+ DRM_ERROR("%s(crtc-%d): no crc provider\n",
+ __func__, drm_crtc_index(crtc));
+ return -ENOENT;
+ }
+
+ if (!src)
+ return -EINVAL;
+
+ if (strcmp(src, "auto") != 0) {
+ DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
+ __func__, drm_crtc_index(crtc), src);
+ return -EINVAL;
+ }
+
+ comp->funcs->crc_start(comp->dev);
+
+ /*
+* skip the first crc because the first frame (vblank + 1) is configured
+* by mtk_crtc_ddp_hw_init() when atomic enable
+*/
+ drm_vblank_work_schedule(&mtk_crtc->crc_work,
+drm_crtc_vblank_count(crtc) + 2, false);
+ return 0;
+}
+
+static int mtk_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src,
+ size_t *cnt)
+{
+ struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
+
+ if (!comp) {
+ DRM_ERROR("%s(crtc-%d): no crc provider\n",
+ __func__, drm_crtc_index(crtc));
+ return -ENOENT;
+ }
+
+ if (src && strcmp(src, "auto") != 0) {
+ DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
+ __func__, drm_crtc_index(crtc), src);
+ return -EINVAL;
+ }
+
+ *cnt = comp->funcs->crc_cnt(comp->dev);
+
+ return 0;
+}
+
int mtk_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
struct mtk_plane_state *state)
{
@@ -751,6 +837,8 @@ static void mtk_crtc_atomic_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
mtk_crtc->enabled = true;
+
+ drm_vblank_work_init(&mtk_crtc->crc_work, crtc, mtk_crtc_crc_work);
}
static void mtk_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -840,6 +928,8 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
.atomic_destroy_state = mtk_crtc_destroy_state,
.enable_vblank = mtk_crtc_enable_vblank,
.disable_vblank = mtk_crtc_disable_vblank,
+ .set_crc_source = mtk_crtc_set_crc_source,
+ .verify_crc_source = mtk_crtc_verify_crc_source,
};
static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -1033,6 +1123,13 @@ int mtk_crtc_create(struct drm_device *drm_dev, const
unsigned int *path,
if (comp->funcs->ctm_set)
has_ctm = true;
+
+ if (comp->funcs->crc_cnt &&
+ comp->funcs->crc_entry &&
+
[PATCH v8 07/16] drm/mediatek: Support more 10bit formats in OVL
From: Hsiao Chien Sung
Support more 10bit formats in OVL.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 32 ++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 862ab683ed1b..d970cdce06bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -71,6 +71,22 @@
#defineOVL_CON_VIRT_FLIP BIT(9)
#defineOVL_CON_HORZ_FLIP BIT(10)
+static inline bool is_10bit_rgb(u32 fmt)
+{
+ switch (fmt) {
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_ARGB2101010:
+ case DRM_FORMAT_RGBX1010102:
+ case DRM_FORMAT_RGBA1010102:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_ABGR2101010:
+ case DRM_FORMAT_BGRX1010102:
+ case DRM_FORMAT_BGRA1010102:
+ return true;
+ }
+ return false;
+}
+
static const u32 mt8173_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
@@ -88,12 +104,18 @@ static const u32 mt8173_formats[] = {
static const u32 mt8195_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB2101010,
DRM_FORMAT_ARGB2101010,
DRM_FORMAT_BGRX,
DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRX1010102,
DRM_FORMAT_BGRA1010102,
DRM_FORMAT_ABGR,
DRM_FORMAT_XBGR,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_ABGR2101010,
+ DRM_FORMAT_RGBX1010102,
+ DRM_FORMAT_RGBA1010102,
DRM_FORMAT_RGB888,
DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
@@ -253,9 +275,7 @@ static void mtk_ovl_set_bit_depth(struct device *dev, int
idx, u32 format,
reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
- if (format == DRM_FORMAT_RGBA1010102 ||
- format == DRM_FORMAT_BGRA1010102 ||
- format == DRM_FORMAT_ARGB2101010)
+ if (is_10bit_rgb(format))
bit_depth = OVL_CON_CLRFMT_10_BIT;
reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
@@ -368,17 +388,23 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl
*ovl, unsigned int fmt)
return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
+ case DRM_FORMAT_RGBX1010102:
+ case DRM_FORMAT_RGBA1010102:
return OVL_CON_CLRFMT_ARGB;
case DRM_FORMAT_BGRX:
case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_BGRX1010102:
case DRM_FORMAT_BGRA1010102:
return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_ARGB2101010:
return OVL_CON_CLRFMT_RGBA;
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_ABGR2101010:
return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_UYVY:
return OVL_CON_CLRFMT_UYVY | OVL_CON_MTX_YUV_TO_RGB;
--
2.18.0
[PATCH v8 15/16] drm/mediatek: Support CRC in OVL
From: Hsiao Chien Sung
We choose OVL as the CRC generator from other hardware
components that are also capable of calculating CRCs,
since its frame done event triggers vblanks, it can be
used as a signal to know when is safe to retrieve CRC of
the frame.
Please note that position of the hardware component
that is chosen as CRC generator in the display path is
significant. For example, while OVL is the first module
in VDOSYS0, its CRC won't be affected by the modules
after it, which means effects applied by PQ, Gamma,
Dither or any other components after OVL won't be
calculated in CRC generation.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 5 +
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 5 +
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 209 ++--
3 files changed, 209 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index 17b036411292..07c3b5c5e14e 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -351,6 +351,11 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
.clk_enable = mtk_ovl_clk_enable,
.clk_disable = mtk_ovl_clk_disable,
.config = mtk_ovl_config,
+ .crc_cnt = mtk_ovl_crc_cnt,
+ .crc_entry = mtk_ovl_crc_entry,
+ .crc_read = mtk_ovl_crc_read,
+ .crc_start = mtk_ovl_crc_start,
+ .crc_stop = mtk_ovl_crc_stop,
.start = mtk_ovl_start,
.stop = mtk_ovl_stop,
.register_vblank_cb = mtk_ovl_register_vblank_cb,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 082ac18fe04a..a03d7a10847a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -105,6 +105,11 @@ void mtk_ovl_enable_vblank(struct device *dev);
void mtk_ovl_disable_vblank(struct device *dev);
const u32 *mtk_ovl_get_formats(struct device *dev);
size_t mtk_ovl_get_num_formats(struct device *dev);
+size_t mtk_ovl_crc_cnt(struct device *dev);
+u32 *mtk_ovl_crc_entry(struct device *dev);
+void mtk_ovl_crc_read(struct device *dev);
+void mtk_ovl_crc_start(struct device *dev);
+void mtk_ovl_crc_stop(struct device *dev);
void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index de1633988921..d77b25c528ea 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -24,12 +24,20 @@
#define OVL_FME_CPL_INTBIT(1)
#define DISP_REG_OVL_INTSTA0x0008
#define DISP_REG_OVL_EN0x000c
+#define OVL_EN BIT(0)
+#define OVL_OP_8BIT_MODE BIT(4)
+#define OVL_HG_FOVL_CK_ON BIT(8)
+#define OVL_HF_FOVL_CK_ON BIT(10)
+#define DISP_REG_OVL_TRIG 0x0010
+#define OVL_CRC_EN BIT(8)
+#define OVL_CRC_CLRBIT(9)
#define DISP_REG_OVL_RST 0x0014
#define DISP_REG_OVL_ROI_SIZE 0x0020
#define DISP_REG_OVL_DATAPATH_CON 0x0024
#define OVL_LAYER_SMI_ID_ENBIT(0)
#define OVL_BGCLR_SEL_IN BIT(2)
#define OVL_LAYER_AFBC_EN(n) BIT(4+n)
+#define OVL_OUTPUT_CLAMP BIT(26)
#define DISP_REG_OVL_ROI_BGCLR 0x0028
#define DISP_REG_OVL_SRC_CON 0x002c
#define DISP_REG_OVL_CON(n)(0x0030 + 0x20 * (n))
@@ -42,7 +50,26 @@
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
#define DISP_REG_OVL_ADDR_MT2701 0x0040
+#define DISP_REG_OVL_CRC 0x0270
+#define OVL_CRC_OUT_MASK GENMASK(30, 0)
#define DISP_REG_OVL_CLRFMT_EXT0x02D0
+#define DISP_REG_OVL_CLRFMT_EXT1 0x02D8
+#define OVL_CLRFMT_EXT1_CSC_EN(n) (1 << (((n) * 4) + 1))
+#define DISP_REG_OVL_Y2R_PARA_R0(n)(0x0134 + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_RMY (GENMASK(14, 0))
+#define DISP_REG_OVL_Y2R_PARA_G0(n)(0x013c + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_GMU (GENMASK(30, 16))
+#define DISP_REG_OVL_Y2R_PARA_B1(n)(0x0148 + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_BMV (GENMASK(14, 0))
+#define DISP_REG_OVL_Y2R_PARA_YUV_A_0(n) (0x014c + 0x28 * (n))
+#define OVL_Y2R_PARA_C_CF_YA
[PATCH v8 08/16] drm/mediatek: Support RGBA8888 and RGBX8888 in OVL on MT8195
From: Hsiao Chien Sung
Support RGBA and RGBX formats in OVL on MT8195.
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index d970cdce06bc..738244a6164e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -114,6 +114,8 @@ static const u32 mt8195_formats[] = {
DRM_FORMAT_XBGR,
DRM_FORMAT_XBGR2101010,
DRM_FORMAT_ABGR2101010,
+ DRM_FORMAT_RGBX,
+ DRM_FORMAT_RGBA,
DRM_FORMAT_RGBX1010102,
DRM_FORMAT_RGBA1010102,
DRM_FORMAT_RGB888,
--
2.18.0
[PATCH v8 00/16] Support IGT in display driver
From: Hsiao Chien Sung
Based-on: commit 1613e604df0c ("Linux 6.10-rc1")
This series adds support for running IGT (Intel GPU Tool) tests with
MediaTek display driver. The following changes will be applied:
1. Add a new API for creating GCE thread loop to retrieve CRCs
from the hardware component
2. Support hardware CRC calculation in both VDOSYS0 and VDOSYS1
3. Support alpha blending in both VDOSYS0 and VDOSYS1
Changes in v8:
- Start/Stop CRC CMDQ thread on when needed
- Squash and rearrange the commits
- Add more information to the commit message and comments
Changes in v7:
- Separate the patch into smaller ones
Changes in v6:
- Use drm_vblank_work to deffer the CRC work into bottom halves
- Separate the patches for "Premultiplied" and "None" alpha blending
Changes in v5:
- Add more descriptions to the codes
- Add DRM mode configs to the driver data
- Squash and rearrange the commits
Changes in v4:
- Separate the patch into smaller ones
- Change the title of some patches
- Revert the changes that are not related to the series
Changes in v3:
- Modify the dt-binding document of Mediatek OVL
- Set DRM mode configs accroding to the hardware capabilities
- Replace cmdq_pkt_jump_absolute() with cmdq_pkt_jump()
Changes in v2:
- Simplify CMDQ by adding commands that are currently used only
- Integrate CRC related codes into new APIs for Mixer and OVL to reuse
- Add CPU version CRC retrieval when CMDQ is disabled
Hsiao Chien Sung (16):
soc: mediatek: Disable 9-bit alpha in ETHDR
drm/mediatek: Add OVL compatible name for MT8195
drm/mediatek: Add missing plane settings when async update
drm/mediatek: Add DRM_MODE_ROTATE_0 to rotation property
drm/mediatek: Set DRM mode configs accordingly
drm/mediatek: Turn off the layers with zero width or height
drm/mediatek: Support more 10bit formats in OVL
drm/mediatek: Support RGBA and RGBX in OVL on MT8195
drm/mediatek: Support "None" blending in OVL
drm/mediatek: Support "None" blending in Mixer
drm/mediatek: Support "Pre-multiplied" blending in OVL
drm/mediatek: Support "Pre-multiplied" blending in Mixer
drm/mediatek: Support alpha blending in display driver
drm/mediatek: Support CRC in display driver
drm/mediatek: Support CRC in OVL
drm/mediatek: Support CRC in OVL adaptor
drivers/gpu/drm/mediatek/mtk_crtc.c | 280
drivers/gpu/drm/mediatek/mtk_crtc.h | 38 +++
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 10 +
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 11 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 10 +
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 316 --
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 37 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c| 24 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h| 4 +
drivers/gpu/drm/mediatek/mtk_ethdr.c | 106 +-
drivers/gpu/drm/mediatek/mtk_ethdr.h | 7 +
drivers/gpu/drm/mediatek/mtk_plane.c | 15 +-
drivers/soc/mediatek/mtk-mmsys.c | 1 +
13 files changed, 816 insertions(+), 43 deletions(-)
--
2.18.0
Re: [PATCH v2 5/7] drm/msm/adreno: Add A702 support
On 23.05.2024 2:14 PM, Connor Abbott wrote:
> On Fri, Feb 23, 2024 at 9:28 PM Konrad Dybcio
> wrote:
>>
>> The A702 is a weird mix of 600 and 700 series.. Perhaps even a
>> testing ground for some A7xx features with good ol' A6xx silicon.
>> It's basically A610 that's been beefed up with some new registers
>> and hw features (like APRIV!), that was then cut back in size,
>> memory bus and some other ways.
>>
>> Add support for it, tested with QCM2290 / RB1.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
[...]
>> +
>> + if (adreno_is_a702(gpu)) {
>> + gpu->ubwc_config.highest_bank_bit = 14;
>> + gpu->ubwc_config.min_acc_len = 1;
>> + gpu->ubwc_config.ubwc_mode = 2;
>
> I just noticed, but this is wrong. ubwc_mode is a 1 bit field and what
> this is actually doing is overwriting hbb_lo, making the highest bank
> bit 15 instead of 14.
You're right, this should be a 0. Thanks!
Konrad
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: > The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a > number of handheld gaming devices made by Anbernic. By consensus a > vendor prefix is not provided as the panel OEM is unknown. Where has this consensus been found? I had a look at the previous discussions, and I can't find any consensus being reached there. And for that kind of thing, having the ack or review of any of the DT maintainers would have been great. For this kind of cases, we usually use the device it's attached to as the vendor, so anbernic in this case. Can you send a followup patch? Maxime signature.asc Description: PGP signature
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On 06/06/2024 11:32, Maxime Ripard wrote: On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a number of handheld gaming devices made by Anbernic. By consensus a vendor prefix is not provided as the panel OEM is unknown. Where has this consensus been found? I had a look at the previous discussions, and I can't find any consensus being reached there. And for that kind of thing, having the ack or review of any of the DT maintainers would have been great. There was a consensus with Conor, this is why he acked v2, see https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ ``` I think if we genuinely do not know what the vendor is then we just don't have a prefix. ``` I agree with Conor so I applied the patchset after Connor reviewed it and the comment was fixed in v3: https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ For this kind of cases, we usually use the device it's attached to as the vendor, so anbernic in this case. Can you send a followup patch? Maxime Neil
Re: [PATCH] drm/mediatek: Don't print error if EDEFER_PROBE returned on component_add
Il 05/06/24 18:50, Nícolas F. R. A. Prado ha scritto:
Use dev_err_probe() in the component_add() error path to prevent
printing an error when the probe is deferred. This was observed on
mt8195 with the disp-rdma driver:
mediatek-disp-rdma 1c002000.rdma: Failed to add component: -517
But the same pattern is used across many other drivers, so update them
all.
While I agree with this commit, it makes little sense to change only one print.
Can you take care of converting all of the dev_err() prints to dev_err_probe()?
P.S.: Also please do it on top of my OF graph series [1]
P.P.S.: It's -EPROBE_DEFER, not EDEFER_PROBE :-P
Thanks,
Angelo
[1]:
https://lore.kernel.org/all/20240516081104.83458-1-angelogioacchino.delre...@collabora.com/
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_color.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 2 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 2 +-
drivers/gpu/drm/mediatek/mtk_ethdr.c| 2 +-
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 3ce8f32b06d5..892dc40458fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -197,7 +197,7 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
ret = component_add(dev, &mtk_disp_aal_component_ops);
if (ret)
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index df35e90dd25f..fc273ebdbcd2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -182,7 +182,7 @@ static int mtk_disp_ccorr_probe(struct platform_device
*pdev)
ret = component_add(dev, &mtk_disp_ccorr_component_ops);
if (ret)
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 7f0085be5671..c2c374e9a8e3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -126,7 +126,7 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
ret = component_add(dev, &mtk_disp_color_component_ops);
if (ret)
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index ca8d1f3aca03..ec926b32c34d 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -287,7 +287,7 @@ static int mtk_disp_gamma_probe(struct platform_device
*pdev)
ret = component_add(dev, &mtk_disp_gamma_component_ops);
if (ret)
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index 77c057e0e671..2f6a605542d5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -354,7 +354,7 @@ static int mtk_disp_merge_probe(struct platform_device
*pdev)
ret = component_add(dev, &mtk_disp_merge_component_ops);
if (ret != 0)
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index b552a02d7eae..ffdc9ca5b6f5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -555,7 +555,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
ret = component_add(dev, &mtk_disp_ovl_component_ops);
if (ret) {
pm_runtime_disable(dev);
- dev_err(dev, "Failed to add component: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to add component\n");
}
return ret;
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 02dd7dcdfedb..c9d6f2b39e92 100644
--- a/drivers/gpu/drm/media
[PATCH] drm/amd/display: Fix dml_print_mode_support() for USRRetrainingSupport
The address of a struct field is usually not NULL, making this test
always truthy. Test the boolean value instead.
Fixes the following Coccinelle/coccicheck error reported by
test_addr.cocci:
ERROR: test of a variable/field address
Compile-tested only.
Signed-off-by: Thorsten Blum
---
drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
index c247aee89caf..a98ec059725a 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_util.c
@@ -404,7 +404,7 @@ void dml_print_mode_support(struct display_mode_lib_st
*mode_lib, dml_uint_t j)
dml_print("DML: MODE SUPPORT: Host VM or Immediate Flip Supported
: %s\n", ((mode_lib->ms.cache_display_cfg.plane.HostVMEnable == false &&
!mode_lib->scratch.dml_core_mode_support_locals.ImmediateFlipRequiredFinal) ||
mode_lib->ms.support.ImmediateFlipSupportedForState[j]) ? "Supported" : "NOT
Supported");
dml_print("DML: MODE SUPPORT: dram clock change support
: %s\n",
mode_lib->scratch.dml_core_mode_support_locals.dram_clock_change_support ==
true ? "Supported" : "NOT Supported");
dml_print("DML: MODE SUPPORT: f_clock change support
: %s\n",
mode_lib->scratch.dml_core_mode_support_locals.f_clock_change_support == true ?
"Supported" : "NOT Supported");
- dml_print("DML: MODE SUPPORT: USR Retraining Support
: %s\n", (!mode_lib->ms.policy.USRRetrainingRequiredFinal ||
&mode_lib->ms.support.USRRetrainingSupport[j]) ? "Supported" : "NOT Supported");
+ dml_print("DML: MODE SUPPORT: USR Retraining Support
: %s\n", (!mode_lib->ms.policy.USRRetrainingRequiredFinal ||
mode_lib->ms.support.USRRetrainingSupport[j]) ? "Supported" : "NOT Supported");
dml_print("DML: MODE SUPPORT:
===\n");
}
--
2.39.2
[PATCH] drm/amd/display: clean up some inconsistent indenting
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c:529
dcn32_auto_dpm_test_log() warn: inconsistent indenting.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9294
Signed-off-by: Jiapeng Chong
---
.../display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c | 36 +--
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
index ff5fdc7b1198..7300e793d506 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c
@@ -525,25 +525,23 @@ static void dcn32_auto_dpm_test_log(
mall_ss_size_bytes = context->bw_ctx.bw.dcn.mall_ss_size_bytes;
-dispclk_khz_reg= REG_READ(CLK1_CLK0_CURRENT_CNT); // DISPCLK
-dppclk_khz_reg = REG_READ(CLK1_CLK1_CURRENT_CNT); // DPPCLK
-dprefclk_khz_reg = REG_READ(CLK1_CLK2_CURRENT_CNT); // DPREFCLK
-dcfclk_khz_reg = REG_READ(CLK1_CLK3_CURRENT_CNT); // DCFCLK
-dtbclk_khz_reg = REG_READ(CLK1_CLK4_CURRENT_CNT); // DTBCLK
-fclk_khz_reg = REG_READ(CLK4_CLK0_CURRENT_CNT); // FCLK
-
-// Overrides for these clocks in case there is no p_state change support
-dramclk_khz_override = new_clocks->dramclk_khz;
-fclk_khz_override = new_clocks->fclk_khz;
-
-num_fclk_levels =
clk_mgr->base.bw_params->clk_table.num_entries_per_clk.num_fclk_levels - 1;
-
-if (!new_clocks->p_state_change_support) {
- dramclk_khz_override = clk_mgr->base.bw_params->max_memclk_mhz *
1000;
-}
-if (!new_clocks->fclk_p_state_change_support) {
- fclk_khz_override =
clk_mgr->base.bw_params->clk_table.entries[num_fclk_levels].fclk_mhz * 1000;
-}
+ dispclk_khz_reg= REG_READ(CLK1_CLK0_CURRENT_CNT); // DISPCLK
+ dppclk_khz_reg = REG_READ(CLK1_CLK1_CURRENT_CNT); // DPPCLK
+ dprefclk_khz_reg = REG_READ(CLK1_CLK2_CURRENT_CNT); // DPREFCLK
+ dcfclk_khz_reg = REG_READ(CLK1_CLK3_CURRENT_CNT); // DCFCLK
+ dtbclk_khz_reg = REG_READ(CLK1_CLK4_CURRENT_CNT); // DTBCLK
+ fclk_khz_reg = REG_READ(CLK4_CLK0_CURRENT_CNT); // FCLK
+
+ // Overrides for these clocks in case there is no p_state change support
+ dramclk_khz_override = new_clocks->dramclk_khz;
+ fclk_khz_override = new_clocks->fclk_khz;
+
+ num_fclk_levels =
clk_mgr->base.bw_params->clk_table.num_entries_per_clk.num_fclk_levels - 1;
+
+ if (!new_clocks->p_state_change_support)
+ dramclk_khz_override = clk_mgr->base.bw_params->max_memclk_mhz
* 1000;
+ if (!new_clocks->fclk_p_state_change_support)
+ fclk_khz_override =
clk_mgr->base.bw_params->clk_table.entries[num_fclk_levels].fclk_mhz * 1000;
// IMPORTANT: When adding more clocks to these logs, do NOT
put a newline
--
2.20.1.7.g153144c
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Thu, 6 Jun 2024, at 9:32 PM, Maxime Ripard wrote: Hi Maxime, thanks for reviewing. > Where has this consensus been found? As Neil notes Conor suggested it [1], and we did consider Hironori's suggestion [2] of using anbernic as the vendor prefix, although my (not strong) feeling at the time was because Anbernic is not the panel vendor, just integrating an unknown OEM's panel into their devices, so at the time I fit was not quite accurate to say Anbernic was the vendor. Some discussion was also had on IRC at #linux-sunxi [3]. Admittedly not a *broad* consensus, but all offered opinions were taken and the patch was accepted subsequently. > For this kind of cases, we usually use the device it's attached to as > the vendor, so anbernic in this case. Can you send a followup patch? Thanks for the clarification, I was not aware of this. Happy to prepare one but will perhaps wait to see if there are any other comments. > Maxime Regards, Ryan [1] https://lore.kernel.org/dri-devel/20240525-velvet-citable-a45dd06847a7@spud/ [2] https://lore.kernel.org/dri-devel/cag40kxgew4ayhk3p_dixkrdesgt0pltmfpyccctbvgus2nm...@mail.gmail.com/ [3] https://oftc.irclog.whitequark.org/linux-sunxi/2024-05-27#332264
Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver
On 6/5/24 5:48 PM, Heiko Stübner wrote:
> Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
>> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
>> the following features, among others:
>>
>> * Fixed Rate Link (FRL)
>> * 4K@120Hz and 8K@60Hz video modes
>> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
>> Cinema VRR
>> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
>> * SCDC I2C DDC access
>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>> * Multi-stream audio
>> * Enhanced Audio Return Channel (EARC)
>>
>> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
>> without audio, CEC or any HDMI 2.1 specific features.
>>
>> Co-developed-by: Algea Cao
>> Signed-off-by: Algea Cao
>> Signed-off-by: Cristian Ciocaltea
>> ---
>> drivers/gpu/drm/bridge/synopsys/Makefile | 2 +-
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831
>> +++
>> include/drm/bridge/dw_hdmi.h | 8 +
>> 4 files changed, 1627 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
>> b/drivers/gpu/drm/bridge/synopsys/Makefile
>> index ce715562e9e5..8354e4879f70 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
>> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
>
>> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
>> + unsigned char *buf, unsigned int length)
>> +{
>> +struct dw_hdmi_i2c *i2c = hdmi->i2c;
>> +int stat;
>> +
>> +if (!i2c->is_regaddr) {
>> +dev_dbg(hdmi->dev, "set read register address to 0\n");
>> +i2c->slave_reg = 0x00;
>> +i2c->is_regaddr = true;
>> +}
>> +
>> +while (length--) {
>> +reinit_completion(&i2c->cmp);
>> +
>> +dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
>> + I2CM_INTERFACE_CONTROL0);
>> +
>> +dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>> + I2CM_INTERFACE_CONTROL0);
>
> Somehow the segment handling is present in the rest of the i2c code here, but
> not the actual handling for reads.
>
> The vendor-kernel does:
>
> - dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> - I2CM_INTERFACE_CONTROL0);
> + if (i2c->is_segment)
> + dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
> + I2CM_INTERFACE_CONTROL0);
> + else
> + dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> + I2CM_INTERFACE_CONTROL0);
Hmm, for some reason this is not present in the stable-5.10-rock5 branch
I've been using as an implementation reference:
https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760
Is there an updated fork?
> Without this change, connecting to a DVI display does not work, and
> reading the EDID ends in the "i2c read error" below.
>
> Adding the segment handling as above makes the DVI connection
> work (as it does in the vendor-kernel).
>
> So it would be nice if you could maybe incorporate this in the next version?
Sure, thanks for pointing this out!
Cristian
Re: [PATCH 2/6] drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
Hi Marek, Am Mittwoch, 5. Juni 2024, 18:25:13 CEST schrieb Marek Vasut: > On 6/5/24 12:52 PM, Alexander Stein wrote: > > Hi Marek, > > Hi, > > [snip] > > Ah, right. That seems simple. But I noticed another thing: > > The TC9595 PLL is configured to 14733 while the lcdif configures > > the display clock to 147333000, the value actually stored in > > adjusted_mode.clock. I do not know if this small difference can be > > neglected. > > Good point, please see (*) below. > > >>> No, sorry. I'm not sure about those VFIFO overruns/underruns you mentioned > >>> in the commit message. Does this maybe only apply to DPI input? > >> > >> No, this actually happens with DSI input in both DPI and (e)DP output > >> modes, it is only really well visible in some resolutions it seems. > > > > Ah, i see. > > > >>> At least for 148.5MHz (1080p) apparently it is not possible to that > >>> exact clock anyway. > >> > >> Right, which sucks, but the TC9595 datasheet explicitly states that the > >> FRMSYNC mode should always be enabled (and is apparently force-enabled > >> on newer bridge chips with no option to disable it) unless the Pixel > >> clock are sourced from DSI clock (which is never the case with this > >> driver). That's what the [1] patch does. > >> > >> But messing with the HFP isn't really working for all resolutions, so > >> this patch instead adjusts the input pixel clock to fit the Pixel PLL > >> limits, which avoids the VFIFO issues altogether. And that makes the > >> FRMSYNC mode work for all kinds of resolutions. > > > > I can't tell if VFIFO issue arise here, because I'm currently trying to > > get a reliable and stable output for DP. > > What kind of problem do you observe on your side exactly ? (I think the > answer to this is at the end). I've spent quite a while on this, so > maybe I ran into that before. DP output either works as expected or not at all. The monitor stays in sleep mode then. I only notice that VFUEN is not cleared in this case. > > The documentation is somewhat > > limited, but FRAMSYNC seems almost necessary in any case, unless you > > utilize DSI bus 100% for this device to get the correct display timings > > using DSI packets. > > That's not quite what it says. > > I don't know what kind of datasheet you have and for which exact bridge, > but look at Section 4, block diagram. I have the datasheet 0.1 and 1.1 for TC9595 available. Also the TC358767A_867XBG v37 spreadsheet. > The FRMSYNC operates on the LS_Clk domain side, right of V_FiFo . It > reads lines from the VFIFO and sends them out of the DP as DP packets. > As long as the input into the VFIFO delivers the lines such that the > VFIFO does not overflow or underflow, everything is fine. > > The DSI side starts to write line into the VFIFO on HSS (Hsync start), > see "DSI Packets for Video Transmission". HSE (Hsync end) packet is > ignored, see "Video Transmission" . Two consecutive HSS must be sent > with the same time between the two as time between two lines configured > into FRMSYNC timing generator. > > However, I _think_ (*) if the time between two HSS is slightly longer > than what the FRMSYNC expects, the FRMSYNC stretches the HFP slightly > for each frame and we won't run into any problems (see 4.12 Clocks and > search for keyword "approximated", they talk about close approximation > there). Which datasheet do you have available? It might just be a typo, but the Clocks section is 4.13 in my case. > >> You might be wondering why not source pixel clock from DSI HS clock and > >> disable FRMSYNC. For one thing, this would limit the ability to pick > >> faster DSI HS clock and make good use of the DSI burst mode (the DSI > >> link can go into LP state after transmitting entire line of pixel data > >> for longer with faster DSI HS clock). The other thing is, to drive the > >> Pixel PLL (not to be confused with pixel clock) from DSI HS clock, the > >> DSI HS clock have to be set to specific clock rates (13*4*7=364 MHz and > >> 13*4*9=468 MHz), which is really limiting. > > btw. those 13 MHz match one of RefClk input options, the *4 is from > HSBY4 divider and 7 and 9 come from MODE[1] strap option dividers. > > > This is not mentioned in the datasheet at all, but just in a small note > > in the calculation sheet, without any description. On a different platform > > DSI HS clock running at 445.5MHz seems also possible, even if unsupported. > > You can use arbitrary DSI HS clock as long as you don't derive RefClk > from DSI HS clock (and RefClk feeds Pixel PLL). Yes, that's what I would expect as well, but that other platform was configured to derive RefClk from DSI/4. > > BTW: Which platform are you testing on? > > MX8MP with LCDIFv3 -> DSIM -> TC9595 -> DP output. > > The TC9595 is 2nd generation (automotive?) replacement for TC358767 (1st > generation replacement is TC358867) . > >>> > >>> Same here. But fail to get output on a DP monitor if I'm running fro
Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver
Am Donnerstag, 6. Juni 2024, 11:53:23 CEST schrieb Cristian Ciocaltea:
> On 6/5/24 5:48 PM, Heiko Stübner wrote:
> > Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
> >> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
> >> the following features, among others:
> >>
> >> * Fixed Rate Link (FRL)
> >> * 4K@120Hz and 8K@60Hz video modes
> >> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
> >> Cinema VRR
> >> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
> >> * SCDC I2C DDC access
> >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> >> * Multi-stream audio
> >> * Enhanced Audio Return Channel (EARC)
> >>
> >> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
> >> without audio, CEC or any HDMI 2.1 specific features.
> >>
> >> Co-developed-by: Algea Cao
> >> Signed-off-by: Algea Cao
> >> Signed-off-by: Cristian Ciocaltea
> >> ---
> >> drivers/gpu/drm/bridge/synopsys/Makefile | 2 +-
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787
> >> +
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831
> >> +++
> >> include/drm/bridge/dw_hdmi.h | 8 +
> >> 4 files changed, 1627 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
> >> b/drivers/gpu/drm/bridge/synopsys/Makefile
> >> index ce715562e9e5..8354e4879f70 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
> >> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
> >
> >> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
> >> + unsigned char *buf, unsigned int length)
> >> +{
> >> + struct dw_hdmi_i2c *i2c = hdmi->i2c;
> >> + int stat;
> >> +
> >> + if (!i2c->is_regaddr) {
> >> + dev_dbg(hdmi->dev, "set read register address to 0\n");
> >> + i2c->slave_reg = 0x00;
> >> + i2c->is_regaddr = true;
> >> + }
> >> +
> >> + while (length--) {
> >> + reinit_completion(&i2c->cmp);
> >> +
> >> + dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
> >> + I2CM_INTERFACE_CONTROL0);
> >> +
> >> + dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> >> + I2CM_INTERFACE_CONTROL0);
> >
> > Somehow the segment handling is present in the rest of the i2c code here,
> > but
> > not the actual handling for reads.
> >
> > The vendor-kernel does:
> >
> > - dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> > - I2CM_INTERFACE_CONTROL0);
> > + if (i2c->is_segment)
> > + dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
> > + I2CM_INTERFACE_CONTROL0);
> > + else
> > + dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> > + I2CM_INTERFACE_CONTROL0);
>
> Hmm, for some reason this is not present in the stable-5.10-rock5 branch
> I've been using as an implementation reference:
>
> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760
>
> Is there an updated fork?
I think the radxa code-base is quite old in terms of sdk-version it's based on.
Grabbing a 6.1 branch from Radxa shows it in:
https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L995
> > Without this change, connecting to a DVI display does not work, and
> > reading the EDID ends in the "i2c read error" below.
> >
> > Adding the segment handling as above makes the DVI connection
> > work (as it does in the vendor-kernel).
> >
> > So it would be nice if you could maybe incorporate this in the next version?
>
> Sure, thanks for pointing this out!
>
> Cristian
>
[PULL] drm-misc-next
Hi! Here's this week drm-misc-next PR. It has the fix for the v3d build issue, so it should be safe to merge it, together with last week's PR content. Thanks! Maxime drm-misc-next-2024-06-06: drm-misc-next for 6.10: UAPI Changes: Cross-subsystem Changes: - dma-buf: Warn when reserving 0 fence slots, internal API enhancements for heaps Core Changes: Driver Changes: - atmel-hlcdc: Support XLCDC in sam9x7 - msm: Validate registers XML description against schema in CI - v3d: Fix build warning - bridges: - analogix_dp: Various improvements - panels: - New panel: WL-355608-A8 The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0: Linux 6.10-rc1 (2024-05-26 15:20:12 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/misc/kernel.git tags/drm-misc-next-2024-06-06 for you to fetch changes up to 310ec03841a36e3f45fb528f0dfdfe5b9e84b037: dma-buf: align fd_flags and heap_flags with dma_heap_allocation_data (2024-06-05 14:52:15 +0530) drm-misc-next for 6.10: UAPI Changes: Cross-subsystem Changes: - dma-buf: Warn when reserving 0 fence slots, internal API enhancements for heaps Core Changes: Driver Changes: - atmel-hlcdc: Support XLCDC in sam9x7 - msm: Validate registers XML description against schema in CI - v3d: Fix build warning - bridges: - analogix_dp: Various improvements - panels: - New panel: WL-355608-A8 Abhinav Kumar (1): drm: ci: fix the xfails for apq8016 Alex Bee (2): dt-bindings: display: rockchip,dw-mipi-dsi: Document RK3128 DSI drm/rockchip: dsi: Add support for RK3128 Amjad Ouled-Ameur (1): drm/arm/komeda: update DMA mask to 40 bits Anatoliy Klymenko (2): drm: xlnx: zynqmp_dpsub: Fix few function comments drm: xlnx: zynqmp_dpsub: Fix compilation error Andy Yan (1): drm/rockchip: vop2: Fix the port mux of VP2 Aradhya Bhatia (6): dt-bindings: vendor-prefixes: Add microtips dt-bindings: vendor-prefixes: Add lincolntech dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel drm/panel: simple: Add Microtips Technology 13-101HIEBCAF0-C panel drm/panel: simple: Add Microtips Technology MF-103HIEB0GA0 panel Barry Song (1): dma-buf: align fd_flags and heap_flags with dma_heap_allocation_data Chaitanya Kumar Borah (1): nouveau: Add missing break statement Christian König (1): dma-buf: add a warning when drv try to reserve 0 fence slots Christophe JAILLET (1): dma-buf/fence-array: Add flex array to struct dma_fence_array Colin Ian King (1): drm/gma500: Fix spelling mistake "patter" -> "pattern" Cong Yang (6): dt-bindings: display: panel: Add himax hx83102 panel bindings drm/panel: himax-hx83102: Break out as separate driver dt-bindings: display: panel: Add compatible for BOE nv110wum-l60 drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel dt-bindings: display: panel: Add compatible for IVO t109nw41 drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel Dmitry Baryshkov (8): drm/panel: lg-sw43408: add missing error handling drm/mipi-dsi: wrap more functions for streamline handling drm/panel: boe-tv101wum-nl6: use wrapped MIPI DCS functions drm/panel: ilitek-ili9882t: use wrapped MIPI DCS functions drm/panel: innolux-p079zca: use mipi_dsi_dcs_nop_multi() drm/panel: novatek-nt36672e: use wrapped MIPI DCS functions drm/panel: lg-sw43408: use new streamlined MIPI DSI API drm/ci: validate drm/msm XML register files against schema Douglas Anderson (44): drm/panel-edp: Add ID for KD KD116N09-30NH-A016 drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels drm/panel: ili9882t: Don't use a table for initting panels drm/panel: innolux-p079zca: Don't use a table for initting panels drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on() better drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before regulators drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare() drm/panel: ilitek-ili9882t: If prepare fails, disable GPIO before regulators drm/panel: ilitek-ili9882t: Check for errors on the NOP in prepare() drm/panel: hima
[PATCH] drm/msm/a6xx: Fix A702 UBWC mode
UBWC_MODE is a one-bit-wide field, so a value of 2 is obviously bogus.
Replace it with the correct value (0).
Fixes: 18397519cb62 ("drm/msm/adreno: Add A702 support")
Reported-by: Connor Abbott
Closes:
https://lore.kernel.org/linux-arm-msm/CACu1E7FTN=kwaDJMNiTmFspALzj2+Q-nvsN5ugi=vz4rdug...@mail.gmail.com/
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..5383aff84830 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1409,7 +1409,7 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
if (adreno_is_a702(gpu)) {
gpu->ubwc_config.highest_bank_bit = 14;
gpu->ubwc_config.min_acc_len = 1;
- gpu->ubwc_config.ubwc_mode = 2;
+ gpu->ubwc_config.ubwc_mode = 0;
}
}
---
base-commit: ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f
change-id: 20240606-topic-a702_ubwcmode-dcc5fde0f330
Best regards,
--
Konrad Dybcio
Re: [PATCH v5 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Il 06/06/24 08:46, Chen-Yu Tsai ha scritto:
On Wed, Jun 5, 2024 at 7:15 PM AngeloGioacchino Del Regno
wrote:
Il 05/06/24 03:38, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-05-21 at 09:57 +0200, AngeloGioacchino Del Regno wrote:
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint defines the starting point for one of the (currently three)
possible hardware paths.
Reviewed-by: Rob Herring (Arm)
Reviewed-by: Alexandre Mergnat
Tested-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..0ef67ca4122b 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -93,6 +93,34 @@ properties:
'#reset-cells':
const: 1
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Output port node. This port connects the MMSYS/VDOSYS output to
+ the first component of one display pipeline, for example one of
+ the available OVL or RDMA blocks.
+ Some MediaTek SoCs support multiple display outputs per MMSYS.
This patch looks good to me. Just want to share another information for you.
Here is an example that mmsys/vdosys could point to the display interface node.
vdosys0: syscon@1c01a000 {
mmsys-display-interface = <&dsi0>, <&dsi1>, <&dp_intf0>;
};
vdosys1: syscon@1c10 {
mmsys-display-interface = <&dp_intf1>;
};
There is no conflict that mmsys/vdosys point to first component of one display
pipeline or point to display interface.
Both could co-exist.
Hey CK,
yes, this could be an alternative to the OF graphs, and I'm sure that it'd work,
even though this kind of solution would still require partial hardcoding of the
display paths up until mmsys-display-interface (so, up until DSI0, or DSI1,
etc).
I think you might be misunderstanding CK's proposal? He's simply saying that
instead of pointing to the start of the pipeline, point to the end instead.
You can still use the OF graph and work backwards from the output.
Oh, well, if I'm misunderstanding, sorry about that!
Though, OF Graphs are describing a "sequence of stuff" (sorry for the suboptimal
wording) and, well, the data goes from A to C with B in the middle, so the graph
starts at A, goes to B, then goes to C.
Starting from A, going to C, then backwards to B would be actually wrong, as
that
appears to describe that the pipeline goes A->C->B instead of A->B->C.
The problem with a solution like this is that, well, even though it would work,
even if we ignore the suboptimal partial hardcoding, OF graphs are something
generic, while the mmsys-display-interface would be a MediaTek specific/custom
property.
In the end, reusing generic kernel apis/interfaces/etc is always preferred
compared to custom solutions, especially in this case, in which the generic
stuff is on-par (or actually, depending purely on personal opinions, superior).
Here you are mixing hardware descriptions and kernel implementation details.
Not really. I'm saying that OF Graph would be preferred compared to a custom
propety, when they both do the same.
But again, I might have misunderstood what CK was trying to say, so just leave
it.
I think this goes back to whether the mmsys/vdosys is actually part of the
graph or not. It certainly controls the muxes within the graph. But that
doesn't mean it has to be within the graph itself. It can just have pointers
to entry points of the graph (for which you would have a couple lines of
custom code [1]). If the data doesn't flow through the mmsys/vdosys, then
^^^ [1] is a link I think? You missed it! :-)
I would argue that it is not part of the graph.
It's part of the graph, because it is setting up the pipeline - and it's doing
that
in hardware, by doing the muxing as you said.
I could even go on arguing that the data does actually pass through that, but I
don't want to start any big deal around that, so I won't.
I would also argue that the data path should be fully described in the
device tree, not hardcoding paths based on board usage.
Yes, that's what I also said (perhaps I should've been clearer) since the very
beginning, and it's exactly what made me put effort in making this series, so
we are totally agreeing on this point.
Cheers,
Angelo
The latter is
a policy / design decision, not a hardware capability.
ChenYu
As for the two to co-exist, I'm not sure that this is actually needed,
Re: [PATCH] arm/komeda: Compile DEFINE_SHOW_ATTRIBUTE() only when CONFIG_DEBUG_FS is enabled
On Thu, Jun 06, 2024 at 11:20:58AM +0300, Jani Nikula wrote:
> On Thu, 06 Jun 2024, pengfuyuan wrote:
> > We do not call komeda_debugfs_init() and the debugfs core function
> > declaration if CONFIG_DEBUG_FS is not defined, but we should not
> > compile it either because the debugfs core function declaration is
> > not included.
> >
> > Reported-by: k2ci
Can we see what the bot reported?
> > Signed-off-by: pengfuyuan
>
> An interesting alternative might actually be to remove *all* the
> CONFIG_DEBUG_FS conditional compilation from the file. Since the debugfs
> functions have no-op stubs for CONFIG_DEBUG_FS=n, the compiler will
> optimize the rest away, because they're no longer referenced. (For the
> same reason, I don't think this patch has an impact for code size.)
>
> The upside for removing conditional compilation is that you'll actually
> do build testing for both CONFIG_DEBUG_FS config values. Assuming most
> developers have it enabled, there's not a lot of testing going on for
> CONFIG_DEBUG_FS=n, and you might introduce build failures with the
> conditional compilation.
>
> Of course, up to Liviu to decide.
Yeah, I quite like the idea of removing the conditional compilation from
the file entirely.
Pengfuyuan, do you mind sending a new patch removing all the CONFIG_DEBUG_FS
from the file, rather than moving things around?
Best regards,
Liviu
>
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index 14ee79becacb..7ada8e6f407c 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -21,6 +21,7 @@
> >
> > #include "komeda_dev.h"
> >
> > +#ifdef CONFIG_DEBUG_FS
> > static int komeda_register_show(struct seq_file *sf, void *x)
> > {
> > struct komeda_dev *mdev = sf->private;
> > @@ -43,7 +44,6 @@ static int komeda_register_show(struct seq_file *sf, void
> > *x)
> >
> > DEFINE_SHOW_ATTRIBUTE(komeda_register);
> >
> > -#ifdef CONFIG_DEBUG_FS
> > static void komeda_debugfs_init(struct komeda_dev *mdev)
> > {
> > if (!debugfs_initialized())
>
> --
> Jani Nikula, Intel
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Thu, Jun 06, 2024 at 11:37:31AM GMT, Neil Armstrong wrote: > On 06/06/2024 11:32, Maxime Ripard wrote: > > On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: > > > The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a > > > number of handheld gaming devices made by Anbernic. By consensus a > > > vendor prefix is not provided as the panel OEM is unknown. > > > > Where has this consensus been found? > > > > I had a look at the previous discussions, and I can't find any consensus > > being reached there. And for that kind of thing, having the ack or > > review of any of the DT maintainers would have been great. > > There was a consensus with Conor, this is why he acked v2, see > https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ It's probably a matter of semantics here, but if it's with only one person, it's not a consensus but an agreement. > ``` > I think if we genuinely do not know what the vendor is then we just > don't have a prefix. > ``` And even then, I don't interpret Conor's statement as a formal agreement but rather an acknowledgment of the issue. > I agree with Conor so I applied the patchset after Connor reviewed it and the > comment was fixed in v3: > https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ Yeah, I know. Still, it's a major deviation to what we've always been doing, getting the DT maintainers voice on that would have been a good idea. Maxime signature.asc Description: PGP signature
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Thu, Jun 06, 2024 at 09:48:54PM GMT, Ryan Walklin wrote: > On Thu, 6 Jun 2024, at 9:32 PM, Maxime Ripard wrote: > Hi Maxime, thanks for reviewing. > > > Where has this consensus been found? > > As Neil notes Conor suggested it [1], and we did consider Hironori's > suggestion [2] of using anbernic as the vendor prefix, although my > (not strong) feeling at the time was because Anbernic is not the panel > vendor, just integrating an unknown OEM's panel into their devices, so > at the time I fit was not quite accurate to say Anbernic was the > vendor. > > Some discussion was also had on IRC at #linux-sunxi [3]. Admittedly > not a *broad* consensus, but all offered opinions were taken and the > patch was accepted subsequently. Respectfully, #linux-sunxi isn't the persons you should be discussing this with. Maxime signature.asc Description: PGP signature
Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver
On 6/6/24 1:16 PM, Heiko Stübner wrote:
> Am Donnerstag, 6. Juni 2024, 11:53:23 CEST schrieb Cristian Ciocaltea:
>> On 6/5/24 5:48 PM, Heiko Stübner wrote:
>>> Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
the following features, among others:
* Fixed Rate Link (FRL)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
Cinema VRR
* Fast Vactive (FVA), aka Quick Frame Transport (QFT)
* SCDC I2C DDC access
* TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
* YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
* Multi-stream audio
* Enhanced Audio Return Channel (EARC)
Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any HDMI 2.1 specific features.
Co-developed-by: Algea Cao
Signed-off-by: Algea Cao
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/bridge/synopsys/Makefile | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787
+
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831
+++
include/drm/bridge/dw_hdmi.h | 8 +
4 files changed, 1627 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index ce715562e9e5..8354e4879f70 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
>>>
+static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
+ unsigned char *buf, unsigned int length)
+{
+ struct dw_hdmi_i2c *i2c = hdmi->i2c;
+ int stat;
+
+ if (!i2c->is_regaddr) {
+ dev_dbg(hdmi->dev, "set read register address to 0\n");
+ i2c->slave_reg = 0x00;
+ i2c->is_regaddr = true;
+ }
+
+ while (length--) {
+ reinit_completion(&i2c->cmp);
+
+ dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
+ I2CM_INTERFACE_CONTROL0);
+
+ dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
+ I2CM_INTERFACE_CONTROL0);
>>>
>>> Somehow the segment handling is present in the rest of the i2c code here,
>>> but
>>> not the actual handling for reads.
>>>
>>> The vendor-kernel does:
>>>
>>> - dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>>> - I2CM_INTERFACE_CONTROL0);
>>> + if (i2c->is_segment)
>>> + dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
>>> + I2CM_INTERFACE_CONTROL0);
>>> + else
>>> + dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>>> + I2CM_INTERFACE_CONTROL0);
>>
>> Hmm, for some reason this is not present in the stable-5.10-rock5 branch
>> I've been using as an implementation reference:
>>
>> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760
>>
>> Is there an updated fork?
>
> I think the radxa code-base is quite old in terms of sdk-version it's based
> on.
> Grabbing a 6.1 branch from Radxa shows it in:
> https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L995
Indeed, I should have switched to using this one as it seems to include
quite a few potentially interesting updates (will check in detail for v2).
For now, we miss cdc0984c90dc ("drm/bridge: synopsys: dw-hdmi-qp: Support
read ext block edid"), which provides an additional change:
@@ -1086,7 +1090,7 @@ static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
i2c->is_segment = true;
hdmi_modb(hdmi, DDC_SEGMENT_ADDR, I2CM_SEG_ADDR,
I2CM_INTERFACE_CONTROL1);
- hdmi_modb(hdmi, *msgs[i].buf, I2CM_SEG_PTR,
+ hdmi_modb(hdmi, *msgs[i].buf << 7, I2CM_SEG_PTR,
I2CM_INTERFACE_CONTROL1);
} else {
if (msgs[i].flags & I2C_M_RD)
Will try to grab some more displays to improve testing on my end.
Thanks,
Cristian
Re: [PATCH v13 5/9] drm/dp: Add refresh rate divider to struct representing AS SDP
On Wed, 05 Jun 2024, Mitul Golani wrote:
> Add target_rr_divider to structure representing AS SDP.
> It is valid only in FAVT mode, sink device ignores the bit in AVT
> mode.
>
> --v2:
> - Update commit header and send patch to dri-devel.
>
> Signed-off-by: Mitul Golani
> Reviewed-by: Arun R Murthy
Maxime, Maarten, Thomas, ack for merging this via drm-intel-next?
BR,
Jani.
> ---
> include/drm/display/drm_dp_helper.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 8defcc399f42..ea03e1dd26ba 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -122,6 +122,7 @@ struct drm_dp_as_sdp {
> int target_rr;
> int duration_incr_ms;
> int duration_decr_ms;
> + bool target_rr_divider;
> enum operation_mode mode;
> };
--
Jani Nikula, Intel
Re: [PATCH v12 12/13] media: imagination: Round to closest multiple for cropping region
Hey,
On 04.06.2024 16:23, Devarsh Thakkar wrote:
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest values (high and low) are possible to raise the probability of
cropping rectangle falling inside the bound region.
This complies with the VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl
description as documented in v4l uapi [1] which specifies that driver
should choose crop rectangle as close as possible if no flags are passed by
user-space, as quoted below :
"``0`` - The driver can adjust the rectangle size freely and shall choose a
crop/compose rectangle as close as possible to the requested
one."
Link:
https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst
[1]
Signed-off-by: Devarsh Thakkar
Acked-by: Sebastian Fricke
Can, whoever picks up the math changes, pick up this change as well?
I will send 1-6 via the media subsystem.
Regards,
Sebastian
---
V12: No change
V11: No change
V10: No change
V9: No change
V8: Update commit message with specification reference
V1->V7 (No change, patch introduced in V7)
---
drivers/media/platform/imagination/e5010-jpeg-enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c
b/drivers/media/platform/imagination/e5010-jpeg-enc.c
index e701d573a26a..d65646f0c38c 100644
--- a/drivers/media/platform/imagination/e5010-jpeg-enc.c
+++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c
@@ -517,10 +517,10 @@ static int e5010_s_selection(struct file *file, void *fh,
struct v4l2_selection
switch (s->flags) {
case 0:
- s->r.width = round_down(s->r.width,
queue->fmt->frmsize.step_width);
- s->r.height = round_down(s->r.height,
queue->fmt->frmsize.step_height);
- s->r.left = round_down(s->r.left,
queue->fmt->frmsize.step_width);
- s->r.top = round_down(s->r.top, 2);
+ s->r.width = round_closest_down(s->r.width,
queue->fmt->frmsize.step_width);
+ s->r.height = round_closest_down(s->r.height,
queue->fmt->frmsize.step_height);
+ s->r.left = round_closest_down(s->r.left,
queue->fmt->frmsize.step_width);
+ s->r.top = round_closest_down(s->r.top, 2);
if (s->r.left + s->r.width > queue->width)
s->r.width = round_down(s->r.width + s->r.left -
queue->width,
--
2.39.1
[PATCH] drivers/base/devres.c: refactor using guards
Refactored devres.c using lock guards and scoped locks.
Changed functions:
- devres_for_each_res
- devres_add
- devres_find
- devres_get
- devres_remove
- release_nodes
- release_all
- devres_open_group
- find_group
- devres_remove_group
- devres_release_group
- devm_krealloc
Signed-off-by: Andrea Calabrese
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 3df0025d12aa..8f72426ac0b6 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -194,14 +194,12 @@ void devres_for_each_res(struct device *dev, dr_release_t
release,
{
struct devres_node *node;
struct devres_node *tmp;
- unsigned long flags;
if (!fn)
return;
- spin_lock_irqsave(&dev->devres_lock, flags);
- list_for_each_entry_safe_reverse(node, tmp,
- &dev->devres_head, entry) {
+ guard(spinlock)(&dev->devres_lock);
+ list_for_each_entry_safe_reverse(node, tmp, &dev->devres_head, entry) {
struct devres *dr = container_of(node, struct devres, node);
if (node->release != release)
@@ -210,7 +208,6 @@ void devres_for_each_res(struct device *dev, dr_release_t
release,
continue;
fn(dev, dr->data, data);
}
- spin_unlock_irqrestore(&dev->devres_lock, flags);
}
EXPORT_SYMBOL_GPL(devres_for_each_res);
@@ -243,11 +240,9 @@ EXPORT_SYMBOL_GPL(devres_free);
void devres_add(struct device *dev, void *res)
{
struct devres *dr = container_of(res, struct devres, data);
- unsigned long flags;
- spin_lock_irqsave(&dev->devres_lock, flags);
+ guard(spinlock)(&dev->devres_lock);
add_dr(dev, &dr->node);
- spin_unlock_irqrestore(&dev->devres_lock, flags);
}
EXPORT_SYMBOL_GPL(devres_add);
@@ -287,11 +282,8 @@ void * devres_find(struct device *dev, dr_release_t
release,
dr_match_t match, void *match_data)
{
struct devres *dr;
- unsigned long flags;
-
- spin_lock_irqsave(&dev->devres_lock, flags);
+ guard(spinlock)(&dev->devres_lock);
dr = find_dr(dev, release, match, match_data);
- spin_unlock_irqrestore(&dev->devres_lock, flags);
if (dr)
return dr->data;
@@ -318,16 +310,15 @@ void * devres_get(struct device *dev, void *new_res,
{
struct devres *new_dr = container_of(new_res, struct devres, data);
struct devres *dr;
- unsigned long flags;
-
- spin_lock_irqsave(&dev->devres_lock, flags);
- dr = find_dr(dev, new_dr->node.release, match, match_data);
- if (!dr) {
- add_dr(dev, &new_dr->node);
- dr = new_dr;
- new_res = NULL;
+ {
+ guard(spinlock)(&dev->devres_lock);
+ dr = find_dr(dev, new_dr->node.release, match, match_data);
+ if (!dr) {
+ add_dr(dev, &new_dr->node);
+ dr = new_dr;
+ new_res = NULL;
+ }
}
- spin_unlock_irqrestore(&dev->devres_lock, flags);
devres_free(new_res);
return dr->data;
@@ -353,15 +344,20 @@ void * devres_remove(struct device *dev, dr_release_t
release,
dr_match_t match, void *match_data)
{
struct devres *dr;
- unsigned long flags;
-
- spin_lock_irqsave(&dev->devres_lock, flags);
- dr = find_dr(dev, release, match, match_data);
- if (dr) {
- list_del_init(&dr->node.entry);
- devres_log(dev, &dr->node, "REM");
+ scoped_guard(spinlock, &dev->devres_lock) {
+ dr = find_dr(dev, release, match, match_data);
+ if (dr) {
+ list_del_init(&dr->node.entry);
+ devres_log(dev, &dr->node, "REM");
+ }
+ }
+ scoped_guard(spinlock, &dev->devres_lock) {
+ dr = find_dr(dev, release, match, match_data);
+ if (dr) {
+ list_del_init(&dr->node.entry);
+ devres_log(dev, &dr->node, "REM");
+ }
}
- spin_unlock_irqrestore(&dev->devres_lock, flags);
if (dr)
return dr->data;
@@ -516,7 +512,6 @@ static void release_nodes(struct device *dev, struct
list_head *todo)
*/
int devres_release_all(struct device *dev)
{
- unsigned long flags;
LIST_HEAD(todo);
int cnt;
@@ -528,9 +523,9 @@ int devres_release_all(struct device *dev)
if (list_empty(&dev->devres_head))
return 0;
- spin_lock_irqsave(&dev->devres_lock, flags);
- cnt = remove_nodes(dev, dev->devres_head.next, &dev->devres_head,
&todo);
- spin_unlock_irqrestore(&dev->devres_lock, flags);
+ scoped_guard(spinlock, &dev->devres_lock) {
+ cnt = remove_nodes(dev, dev->devres_head.next,
&dev->devres_head, &todo);
+ }
release_nodes(dev, &t
[PATCH] drm/hisilicon: Fix a NULL pointer access when call hibmc_unload
From: Shixiong Ou
If Calling hibmc_mm_init() failed in hibmc_load(), the hibmc_unload()
will access a NULL pointer, as it don't call ww_mutex_init() to
initialize mode_config.connection_mutex but try to lock it when
calling drm_atomic_helper_shutdown() in hibmc_unload().
[ 50.939211][ 0] Unable to handle kernel NULL pointer dereference at virtual
address 0018
..
[ 51.149882][ 0] Call trace:
[ 51.152750][ 0] ww_mutex_lock+0xf0/0x1e0
[ 51.156829][ 0] drm_modeset_lock+0x184/0x2c0
[ 51.161254][ 0] drm_modeset_lock_all_ctx+0x98/0x188
[ 51.166284][ 0] drm_atomic_helper_shutdown+0xa4/0x128
[ 51.171487][ 0] hibmc_unload+0x50/0x2f0
[ 51.175479][ 0] hibmc_load+0x5d8/0x888
[ 51.179386][ 0] drm_dev_register+0x280/0x558
[ 51.183811][ 0] drm_get_pci_dev+0x140/0x3c8
[ 51.188150][ 0] hibmc_pci_probe+0x148/0x190
[ 51.192489][ 0] local_pci_probe+0xc4/0x180
[ 51.196742][ 0] pci_device_probe+0x328/0x530
[ 51.201167][ 0] really_probe+0x498/0x9a0
[ 51.205248][ 0] driver_probe_device+0x224/0x308
[ 51.209932][ 0] device_driver_attach+0xec/0x128
[ 51.214616][ 0] __driver_attach+0x144/0x280
[ 51.218955][ 0] bus_for_each_dev+0x120/0x1a0
[ 51.223380][ 0] driver_attach+0x48/0x60
[ 51.227372][ 0] bus_add_driver+0x328/0x578
[ 51.231625][ 0] driver_register+0x148/0x398
[ 51.235965][ 0] __pci_register_driver+0x15c/0x1c8
[ 51.240823][ 0] hibmc_init+0x2c/0x34
[ 51.244557][ 0] do_one_initcall+0xc8/0x4a8
[ 51.248810][ 0] kernel_init_freeable+0x678/0x75c
[ 51.253582][ 0] kernel_init+0x18/0x128
[ 51.257489][ 0] ret_from_fork+0x10/0x18
Add a initialized flag to avoid this.
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 ++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 57c21ec452b7..343f64d66e75 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -99,6 +99,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
ret = drmm_mode_config_init(dev);
if (ret)
return ret;
+ priv->mode_config_initialized = true;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -240,9 +241,12 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev->dev);
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
- drm_atomic_helper_shutdown(dev);
-
+ if(priv->mode_config_initialized){
+ drm_atomic_helper_shutdown(dev);
+ priv->mode_config_initialized = false;
+ }
free_irq(pdev->irq, dev);
pci_disable_msi(to_pci_dev(dev->dev));
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 207aa3f660b0..08fd7cb59bb5 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -37,6 +37,7 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
+ bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
--
2.25.1
Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver
On 6/5/24 16:48, Heiko Stübner wrote: Without this change, connecting to a DVI display does not work, and reading the EDID ends in the "i2c read error" below. I had a lot of problems initially with the vendor driver on my DVI display, and am aware that several changes were required. However, I tested Cristian patch and worked fine. All modes were apparently detected from the display and they all worked. But maybe I was just lucky and it was using a somehow cached table, I can't say. This is an AOC DVI display from 2011 with a passive adapter. Luis
Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()
Il 02/06/24 17:57, Andy Shevchenko ha scritto: Make two APIs look similar. Hence convert match_string() to be a 2-argument macro. In order to avoid unneeded churn, convert all users as well. There is no functional change intended. Signed-off-by: Andy Shevchenko For MediaTek Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()
On Sun, Jun 02, 2024 at 06:57:12PM +0300, Andy Shevchenko wrote: > Make two APIs look similar. Hence convert match_string() to be > a 2-argument macro. In order to avoid unneeded churn, convert > all users as well. There is no functional change intended. > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > index 1b7e82a0ad2e..b6f52f44625f 100644 > --- a/drivers/cpufreq/amd-pstate.c > +++ b/drivers/cpufreq/amd-pstate.c > @@ -1117,9 +1117,9 @@ static ssize_t store_energy_performance_preference( > if (ret != 1) > return -EINVAL; > > - ret = match_string(energy_perf_strings, -1, str_preference); > + ret = __match_string(energy_perf_strings, -1, str_preference); > if (ret < 0) > - return -EINVAL; > + return ret; > > mutex_lock(&amd_pstate_limits_lock); > ret = amd_pstate_set_energy_pref_index(cpudata, ret); For drivers/cpufreq/amd-pstate.c Acked-by: Gautham R. Shenoy -- Thanks and Regards gautham.
[PATCH] i2c: imx-lpi2c: add eDMA mode support for LPI2C
From: Carlos Song
Add eDMA mode support for LPI2C.
There are some differences between TX DMA mode and RX DMA mode.
LPI2C MTDR register is Controller Transmit Data Register.
When LPI2C send data, it is tx cmd register and tx data fifo.
When LPI2C receive data, it is just a rx cmd register. LPI2C MRDR
register is Controller Receive Data Register, received data are
stored in this.
MTDR[8:10] is CMD field and MTDR[0:7] is DATA filed.
+---+---+
| C M D | D A T A |
+---+---+---+---+---+---+---+---+---+---+---+
| 10| 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---+---+---+---+---+---+---+---+---+---+---+
MRDR is Controller Receive Data Register.
MRDR[0:7] is DATA filed.
+---+
| D A T A |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---+---+---+---+---+---+---+---+
When the LPI2C controller needs to send data, tx cmd and 8-bit data
should be written into MTDR:
CMD: 000b: Transmit the value in DATA[7:0].
DATA: 8-bit data.
If LPI2C controller needs to send N 8-bit data, just write N times
(CMD(W) + DATA(u8)) to MTDR.
When the LPI2C controller needs to receive data, rx cmd should be
written into MTDR, the received data will be stored in the MRDR.
MTDR(CMD): 001b: Receive (DATA[7:0] + 1) 8-bit data.
MTDR(DATA): byte counter.
MRDR(DATA): 8-bit data.
So when LPI2C controller needs to receive N 8-bit data,
1. N <= 256:
Write 1 time (CMD(R) + BYTE COUNT(N-1)) into MTDR and receive data from
MRDR.
2. N > 256:
Write N/256 times (CMD(R) + BYTE COUNT(255)) + 1 time (CMD(R) + BYTE
COUNT(N%256)) into MTDR and receive data from MRDR.
Due to these differences, when LPI2C is in DMA TX mode, only enable TX
channel to send data. But when LPI2C is in DMA RX mode, TX and RX channel
are both enabled, TX channel is used to send RX cmd and RX channel is
used to receive data.
Signed-off-by: Carlos Song
Reviewed-by: Frank Li
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 536 -
1 file changed, 528 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 0197786892a2..26640c1dadc7 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -29,6 +31,7 @@
#define LPI2C_MCR 0x10/* i2c contrl register */
#define LPI2C_MSR 0x14/* i2c status register */
#define LPI2C_MIER 0x18/* i2c interrupt enable */
+#define LPI2C_MDER 0x1C/* i2c DMA enable */
#define LPI2C_MCFGR0 0x20/* i2c master configuration */
#define LPI2C_MCFGR1 0x24/* i2c master configuration */
#define LPI2C_MCFGR2 0x28/* i2c master configuration */
@@ -70,11 +73,14 @@
#define MCFGR1_AUTOSTOPBIT(8)
#define MCFGR1_IGNACK BIT(9)
#define MRDR_RXEMPTY BIT(14)
+#define MDER_TDDE BIT(0)
+#define MDER_RDDE BIT(1)
#define I2C_CLK_RATIO 2
#define CHUNK_DATA 256
#define I2C_PM_TIMEOUT 10 /* ms */
+#define I2C_DMA_THRESHOLD 8 /* bytes */
enum lpi2c_imx_mode {
STANDARD, /* 100+Kbps */
@@ -108,6 +114,22 @@ struct lpi2c_imx_struct {
unsigned intrxfifosize;
enum lpi2c_imx_mode mode;
struct i2c_bus_recovery_info rinfo;
+
+ boolcan_use_dma;
+ boolusing_pio_mode;
+ u8 rx_cmd_buf_len;
+ u16 *rx_cmd_buf;
+ u8 *dma_buf;
+ unsigned intdma_len;
+ unsigned inttx_burst_num;
+ unsigned intrx_burst_num;
+ resource_size_t phy_addr;
+ dma_addr_t dma_tx_addr;
+ dma_addr_t dma_addr;
+ enum dma_data_direction dma_direction;
+ struct dma_chan *chan_tx;
+ struct dma_chan *chan_rx;
+ struct i2c_msg *msg;
};
static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx,
@@ -305,7 +327,7 @@ static int lpi2c_imx_master_disable(struct lpi2c_imx_struct
*lpi2c_imx)
return 0;
}
-static int lpi2c_imx_msg_complete(struct lpi2c_imx_struct *lpi2c_imx)
+static int lpi2c_imx_pio_msg_complete(struct lpi2c_imx_struct *lpi2c_imx)
{
unsigned long time_left;
@@ -451,6 +473,444 @@ static void lpi2c_imx_read(struct lpi2c_imx_struct
*lpi2c_imx,
lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);
}
+static bool is_use_dma(struct lpi2c_imx_struct *lpi2c_imx, struct i2c_msg *msg)
+{
+ if (!lpi2c_imx->can_use_dma)
+ return false;
+
+ /*
+* When the length of data is less than I2C_DMA_THRESHOLD,
+* cpu mode is used directly to avoid low performance.
+*/
+ if (msg->len < I2C_DMA_THRESHOLD)
+ return false;
+
+ return true;
+}
+
+static int lpi2c
Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
On 6/6/24 2:22 AM, Rob Herring wrote:
> On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
>> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
>> found on Rockchip RK3588 SoC family.
>>
>> Since RK3588 uses different clocks than previous Rockchip SoCs and also
>> requires a couple of reset lines and some additional properties, provide
>> the required changes in the binding to accommodate all variants.
>>
>> Signed-off-by: Cristian Ciocaltea
>> ---
>> .../display/rockchip/rockchip,dw-hdmi.yaml | 127
>> +++--
>> 1 file changed, 90 insertions(+), 37 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> index 2aac62219ff6..60d6b815227f 100644
>> ---
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> +++
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> @@ -10,12 +10,10 @@ maintainers:
>>- Mark Yao
>>
>> description: |
>> - The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
>> - with a companion PHY IP.
>> -
>> -allOf:
>> - - $ref: ../bridge/synopsys,dw-hdmi.yaml#
>> - - $ref: /schemas/sound/dai-common.yaml#
>> + For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
>> + HDMI 1.4 TX controller IP with a companion PHY IP.
>> + The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
>> + TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>>
>> properties:
>>compatible:
>> @@ -25,6 +23,7 @@ properties:
>>- rockchip,rk3328-dw-hdmi
>>- rockchip,rk3399-dw-hdmi
>>- rockchip,rk3568-dw-hdmi
>> + - rockchip,rk3588-dw-hdmi
>>
>>reg-io-width:
>> const: 4
>> @@ -40,36 +39,6 @@ properties:
>>A 1.8V supply that powers up the SoC internal circuitry. The pin name
>> on the
>>SoC usually is HDMI_TX_AVDD_1V8.
>>
>> - clocks:
>> -minItems: 2
>> -items:
>> - - {}
>> - - {}
>> - # The next three clocks are all optional, but shall be specified in
>> this
>> - # order when present.
>> - - description: The HDMI CEC controller main clock
>> - - description: Power for GRF IO
>> - - description: External clock for some HDMI PHY (old clock name,
>> deprecated)
>> - - description: External clock for some HDMI PHY (new name)
>> -
>> - clock-names:
>> -minItems: 2
>> -items:
>> - - {}
>> - - {}
>> - - enum:
>> - - cec
>> - - grf
>> - - vpll
>> - - ref
>> - - enum:
>> - - grf
>> - - vpll
>> - - ref
>> - - enum:
>> - - vpll
>> - - ref
>> -
>>ddc-i2c-bus:
>> $ref: /schemas/types.yaml#/definitions/phandle
>> description:
>> @@ -131,13 +100,97 @@ properties:
>> required:
>>- compatible
>>- reg
>> - - reg-io-width
>>- clocks
>>- clock-names
>>- interrupts
>>- ports
>>- rockchip,grf
>>
>> +allOf:
>> + - $ref: /schemas/sound/dai-common.yaml#
>> + - if:
>> + properties:
>> +compatible:
>> + contains:
>> +enum:
>> + - rockchip,rk3588-dw-hdmi
>> +then:
>> + properties:
>> +reg:
>> + maxItems: 1
>> +
>> +clocks:
>> + minItems: 1
>> + items:
>> +- description: APB system interface clock
>> +# The next clocks are optional, but shall be specified in this
>> +# order when present.
>> +- description: TMDS/FRL link clock
>> +- description: EARC RX biphase clock
>> +- description: Reference clock
>> +- description: Audio interface clock
>> +- description: Video datapath clock
>> +
>> +clock-names:
>> + minItems: 1
>> + items:
>> +- const: pclk
>> +- enum: [hdp, earc, ref, aud, hclk_vo1]
>> +- enum: [earc, ref, aud, hclk_vo1]
>> +- enum: [ref, aud, hclk_vo1]
>> +- enum: [aud, hclk_vo1]
>> +- const: hclk_vo1
>> +
>> +resets:
>> + minItems: 2
>> + maxItems: 2
>> +
>> +reset-names:
>> + items:
>> +- const: ref
>> +- const: hdp
>> +
>> +interrupts:
>> + minItems: 1
>> + maxItems: 5
>> +
>> +rockchip,vo1_grf:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: Some QP related data is accessed through VO1 GRF regs
>> +
>> + required:
>> +- resets
>> +- reset-names
>> +- rockchip,vo1_grf
>> +
>> +else:
>> + $ref: ../bridge/synopsys,dw-hdmi.yaml#
>
> This is odd... With this plus the amount of conditional schema, I think
> this should be a new schema doc. Doesn't have to have a c
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On Thu, Jun 06, 2024 at 01:23:03PM +0200, Maxime Ripard wrote: > On Thu, Jun 06, 2024 at 11:37:31AM GMT, Neil Armstrong wrote: > > On 06/06/2024 11:32, Maxime Ripard wrote: > > > On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: > > > > The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a > > > > number of handheld gaming devices made by Anbernic. By consensus a > > > > vendor prefix is not provided as the panel OEM is unknown. > > > > > > Where has this consensus been found? > > > > > > I had a look at the previous discussions, and I can't find any consensus > > > being reached there. And for that kind of thing, having the ack or > > > review of any of the DT maintainers would have been great. > > > > There was a consensus with Conor, this is why he acked v2, see > > https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ > > It's probably a matter of semantics here, but if it's with only one > person, it's not a consensus but an agreement. > > > ``` > > I think if we genuinely do not know what the vendor is then we just > > don't have a prefix. > > ``` > > And even then, I don't interpret Conor's statement as a formal agreement > but rather an acknowledgment of the issue. I mean, I specifically left an r-b below that line in v2: https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ I'm not a displays guy, so my sources were limited to what I could find from search engines, but I spent some time looking for an actual vendor of the panel and could not. All I found was various listings on places like AliExpress that did not mention an manufacturer. I'd rather not invent a vendor because we could not find the actual vendor of the panel & it seemed rather unreasonable to block support for the device on the basis of not being able to figure out the vendor. If you, as someone knowledgeable on displays, can figure the vendor out, then yeah we should definitely add it. > > I agree with Conor so I applied the patchset after Connor reviewed it and > > the comment was fixed in v3: > > https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ > > Yeah, I know. Still, it's a major deviation to what we've always been > doing, getting the DT maintainers voice on that would have been a good > idea. Is it a consensus of DT maintainers you're looking for? Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers
On 4.06.2024 4:40 PM, Will Deacon wrote: > On Thu, May 16, 2024 at 01:55:26PM -0500, Andrew Halaney wrote: >> On Thu, May 16, 2024 at 08:20:05PM GMT, Akhil P Oommen wrote: >>> On Thu, May 16, 2024 at 08:15:34AM -0500, Andrew Halaney wrote: If I understand correctly, you don't need any memory barrier. writel()/readl()'s are ordered to the same endpoint. That goes for all the reordering/barrier comments mentioned below too. device-io.rst: The read and write functions are defined to be ordered. That is the compiler is not permitted to reorder the I/O sequence. When the ordering can be compiler optimised, you can use __readb() and friends to indicate the relaxed ordering. Use this with care. memory-barriers.txt: (*) readX(), writeX(): The readX() and writeX() MMIO accessors take a pointer to the peripheral being accessed as an __iomem * parameter. For pointers mapped with the default I/O attributes (e.g. those returned by ioremap()), the ordering guarantees are as follows: 1. All readX() and writeX() accesses to the same peripheral are ordered with respect to each other. This ensures that MMIO register accesses by the same CPU thread to a particular device will arrive in program order. >>> >>> In arm64, a writel followed by readl translates to roughly the following >>> sequence: dmb_wmb(), __raw_writel(), __raw_readl(), dmb_rmb(). I am not >>> sure what is stopping compiler from reordering __raw_writel() and >>> __raw_readl() >>> above? I am assuming iomem cookie is ignored during compilation. >> >> It seems to me that is due to some usage of volatile there in >> __raw_writel() etc, but to be honest after reading about volatile and >> some threads from gcc mailing lists, I don't have a confident answer :) >> >>> >>> Added Will to this thread if he can throw some light on this. >> >> Hopefully Will can school us. > > The ordering in this case is ensured by the memory attributes used for > ioremap(). When an MMIO region is mapped using Device-nGnRE attributes > (as it the case for ioremap()), the "nR" part means "no reordering", so > readX() and writeX() to that region are ordered wrt each other. > > Note that guarantee _doesn't_ apply to other flavours of ioremap(), so > e.g. ioremap_wc() won't give you the ordering. > > Hope that helps, Just to make sure I'm following, would mapping things as nGnRnE effectively get rid of write buffering, perhaps being a way of debugging whether that in particular is causing issues (at the cost of speed)? Konrad
[PATCH] arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations
Since the debugfs functions have no-op stubs for CONFIG_DEBUG_FS=n,
the compiler will optimize the rest away since they are no longer referenced.
The benefit of removing the conditional compilation is that the build
is actually tested for both CONFIG_DEBUG_FS configuration values.
Assuming most developers have it enabled, CONFIG_DEBUG_FS=n is not tested
much and may fail the build due to the conditional compilation.
Reported-by: k2ci
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 14ee79becacb..5ba62e637a61 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -12,10 +12,8 @@
#include
#include
#include
-#ifdef CONFIG_DEBUG_FS
#include
#include
-#endif
#include
@@ -43,7 +41,6 @@ static int komeda_register_show(struct seq_file *sf, void *x)
DEFINE_SHOW_ATTRIBUTE(komeda_register);
-#ifdef CONFIG_DEBUG_FS
static void komeda_debugfs_init(struct komeda_dev *mdev)
{
if (!debugfs_initialized())
@@ -55,7 +52,6 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
debugfs_create_x16("err_verbosity", 0664, mdev->debugfs_root,
&mdev->err_verbosity);
}
-#endif
static ssize_t
core_id_show(struct device *dev, struct device_attribute *attr, char *buf)
@@ -265,9 +261,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
mdev->err_verbosity = KOMEDA_DEV_PRINT_ERR_EVENTS;
-#ifdef CONFIG_DEBUG_FS
komeda_debugfs_init(mdev);
-#endif
return mdev;
@@ -286,9 +280,7 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
sysfs_remove_group(&dev->kobj, &komeda_sysfs_attr_group);
-#ifdef CONFIG_DEBUG_FS
debugfs_remove_recursive(mdev->debugfs_root);
-#endif
if (mdev->aclk)
clk_prepare_enable(mdev->aclk);
--
2.25.1
Re: [PATCH v2 10/12] media: platform: mtk-mdp3: Get fine-grain control of cmdq_pkt_finalize()
Le 22/02/2024 à 16:41, Chun-Kuang Hu a écrit :
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().
Signed-off-by: Chun-Kuang Hu
---
drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c | 3 ++-
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c | 2 ++
drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
index 6adac857a477..b720e69b341d 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
@@ -471,7 +471,8 @@ int mdp_cmdq_send(struct mdp_dev *mdp, struct
mdp_cmdq_param *param)
dev_err(dev, "mdp_path_config error\n");
goto err_free_path;
}
- cmdq_pkt_finalize(&cmd->pkt);
+ cmdq_pkt_eoc(&cmd->pkt);
+ cmdq_pkt_jump_rel(&cmd->pkt, CMDQ_INST_SIZE, mdp->cmdq_shift_pa);
for (i = 0; i < num_comp; i++)
memcpy(&comps[i], path->comps[i].comp,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 94f4ed78523b..2214744c937c 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -231,6 +231,8 @@ static int mdp_probe(struct platform_device *pdev)
goto err_put_scp;
}
+ mdp->cmdq_shift_pa = cmdq_get_shift_pa(mdp->cmdq_clt->chan);
+
init_waitqueue_head(&mdp->callback_wq);
ida_init(&mdp->mdp_ida);
platform_set_drvdata(pdev, mdp);
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
index 7e21d226ceb8..ed61e0bb69ee 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.h
@@ -83,6 +83,7 @@ struct mdp_dev {
u32 id_count;
struct ida mdp_ida;
struct cmdq_client *cmdq_clt;
+ u8 cmdq_shift_pa;
Can send a new version of this series because this patch can't
be applied on media_tree/master branch.
The code look correct for me but we need to be able to applied it
to perform more checks.
Regards,
Benjamin
wait_queue_head_t callback_wq;
struct v4l2_device v4l2_dev;
Re: [PATCH v13 5/9] drm/dp: Add refresh rate divider to struct representing AS SDP
On Thu, Jun 06, 2024 at 02:38:45PM GMT, Jani Nikula wrote: > On Wed, 05 Jun 2024, Mitul Golani > wrote: > > Add target_rr_divider to structure representing AS SDP. > > It is valid only in FAVT mode, sink device ignores the bit in AVT > > mode. > > > > --v2: > > - Update commit header and send patch to dri-devel. > > > > Signed-off-by: Mitul Golani > > Reviewed-by: Arun R Murthy > > Maxime, Maarten, Thomas, ack for merging this via drm-intel-next? Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature
[Bug 218900] amdgpu: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=218900 Hanabishi (i.r.e.c.c.a.k.u.n+bugzilla.kernel@gmail.com) changed: What|Removed |Added CC||i.r.e.c.c.a.k.u.n+bugzilla. ||kernel@gmail.com --- Comment #14 from Hanabishi (i.r.e.c.c.a.k.u.n+bugzilla.kernel@gmail.com) --- *** Bug 218921 has been marked as a duplicate of this bug. *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Thu, Jun 06, 2024 at 10:21:07AM +0300, Jani Nikula wrote:
> On Wed, 05 Jun 2024, Chris Bainbridge wrote:
> > On Tue, Jun 04, 2024 at 10:02:29AM +0800, kernel test robot wrote:
> >> Hi Mario,
> >>
> >> kernel test robot noticed the following build errors:
> >>
> >> [auto build test ERROR on drm-misc/drm-misc-next]
> >> [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
> >> drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
> >> linus/master v6.10-rc2 next-20240603]
> >> [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#_base_tree_information]
> >>
> >> url:
> >> https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-client-Detect-when-ACPI-lid-is-closed-during-initialization/20240529-050440
> >> base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> >> patch link:
> >> https://lore.kernel.org/r/20240528210319.1242-1-mario.limonciello%40amd.com
> >> patch subject: [PATCH v2] drm/client: Detect when ACPI lid is closed
> >> during initialization
> >> config: i386-randconfig-053-20240604
> >> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/config)
> >> compiler: gcc-9 (Ubuntu 9.5.0-4ubuntu2) 9.5.0
> >> reproduce (this is a W=1 build):
> >> (https://download.01.org/0day-ci/archive/20240604/202406040928.eu1griwv-...@intel.com/reproduce)
> >>
> >> If you fix the issue in a separate patch/commit (i.e. not just a new
> >> version of
> >> the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot
> >> | Closes:
> >> https://lore.kernel.org/oe-kbuild-all/202406040928.eu1griwv-...@intel.com/
> >>
> >> All errors (new ones prefixed by >>):
> >>
> >>ld: drivers/gpu/drm/drm_client_modeset.o: in function
> >> `drm_client_match_edp_lid':
> >> >> drivers/gpu/drm/drm_client_modeset.c:281:(.text+0x221b): undefined
> >> >> reference to `acpi_lid_open'
> >>
> >>
> >> vim +281 drivers/gpu/drm/drm_client_modeset.c
> >>
> >>260
> >>261 static void drm_client_match_edp_lid(struct drm_device *dev,
> >>262 struct drm_connector
> >> **connectors,
> >>263 unsigned int
> >> connector_count,
> >>264 bool *enabled)
> >>265 {
> >>266 int i;
> >>267
> >>268 for (i = 0; i < connector_count; i++) {
> >>269 struct drm_connector *connector = connectors[i];
> >>270
> >>271 switch (connector->connector_type) {
> >>272 case DRM_MODE_CONNECTOR_LVDS:
> >>273 case DRM_MODE_CONNECTOR_eDP:
> >>274 if (!enabled[i])
> >>275 continue;
> >>276 break;
> >>277 default:
> >>278 continue;
> >>279 }
> >>280
> >> > 281 if (!acpi_lid_open()) {
> >>282 drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid
> >> is closed, disabling\n",
> >>283 connector->base.id,
> >> connector->name);
> >>284 enabled[i] = false;
> >>285 }
> >>286 }
> >>287 }
> >>288
> >>
> >> --
> >> 0-DAY CI Kernel Test Service
> >> https://github.com/intel/lkp-tests/wiki
> >
> > The failed config has CONFIG_ACPI_BUTTON=m. The build failure can be
> > fixed with:
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index b76438c31761..0271e66f44f8 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -271,11 +271,13 @@ static void drm_client_match_edp_lid(struct
> > drm_device *dev,
> > if (connector->connector_type != DRM_MODE_CONNECTOR_eDP ||
> > !enabled[i])
> > continue;
> >
> > +#if defined(CONFIG_ACPI_BUTTON)
> > if (!acpi_lid_open()) {
> > drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed,
> > disabling\n",
> > connector->base.id, connector->name);
> > enabled[i] = false;
> > }
> > +#endif
> > }
> > }
>
> No. This is because
>
> CONFIG_DRM=y
> CONFIG_ACPI_BUTTON=m
>
> The pedantically correct fix is probably having DRM
>
> depends on ACPI_BUTTON || ACPI_BUTTON=n
>
> but seeing how i915 and xe just
>
> select ACPI_BUTTON if ACPI
Huh. We should nuke that as we haven't used this lid stuff in ages.
--
Ville Syrjälä
Intel
[PATCH] drm/edid: reduce DisplayID log spamming
Debug printing at DisplayID validation leads to lots of log spamming as
it's called at DisplayID iterators during EDID parsing. Remove it, and
replace with a less noisy message at connector EDID update.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 3 ---
drivers/gpu/drm/drm_edid.c | 5 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 9d01d762801f..b4fd43783c50 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -33,9 +33,6 @@ validate_displayid(const u8 *displayid, int length, int idx)
if (IS_ERR(base))
return base;
- DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",
- base->rev, base->bytes, base->prod_id, base->ext_count);
-
/* +1 for DispID checksum */
dispid_length = sizeof(*base) + base->bytes + 1;
if (dispid_length > length - idx)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..9fc7292f5382 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6629,6 +6629,11 @@ static void update_displayid_info(struct drm_connector
*connector,
displayid_iter_edid_begin(drm_edid, &iter);
displayid_iter_for_each(block, &iter) {
+ drm_dbg_kms(connector->dev,
+ "[CONNECTOR:%d:%s] DisplayID extension version
0x%02x, primary use 0x%02x\n",
+ connector->base.id, connector->name,
+ displayid_version(&iter),
+ displayid_primary_use(&iter));
if (displayid_version(&iter) == DISPLAY_ID_STRUCTURE_VER_20 &&
(displayid_primary_use(&iter) ==
PRIMARY_USE_HEAD_MOUNTED_VR ||
displayid_primary_use(&iter) ==
PRIMARY_USE_HEAD_MOUNTED_AR))
--
2.39.2
Re: [PATCH] arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations
On Thu, Jun 06, 2024 at 08:08:42PM +0800, pengfuyuan wrote:
> Since the debugfs functions have no-op stubs for CONFIG_DEBUG_FS=n,
> the compiler will optimize the rest away since they are no longer referenced.
>
> The benefit of removing the conditional compilation is that the build
> is actually tested for both CONFIG_DEBUG_FS configuration values.
> Assuming most developers have it enabled, CONFIG_DEBUG_FS=n is not tested
> much and may fail the build due to the conditional compilation.
>
> Reported-by: k2ci
> Signed-off-by: pengfuyuan
Acked-by: Liviu Dudau
Thanks for the cleanup!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 14ee79becacb..5ba62e637a61 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -12,10 +12,8 @@
> #include
> #include
> #include
> -#ifdef CONFIG_DEBUG_FS
> #include
> #include
> -#endif
>
> #include
>
> @@ -43,7 +41,6 @@ static int komeda_register_show(struct seq_file *sf, void
> *x)
>
> DEFINE_SHOW_ATTRIBUTE(komeda_register);
>
> -#ifdef CONFIG_DEBUG_FS
> static void komeda_debugfs_init(struct komeda_dev *mdev)
> {
> if (!debugfs_initialized())
> @@ -55,7 +52,6 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
> debugfs_create_x16("err_verbosity", 0664, mdev->debugfs_root,
> &mdev->err_verbosity);
> }
> -#endif
>
> static ssize_t
> core_id_show(struct device *dev, struct device_attribute *attr, char *buf)
> @@ -265,9 +261,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
>
> mdev->err_verbosity = KOMEDA_DEV_PRINT_ERR_EVENTS;
>
> -#ifdef CONFIG_DEBUG_FS
> komeda_debugfs_init(mdev);
> -#endif
>
> return mdev;
>
> @@ -286,9 +280,7 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
>
> sysfs_remove_group(&dev->kobj, &komeda_sysfs_attr_group);
>
> -#ifdef CONFIG_DEBUG_FS
> debugfs_remove_recursive(mdev->debugfs_root);
> -#endif
>
> if (mdev->aclk)
> clk_prepare_enable(mdev->aclk);
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/mediatek: Don't print error if EDEFER_PROBE returned on component_add
On Wed, 05 Jun 2024 12:50:25 -0400 Nícolas F. R. A. Prado wrote: > Use dev_err_probe() in the component_add() error path to prevent > printing an error when the probe is deferred. This was observed on > mt8195 with the disp-rdma driver: > > mediatek-disp-rdma 1c002000.rdma: Failed to add component: -517 > > But the same pattern is used across many other drivers, so update them > all. > > Signed-off-by: Nícolas F. R. A. Prado > --- > drivers/gpu/drm/mediatek/mtk_disp_aal.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_color.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_merge.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 2 +- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 2 +- > drivers/gpu/drm/mediatek/mtk_ethdr.c| 2 +- > drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 2 +- > 10 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c > b/drivers/gpu/drm/mediatek/mtk_disp_aal.c > index 3ce8f32b06d5..892dc40458fb 100644 > --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c > +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c > @@ -197,7 +197,7 @@ static int mtk_disp_aal_probe(struct platform_device > *pdev) > > ret = component_add(dev, &mtk_disp_aal_component_ops); > if (ret) > - dev_err(dev, "Failed to add component: %d\n", ret); > + dev_err_probe(dev, ret, "Failed to add component\n"); Perhaps return dev_err_probe(...) return 0; Whilst I can see you are focused on this one problem case, it might be better to use dev_err_probe() for all the similar cases earlier in these functions. Then that return dev_err_probe() pattern will make more sense as it will be consistent with all the other calls.
[PATCH v3 1/4] drm/sched: store the drm_device instead of the device
When tracing is enabled, being able to identify which device is sending
events is useful; for this the next commit will extend events to include
drm_device::primary::index.
Since the device member is only used in the drm_* log macros, we can
replace it by a drm_device pointer.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
drivers/gpu/drm/imagination/pvr_queue.c| 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c| 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 26 +++---
drivers/gpu/drm/v3d/v3d_sched.c| 12 +-
drivers/gpu/drm/xe/xe_execlist.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.h | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
include/drm/gpu_scheduler.h| 4 ++--
17 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 932dc93b2e63..7f2a68ad8034 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2738,7 +2738,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
- adev->dev);
+ &adev->ddev);
if (r) {
DRM_ERROR("Failed to create scheduler on ring %s.\n",
ring->name);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index c4b04b0dee16..c4345b68a51f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -138,7 +138,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
DRM_SCHED_PRIORITY_COUNT,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
-dev_name(gpu->dev), gpu->dev);
+dev_name(gpu->dev), gpu->drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/imagination/pvr_queue.c
b/drivers/gpu/drm/imagination/pvr_queue.c
index 5ed9c98fb599..cdbb6c01e952 100644
--- a/drivers/gpu/drm/imagination/pvr_queue.c
+++ b/drivers/gpu/drm/imagination/pvr_queue.c
@@ -1287,7 +1287,7 @@ struct pvr_queue *pvr_queue_create(struct pvr_context
*ctx,
pvr_dev->sched_wq, 1, 64 * 1024, 1,
msecs_to_jiffies(500),
pvr_dev->sched_wq, NULL, "pvr-queue",
-pvr_dev->base.dev);
+&pvr_dev->base);
if (err)
goto err_release_ufo;
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index bbf3f8feab94..db6ee7650468 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -526,7 +526,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
- NULL, name, pipe->ldev->dev);
+ NULL, name, pipe->ldev->ddev);
}
void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 9d6655f96f0c..3a4b3816f2c9 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -101,7 +101,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
ret = drm_sched_init(&ring->sched, &msm_sched_ops, NULL,
DRM_SCHED_PRIORITY_COUNT,
num_hw_submissions, 0, sched_timeout,
-NULL, NULL, to_msm_bo(ring->bo)->name,
gpu->dev->dev);
+NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev);
if (ret) {
goto fail;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
b/drivers/gpu/drm/nouveau/nouveau_sched.c
index 32fa2e273965..386839bed8a2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sched.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
@@ -419,7 +419,7 @@ nouveau_sched_init(struct nouveau
[PATCH v3 2/4] drm/sched: add dev_index=xx to the drm_sched_process_job event
Until the switch from kthread to workqueue, a userspace application could
determine the device index from the pid of the thread sending this event.
With workqueues this is not possible anymore, so the event needs to contain
this information (the ring name alone is not enough, because they're not
unique).
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/scheduler/gpu_scheduler_trace.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index c75302ca3427..0a19c121bda5 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -28,6 +28,9 @@
#include
#include
+#include "drm/drm_device.h"
+#include "drm/drm_file.h"
+
#undef TRACE_SYSTEM
#define TRACE_SYSTEM gpu_scheduler
#define TRACE_INCLUDE_FILE gpu_scheduler_trace
@@ -42,6 +45,7 @@ DECLARE_EVENT_CLASS(drm_sched_job,
__field(uint64_t, id)
__field(u32, job_count)
__field(int, hw_job_count)
+__field(int, dev_index)
),
TP_fast_assign(
@@ -52,6 +56,7 @@ DECLARE_EVENT_CLASS(drm_sched_job,
__entry->job_count =
spsc_queue_count(&entity->job_queue);
__entry->hw_job_count = atomic_read(
&sched_job->sched->credit_count);
+ __entry->dev_index =
sched_job->sched->dev->primary->index;
),
TP_printk("entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw
job count:%d",
__entry->entity, __entry->id,
@@ -64,9 +69,13 @@ DEFINE_EVENT(drm_sched_job, drm_sched_job,
TP_ARGS(sched_job, entity)
);
-DEFINE_EVENT(drm_sched_job, drm_run_job,
+DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
- TP_ARGS(sched_job, entity)
+ TP_ARGS(sched_job, entity),
+ TP_printk("dev_index=%d entity=%p id=%llu, fence=%p, ring=%s, job
count:%u, hw job count:%d",
+ __entry->dev_index, __entry->entity, __entry->id,
+ __entry->fence, __get_str(name),
+ __entry->job_count, __entry->hw_job_count)
);
TRACE_EVENT(drm_sched_process_job,
--
2.40.1
[PATCH v3 3/4] drm/sched: cleanup gpu_scheduler trace events
Print identifiers instead of pointers:
* "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
coherent way to print the fence. A possible follow up change would be
to use the same format in traces/../dma-fence.h.
* "entity=%p" is removed because the fence's context is already an
identifier of the job owner.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 27 ++-
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index 0a19c121bda5..2d7f2252eb5d 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -58,9 +58,9 @@ DECLARE_EVENT_CLASS(drm_sched_job,
&sched_job->sched->credit_count);
__entry->dev_index =
sched_job->sched->dev->primary->index;
),
- TP_printk("entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw
job count:%d",
- __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
count:%u, hw job count:%d",
+ __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
);
@@ -72,9 +72,9 @@ DEFINE_EVENT(drm_sched_job, drm_sched_job,
DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
TP_ARGS(sched_job, entity),
- TP_printk("dev_index=%d entity=%p id=%llu, fence=%p, ring=%s, job
count:%u, hw job count:%d",
- __entry->dev_index, __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("dev_index=%d id=%llu, fence=(context:%llu, seqno:%lld),
ring=%s, job count:%u, hw job count:%d",
+ __entry->dev_index, __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
);
@@ -88,7 +88,8 @@ TRACE_EVENT(drm_sched_process_job,
TP_fast_assign(
__entry->fence = &fence->finished;
),
- TP_printk("fence=%p signaled", __entry->fence)
+ TP_printk("fence=(context:%llu, seqno:%lld) signaled",
+ __entry->fence->context, __entry->fence->seqno)
);
TRACE_EVENT(drm_sched_job_wait_dep,
@@ -96,23 +97,25 @@ TRACE_EVENT(drm_sched_job_wait_dep,
TP_ARGS(sched_job, fence),
TP_STRUCT__entry(
__string(name, sched_job->sched->name)
+__field(uint64_t, fence_context)
__field(uint64_t, id)
__field(struct dma_fence *, fence)
__field(uint64_t, ctx)
-__field(unsigned, seqno)
+__field(uint64_t, seqno)
),
TP_fast_assign(
__assign_str(name);
+ /* Store the hw exec fence context. */
+ __entry->fence_context =
sched_job->entity->fence_context + 1;
__entry->id = sched_job->id;
__entry->fence = fence;
__entry->ctx = fence->context;
__entry->seqno = fence->seqno;
),
- TP_printk("job ring=%s, id=%llu, depends fence=%p, context=%llu,
seq=%u",
- __get_str(name), __entry->id,
- __entry->fence, __entry->ctx,
- __entry->seqno)
+ TP_printk("job ring=%s, fence_context=%llu, id=%llu, depends
fence=(context:%llu, seqno:%lld)",
+ __get_str(name), __entry->fence_context, __entry->id,
+ __entry->ctx, __entry->seqno)
);
#endif
--
2.40.1
[PATCH v3 0/4] Improve gpu_scheduler trace events
Hi,
This is the new version of my patch series aiming at improving the
trace events around gpu jobs.
The main ideas implemented are: trace dependencies between jobs and
identify the GPU running jobs (because 'ring' is not a unique attribute).
Changes from v2:
* dropped all amdgpu changes. The goal here is to make the gpu_scheduler
trace events usable by a tool, without dependencies on driver-specific
events
* dropped the vblank related changes. I'll post a separate series to
cover drm/vblank events later.
* reworked fence printing so it's coherent between all events.
* added a dev_index to let the tools parsing the events which GPU is
running a job. It wasn't needed before the gpu scheduler switch to
workqueues because the queue pid was enough to identify the hardware queue.
* dropped the changes to trace the "why" of a dependency. I implemented
a version based on Sima's suggestion using xa_tag_pointer but I'm not
convinced it's really useful, so I'm dropping it for now.
Open questions:
* assuming the new fence printing format is agreed on,
should we add some code to preserve the old format?
* checkpatch doesn't like the indentation in the last patch, because
everything is vertically aligned to 'TP_fast_assign('. How to best fix it?
WARNING: Statements should start on a tabstop
#82: FILE: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h:80:
+unsigned long idx;
v2: https://lists.freedesktop.org/archives/dri-devel/2024-February/441341.html
Pierre-Eric Pelloux-Prayer (4):
drm/sched: store the drm_device instead of the device
drm/sched: add dev_index=xx to the drm_sched_process_job event
drm/sched: cleanup gpu_scheduler trace events
drm/sched: trace dependencies for gpu jobs
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
drivers/gpu/drm/imagination/pvr_queue.c | 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 88 +++
drivers/gpu/drm/scheduler/sched_entity.c | 11 ++-
drivers/gpu/drm/scheduler/sched_main.c| 28 +++---
drivers/gpu/drm/v3d/v3d_sched.c | 12 +--
drivers/gpu/drm/xe/xe_execlist.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.h | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c| 2 +-
include/drm/gpu_scheduler.h | 4 +-
18 files changed, 115 insertions(+), 54 deletions(-)
--
2.40.1
[PATCH v3 4/4] drm/sched: trace dependencies for gpu jobs
Trace the fence dependencies similarly to how we print fences:
... , dependencies:{(context:606, seqno:38006)}
This allows tools to analyze the dependencies between the jobs (previously
it was only possible for fences traced by drm_sched_job_wait_dep).
Since drm_sched_job and drm_run_job use the same base event class,
the caller of trace_drm_run_job have to pass a dep_count of 0 (which
is ignored because dependencies are only considered at submit time).
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 58 ---
drivers/gpu/drm/scheduler/sched_entity.c | 8 ++-
drivers/gpu/drm/scheduler/sched_main.c| 2 +-
3 files changed, 58 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index 2d7f2252eb5d..9d90237793a1 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include "drm/drm_device.h"
@@ -35,9 +36,34 @@
#define TRACE_SYSTEM gpu_scheduler
#define TRACE_INCLUDE_FILE gpu_scheduler_trace
+#ifndef __TRACE_EVENT_GPU_SCHEDULER_PRINT_FN
+#define __TRACE_EVENT_GPU_SCHEDULER_PRINT_FN
+/* Similar to trace_print_array_seq but for fences. */
+static inline const char *__print_dma_fence_array(struct trace_seq *p, const
void *buf, int count)
+{
+ const char *ret = trace_seq_buffer_ptr(p);
+ u64 *fences = (u64 *) buf;
+ const char *prefix = "";
+
+ trace_seq_putc(p, '{');
+ for (int i = 0; i < count; i++) {
+ u64 context = fences[2 * i], seqno = fences[2 * i + 1];
+
+ trace_seq_printf(p, "%s(context:%llu, seqno:%lld)",
+prefix, context, seqno);
+ prefix = ",";
+ }
+ trace_seq_putc(p, '}');
+ trace_seq_putc(p, 0);
+
+ return ret;
+}
+#endif
+
DECLARE_EVENT_CLASS(drm_sched_job,
- TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
- TP_ARGS(sched_job, entity),
+ TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity,
+unsigned int dep_count),
+ TP_ARGS(sched_job, entity, dep_count),
TP_STRUCT__entry(
__field(struct drm_sched_entity *, entity)
__field(struct dma_fence *, fence)
@@ -46,9 +72,14 @@ DECLARE_EVENT_CLASS(drm_sched_job,
__field(u32, job_count)
__field(int, hw_job_count)
__field(int, dev_index)
+__field(int, n_deps)
+__dynamic_array(u64, deps, dep_count * 2)
),
TP_fast_assign(
+ unsigned long idx;
+ struct dma_fence *fence;
+ u64 *dyn_arr;
__entry->entity = entity;
__entry->id = sched_job->id;
__entry->fence = &sched_job->s_fence->finished;
@@ -57,21 +88,32 @@ DECLARE_EVENT_CLASS(drm_sched_job,
__entry->hw_job_count = atomic_read(
&sched_job->sched->credit_count);
__entry->dev_index =
sched_job->sched->dev->primary->index;
+ __entry->n_deps = dep_count;
+ if (dep_count) {
+ dyn_arr = __get_dynamic_array(deps);
+ xa_for_each(&sched_job->dependencies, idx,
fence) {
+ dyn_arr[2 * idx] = fence->context;
+ dyn_arr[2 * idx + 1] = fence->seqno;
+ }
+ }
),
- TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
count:%u, hw job count:%d",
+ TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
count:%u, hw job count:%d, dependencies:%s",
__entry->id,
__entry->fence->context, __entry->fence->seqno,
__get_str(name),
- __entry->job_count, __entry->hw_job_count)
+ __entry->job_count, __entry->hw_job_count,
+ __print_dma_fence_array(p, __get_dynamic_array(deps),
__entry->n_deps))
);
DEFINE_EVENT(drm_sched_job, drm_sched_job,
- TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
- TP_ARGS(sched_job, entity)
+ TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity,
+unsigned int dep_count),
+ TP_ARGS(sched_job, entity, dep_count)
);
DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
[PATCH] backlight: lm3509_bl: Fix NULL vs IS_ERR() check in register() function
The devm_backlight_device_register() doesn't return NULL, it returns
error pointers. Update the error checking to match.
Fixes: b72755f5b577 ("backlight: Add new lm3509 backlight driver")
Signed-off-by: Dan Carpenter
---
drivers/video/backlight/lm3509_bl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3509_bl.c
b/drivers/video/backlight/lm3509_bl.c
index ab57f79ffe23..c93cdedff5ad 100644
--- a/drivers/video/backlight/lm3509_bl.c
+++ b/drivers/video/backlight/lm3509_bl.c
@@ -114,9 +114,10 @@ lm3509_backlight_register(struct device *dev, const char
*name_suffix,
}
bd = devm_backlight_device_register(dev, label, dev, data, ops, &props);
- if (bd)
- backlight_update_status(bd);
+ if (IS_ERR(bd))
+ return bd;
+ backlight_update_status(bd);
return bd;
}
--
2.43.0
Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
Am 06.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer:
When tracing is enabled, being able to identify which device is sending
events is useful; for this the next commit will extend events to include
drm_device::primary::index.
That sounds like a rather bad idea since the primary index is really
just an arbitrary number and not defined for all devices.
Why not use the device name instead? This way you don't need this change
in the first place.
Regards,
Christian.
Since the device member is only used in the drm_* log macros, we can
replace it by a drm_device pointer.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
drivers/gpu/drm/imagination/pvr_queue.c| 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c| 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 26 +++---
drivers/gpu/drm/v3d/v3d_sched.c| 12 +-
drivers/gpu/drm/xe/xe_execlist.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 2 +-
drivers/gpu/drm/xe/xe_gpu_scheduler.h | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
include/drm/gpu_scheduler.h| 4 ++--
17 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 932dc93b2e63..7f2a68ad8034 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2738,7 +2738,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
- adev->dev);
+ &adev->ddev);
if (r) {
DRM_ERROR("Failed to create scheduler on ring %s.\n",
ring->name);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index c4b04b0dee16..c4345b68a51f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -138,7 +138,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
DRM_SCHED_PRIORITY_COUNT,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
-dev_name(gpu->dev), gpu->dev);
+dev_name(gpu->dev), gpu->drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/imagination/pvr_queue.c b/drivers/gpu/drm/imagination/pvr_queue.c
index 5ed9c98fb599..cdbb6c01e952 100644
--- a/drivers/gpu/drm/imagination/pvr_queue.c
+++ b/drivers/gpu/drm/imagination/pvr_queue.c
@@ -1287,7 +1287,7 @@ struct pvr_queue *pvr_queue_create(struct pvr_context
*ctx,
pvr_dev->sched_wq, 1, 64 * 1024, 1,
msecs_to_jiffies(500),
pvr_dev->sched_wq, NULL, "pvr-queue",
-pvr_dev->base.dev);
+&pvr_dev->base);
if (err)
goto err_release_ufo;
diff --git a/drivers/gpu/drm/lima/lima_sched.c b/drivers/gpu/drm/lima/lima_sched.c
index bbf3f8feab94..db6ee7650468 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -526,7 +526,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
- NULL, name, pipe->ldev->dev);
+ NULL, name, pipe->ldev->ddev);
}
void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 9d6655f96f0c..3a4b3816f2c9 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -101,7 +101,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
ret = drm_sched_init(&ring->sched, &msm_sched_ops, NULL,
DRM_SCHED_PRIORITY_COUNT,
num_hw_submissions, 0, sched_timeout,
-NULL, NULL, to_msm_bo(ring->bo)->name,
gpu->dev->dev);
+NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev);
Re: [PATCH v3 3/4] drm/sched: cleanup gpu_scheduler trace events
On Thu, 6 Jun 2024 15:06:24 +0200
Pierre-Eric Pelloux-Prayer wrote:
> Print identifiers instead of pointers:
> * "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
> coherent way to print the fence. A possible follow up change would be
> to use the same format in traces/../dma-fence.h.
> * "entity=%p" is removed because the fence's context is already an
> identifier of the job owner.
>
> Signed-off-by: Pierre-Eric Pelloux-Prayer
> ---
> .../gpu/drm/scheduler/gpu_scheduler_trace.h | 27 ++-
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> index 0a19c121bda5..2d7f2252eb5d 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> @@ -58,9 +58,9 @@ DECLARE_EVENT_CLASS(drm_sched_job,
> &sched_job->sched->credit_count);
> __entry->dev_index =
> sched_job->sched->dev->primary->index;
> ),
> - TP_printk("entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw
> job count:%d",
> - __entry->entity, __entry->id,
> - __entry->fence, __get_str(name),
> + TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
> count:%u, hw job count:%d",
> + __entry->id,
> + __entry->fence->context, __entry->fence->seqno,
> __get_str(name),
> __entry->job_count, __entry->hw_job_count)
> );
>
> @@ -72,9 +72,9 @@ DEFINE_EVENT(drm_sched_job, drm_sched_job,
> DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
> TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
> *entity),
> TP_ARGS(sched_job, entity),
> - TP_printk("dev_index=%d entity=%p id=%llu, fence=%p, ring=%s, job
> count:%u, hw job count:%d",
> - __entry->dev_index, __entry->entity, __entry->id,
> - __entry->fence, __get_str(name),
> + TP_printk("dev_index=%d id=%llu, fence=(context:%llu, seqno:%lld),
> ring=%s, job count:%u, hw job count:%d",
> + __entry->dev_index, __entry->id,
> + __entry->fence->context, __entry->fence->seqno,
> __get_str(name),
> __entry->job_count, __entry->hw_job_count)
NACK!
You can't dereference pointers from TP_printk(). This is called seconds,
minutes, hours, even days or months after that pointer was assigned. How do
you know that pointer still points to anything?
-- Steve
> );
>
> @@ -88,7 +88,8 @@ TRACE_EVENT(drm_sched_process_job,
> TP_fast_assign(
> __entry->fence = &fence->finished;
> ),
> - TP_printk("fence=%p signaled", __entry->fence)
> + TP_printk("fence=(context:%llu, seqno:%lld) signaled",
> + __entry->fence->context, __entry->fence->seqno)
> );
>
> TRACE_EVENT(drm_sched_job_wait_dep,
> @@ -96,23 +97,25 @@ TRACE_EVENT(drm_sched_job_wait_dep,
> TP_ARGS(sched_job, fence),
> TP_STRUCT__entry(
>__string(name, sched_job->sched->name)
> + __field(uint64_t, fence_context)
>__field(uint64_t, id)
>__field(struct dma_fence *, fence)
>__field(uint64_t, ctx)
> - __field(unsigned, seqno)
> + __field(uint64_t, seqno)
>),
>
> TP_fast_assign(
> __assign_str(name);
> +/* Store the hw exec fence context. */
> +__entry->fence_context =
> sched_job->entity->fence_context + 1;
> __entry->id = sched_job->id;
> __entry->fence = fence;
> __entry->ctx = fence->context;
> __entry->seqno = fence->seqno;
> ),
> - TP_printk("job ring=%s, id=%llu, depends fence=%p, context=%llu,
> seq=%u",
> - __get_str(name), __entry->id,
> - __entry->fence, __entry->ctx,
> - __entry->seqno)
> + TP_printk("job ring=%s, fence_context=%llu, id=%llu, depends
> fence=(context:%llu, seqno:%lld)",
> + __get_str(name), __entry->fence_context, __entry->id,
> + __entry->ctx, __entry->seqno)
> );
>
> #endif
Re: [PATCH v3 3/4] drm/sched: cleanup gpu_scheduler trace events
Am 06.06.24 um 15:19 schrieb Steven Rostedt:
On Thu, 6 Jun 2024 15:06:24 +0200
Pierre-Eric Pelloux-Prayer wrote:
Print identifiers instead of pointers:
* "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
coherent way to print the fence. A possible follow up change would be
to use the same format in traces/../dma-fence.h.
* "entity=%p" is removed because the fence's context is already an
identifier of the job owner.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 27 ++-
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index 0a19c121bda5..2d7f2252eb5d 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -58,9 +58,9 @@ DECLARE_EVENT_CLASS(drm_sched_job,
&sched_job->sched->credit_count);
__entry->dev_index =
sched_job->sched->dev->primary->index;
),
- TP_printk("entity=%p, id=%llu, fence=%p, ring=%s, job count:%u, hw job
count:%d",
- __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("id=%llu, fence=(context:%llu, seqno:%lld), ring=%s, job
count:%u, hw job count:%d",
+ __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
);
@@ -72,9 +72,9 @@ DEFINE_EVENT(drm_sched_job, drm_sched_job,
DEFINE_EVENT_PRINT(drm_sched_job, drm_run_job,
TP_PROTO(struct drm_sched_job *sched_job, struct drm_sched_entity
*entity),
TP_ARGS(sched_job, entity),
- TP_printk("dev_index=%d entity=%p id=%llu, fence=%p, ring=%s, job
count:%u, hw job count:%d",
- __entry->dev_index, __entry->entity, __entry->id,
- __entry->fence, __get_str(name),
+ TP_printk("dev_index=%d id=%llu, fence=(context:%llu, seqno:%lld),
ring=%s, job count:%u, hw job count:%d",
+ __entry->dev_index, __entry->id,
+ __entry->fence->context, __entry->fence->seqno,
__get_str(name),
__entry->job_count, __entry->hw_job_count)
NACK!
You can't dereference pointers from TP_printk(). This is called seconds,
minutes, hours, even days or months after that pointer was assigned. How do
you know that pointer still points to anything?
Yeah, just wanted to reply the same thing. That is a really really bad idea.
You could in theory grab a reference to the fence, but we usually try to
avoid that as well since it prevents modules from unloading.
Rather move the context and seqno directly as values into the trace event.
Christian.
-- Steve
);
@@ -88,7 +88,8 @@ TRACE_EVENT(drm_sched_process_job,
TP_fast_assign(
__entry->fence = &fence->finished;
),
- TP_printk("fence=%p signaled", __entry->fence)
+ TP_printk("fence=(context:%llu, seqno:%lld) signaled",
+ __entry->fence->context, __entry->fence->seqno)
);
TRACE_EVENT(drm_sched_job_wait_dep,
@@ -96,23 +97,25 @@ TRACE_EVENT(drm_sched_job_wait_dep,
TP_ARGS(sched_job, fence),
TP_STRUCT__entry(
__string(name, sched_job->sched->name)
+__field(uint64_t, fence_context)
__field(uint64_t, id)
__field(struct dma_fence *, fence)
__field(uint64_t, ctx)
-__field(unsigned, seqno)
+__field(uint64_t, seqno)
),
TP_fast_assign(
__assign_str(name);
+ /* Store the hw exec fence context. */
+ __entry->fence_context =
sched_job->entity->fence_context + 1;
__entry->id = sched_job->id;
__entry->fence = fence;
__entry->ctx = fence->context;
__entry->seqno = fence->seqno;
),
- TP_printk("job ring=%s, id=%llu, depends fence=%p, context=%llu,
seq=%u",
- __get_str(name), __entry->id,
- __entry->fence, __entry->ctx,
- __entry->seqno)
+ TP_printk("job ring=%s, fence_context=%llu, id=%llu, depends
fence=(context:%llu, seqno:%lld)",
+ __get_str(name), __entry->fence_context, __entry->id,
+ __entry->ctx, __entry->seqno)
);
#endif
Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
On Thu, Jun 06, 2024 at 03:18:14PM +0200, Christian König wrote: > Am 06.06.24 um 15:06 schrieb Pierre-Eric Pelloux-Prayer: > > When tracing is enabled, being able to identify which device is sending > > events is useful; for this the next commit will extend events to include > > drm_device::primary::index. > > That sounds like a rather bad idea since the primary index is really > just an arbitrary number and not defined for all devices. > > Why not use the device name instead? This way you don't need this change > in the first place. FWIW dev_name() is what I added to all i915 display tracepoints. -- Ville Syrjälä Intel
Re: [PATCH v12 12/13] media: imagination: Round to closest multiple for cropping region
Hi Sebastian Thanks for the update. On 06/06/24 17:14, Sebastian Fricke wrote: > Hey, > > On 04.06.2024 16:23, Devarsh Thakkar wrote: >> If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up >> (V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest >> multiple of requested value while updating the crop rectangle coordinates. >> >> Use the rounding macro which gives preference to rounding down in case two >> nearest values (high and low) are possible to raise the probability of >> cropping rectangle falling inside the bound region. >> >> This complies with the VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl >> description as documented in v4l uapi [1] which specifies that driver >> should choose crop rectangle as close as possible if no flags are passed by >> user-space, as quoted below : >> >> "``0`` - The driver can adjust the rectangle size freely and shall choose a >> crop/compose rectangle as close as possible to the requested >> one." >> >> Link: >> https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst >> [1] >> Signed-off-by: Devarsh Thakkar > > Acked-by: Sebastian Fricke > > Can, whoever picks up the math changes, pick up this change as well? > I will send 1-6 via the media subsystem. > For [PATCH 1/13] to [PATCH 6/13] patches from the series, I see few warnings reported to me offline for some of the patches which were caught from using smatch/sparse related automation scripts which were somehow missed by my equivalent test script. The fixes should be trivial though and I will be rolling out a v13 soon to fix them up. The rest of the patches (PATCH 7/13 to PATCH 13/13) no smatch/sparse related warnings were caught for these though, and are good to go in. Although, I can still include them in V13 too just to avoid any confusion. Regards Devarsh
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On 06/06/2024 13:23, Maxime Ripard wrote: On Thu, Jun 06, 2024 at 11:37:31AM GMT, Neil Armstrong wrote: On 06/06/2024 11:32, Maxime Ripard wrote: On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a number of handheld gaming devices made by Anbernic. By consensus a vendor prefix is not provided as the panel OEM is unknown. Where has this consensus been found? I had a look at the previous discussions, and I can't find any consensus being reached there. And for that kind of thing, having the ack or review of any of the DT maintainers would have been great. There was a consensus with Conor, this is why he acked v2, see https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ It's probably a matter of semantics here, but if it's with only one person, it's not a consensus but an agreement. ``` I think if we genuinely do not know what the vendor is then we just don't have a prefix. ``` And even then, I don't interpret Conor's statement as a formal agreement but rather an acknowledgment of the issue. Well since both maintainers (DT and Panel) agreed, isn't it all good ? I agree with Conor so I applied the patchset after Connor reviewed it and the comment was fixed in v3: https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ Yeah, I know. Still, it's a major deviation to what we've always been doing, getting the DT maintainers voice on that would have been a good idea. I consider Conor's voice enough as one of the DT maintainers. Neil Maxime
Re: [PATCH v12 12/13] media: imagination: Round to closest multiple for cropping region
On Thu, Jun 06, 2024 at 01:44:59PM +0200, Sebastian Fricke wrote: > Hey, > > On 04.06.2024 16:23, Devarsh Thakkar wrote: > > If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up > > (V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest > > multiple of requested value while updating the crop rectangle coordinates. > > > > Use the rounding macro which gives preference to rounding down in case two > > nearest values (high and low) are possible to raise the probability of > > cropping rectangle falling inside the bound region. > > > > This complies with the VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl > > description as documented in v4l uapi [1] which specifies that driver > > should choose crop rectangle as close as possible if no flags are passed by > > user-space, as quoted below : > > > > "``0`` - The driver can adjust the rectangle size freely and shall choose a > > crop/compose rectangle as close as possible to the requested > > one." > > > > Link: > > https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst > > [1] > > Signed-off-by: Devarsh Thakkar > > Acked-by: Sebastian Fricke > > Can, whoever picks up the math changes, pick up this change as well? > I will send 1-6 via the media subsystem. math.h is orphaned, meaning any Tier-1 maintainer may push this through. So, there is nobody behind it. -- With Best Regards, Andy Shevchenko
[PATCH 6.1 219/473] fbdev: sh7760fb: allow modular build
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]
There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.
Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: John Paul Adrian Glaubitz
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz
Acked-by: Javier Martinez Canillas
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ff95f19224901..37089d5a7ccc5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2014,8 +2014,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
config FB_SH7760
- bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
- depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+ tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+ depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
--
2.43.0
[PATCH 6.6 314/744] fbdev: sh7760fb: allow modular build
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]
There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.
Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven
Signed-off-by: Randy Dunlap
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: John Paul Adrian Glaubitz
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz
Acked-by: Javier Martinez Canillas
Signed-off-by: Helge Deller
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c29754b65c0ec..325298573e120 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1761,8 +1761,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
config FB_SH7760
- bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
- depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+ tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+ depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_IOMEM_HELPERS
help
--
2.43.0
Re: [PATCH v3 1/6] drm/ci: uprev mesa version
On 28/05/2024 23:40, Vignesh Raman wrote:
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest version which includes a fix for this issue.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e
Use id_tokens for JWT authentication. Since s3 bucket is migrated to
mesa-rootfs, update the variables accordingly. Also copy helper scripts
to install, so that the ci jobs can use these scripts for logging.
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
v2:
- Uprev to recent version and use id_tokens for JWT authentication
v3:
- Move adding farm variable and updating device type variable to seperate
commit
---
drivers/gpu/drm/ci/build-igt.sh | 2 +-
drivers/gpu/drm/ci/build.sh | 6 +++--
drivers/gpu/drm/ci/container.yml | 12 +++--
drivers/gpu/drm/ci/gitlab-ci.yml | 44 +--
drivers/gpu/drm/ci/image-tags.yml | 2 +-
drivers/gpu/drm/ci/lava-submit.sh | 4 +--
6 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
index 500fa4f5c30a..7859554756c4 100644
--- a/drivers/gpu/drm/ci/build-igt.sh
+++ b/drivers/gpu/drm/ci/build-igt.sh
@@ -32,4 +32,4 @@ tar -cf artifacts/igt.tar /igt
# Pass needed files to the test stage
S3_ARTIFACT_NAME="igt.tar.gz"
gzip -c artifacts/igt.tar > ${S3_ARTIFACT_NAME}
-ci-fairy s3cp --token-file "${CI_JOB_JWT_FILE}" ${S3_ARTIFACT_NAME}
https://${PIPELINE_ARTIFACTS_BASE}/${KERNEL_ARCH}/${S3_ARTIFACT_NAME}
+ci-fairy s3cp --token-file "${S3_JWT_FILE}" ${S3_ARTIFACT_NAME}
https://${PIPELINE_ARTIFACTS_BASE}/${KERNEL_ARCH}/${S3_ARTIFACT_NAME}
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 106f2d40d222..a67871fdcd3f 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -128,6 +128,7 @@ fi
# Pass needed files to the test stage
mkdir -p install
cp -rfv .gitlab-ci/* install/.
+cp -rfv ci/* install/.
cp -rfv install/common install/ci-common
cp -rfv drivers/gpu/drm/ci/* install/.
@@ -141,14 +142,15 @@ if [[ "$UPLOAD_TO_MINIO" = "1" ]]; then
FILES_TO_UPLOAD="$FILES_TO_UPLOAD $(basename -a $DEVICE_TREES)"
fi
+ls -l "${S3_JWT_FILE}"
for f in $FILES_TO_UPLOAD; do
-ci-fairy s3cp --token-file "${CI_JOB_JWT_FILE}" /lava-files/$f \
+ci-fairy s3cp --token-file "${S3_JWT_FILE}" /lava-files/$f \
https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/$f
done
S3_ARTIFACT_NAME="kernel-files.tar.zst"
tar --zstd -cf $S3_ARTIFACT_NAME install
-ci-fairy s3cp --token-file "${CI_JOB_JWT_FILE}" ${S3_ARTIFACT_NAME}
https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/${S3_ARTIFACT_NAME}
+ci-fairy s3cp --token-file "${S3_JWT_FILE}" ${S3_ARTIFACT_NAME}
https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/${S3_ARTIFACT_NAME}
echo "Download vmlinux.xz from https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/vmlinux.xz";
fi
diff --git a/drivers/gpu/drm/ci/container.yml b/drivers/gpu/drm/ci/container.yml
index 9764e7921a4f..d6edf3635b23 100644
--- a/drivers/gpu/drm/ci/container.yml
+++ b/drivers/gpu/drm/ci/container.yml
@@ -36,15 +36,15 @@ debian/android_build:
rules:
- when: never
-debian/x86_64_test-android:
+.debian/x86_64_test-android:
rules:
- when: never
-windows_build_vs2019:
+windows_build_msvc:
rules:
- when: never
-windows_test_vs2019:
+windows_test_msvc:
rules:
- when: never
@@ -56,10 +56,6 @@ rustfmt:
rules:
- when: never
-windows_vs2019:
- rules:
-- when: never
-
-clang-format:
+windows_msvc:
rules:
- when: never
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 084e3ff8e3f4..8f32de63d92e 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: &drm-ci-project-path mesa/mesa
- DRM_CI_COMMIT_SHA: &drm-ci-commit-sha
9d162de9a05155e1c4041857a5848842749164cf
+ DRM_CI_COMMIT_SHA: &drm-ci-commit-sha
e2b9c5a9e3e4f9b532067af8022eaef8d6fc6c00
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -19,33 +19,47 @@ variables:
bash download-git-cache.sh
rm download-git-cache.sh
set +o xtrace
+ S3_JWT_FILE: /s3_jwt
S3_HOST: s3.freedesktop.org
+ # This bucket is used to fetch the kernel image
+ S3_KERNEL_BUCKET: mesa-rootfs
+ # Bucket for git cache
+ S3_GITCACHE_BUCKET: git-cache
+ # Bucket for the pipeline artifacts pushed to S3
+ S3_ARTIFACTS_BUCKET: artifacts
# per-pipeline artifact storage on MinIO
- PIPELINE_ARTIFACTS_BASE:
${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
+
Re: [PATCH v3 2/6] drm/ci: add farm variable
On 28/05/2024 23:40, Vignesh Raman wrote:
Mesa uses structured logs for logging and debug purpose,
https://mesa.pages.freedesktop.org/-/mesa/-/jobs/59165650/artifacts/results/job_detail.json
Since drm-ci uses the mesa scripts, add the farm variable
and update the device type for missing jobs.
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
v3:
- New commit to add farm variable and update device type variable.
---
drivers/gpu/drm/ci/test.yml | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 8bc63912fddb..2615f67f6aa3 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -24,6 +24,7 @@
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
DEBIAN_ARCH: "armhf"
+FARM: collabora
dependencies:
- testing:arm32
needs:
@@ -39,6 +40,7 @@
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
DEBIAN_ARCH: "arm64"
+FARM: collabora
dependencies:
- testing:arm64
needs:
@@ -54,6 +56,7 @@
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
DEBIAN_ARCH: "amd64"
+FARM: collabora
dependencies:
- testing:x86_64
needs:
@@ -74,6 +77,7 @@
S3_ARTIFACT_NAME: "arm64/kernel-files"
BM_KERNEL: https://${PIPELINE_ARTIFACTS_BASE}/arm64/Image.gz
BM_CMDLINE: "ip=dhcp console=ttyMSM0,115200n8 $BM_KERNEL_EXTRA_ARGS
root=/dev/nfs rw nfsrootdebug nfsroot=,tcp,nfsvers=4.2 init=/init $BM_KERNELARGS"
+FARM: google
needs:
- debian/arm64_test
- job: testing:arm64
@@ -116,8 +120,9 @@ msm:apq8016:
- .baremetal-igt-arm64
stage: msm
variables:
+DEVICE_TYPE: apq8016-sbc-usb-host
DRIVER_NAME: msm
-BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/apq8016-sbc-usb-host.dtb
+BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/${DEVICE_TYPE}.dtb
GPU_VERSION: apq8016
# disabling unused clocks congests with the MDSS runtime PM trying to
# disable those clocks and causes boot to fail.
@@ -132,9 +137,10 @@ msm:apq8096:
- .baremetal-igt-arm64
stage: msm
variables:
+DEVICE_TYPE: apq8096-db820c
DRIVER_NAME: msm
BM_KERNEL_EXTRA_ARGS: maxcpus=2
-BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/apq8096-db820c.dtb
+BM_DTB: https://${PIPELINE_ARTIFACTS_BASE}/arm64/${DEVICE_TYPE}.dtb
GPU_VERSION: apq8096
RUNNER_TAG: google-freedreno-db820c
script:
@@ -146,6 +152,7 @@ msm:sdm845:
stage: msm
parallel: 6
variables:
+DEVICE_TYPE: sdm845-cheza-r3
DRIVER_NAME: msm
BM_KERNEL: https://${PIPELINE_ARTIFACTS_BASE}/arm64/cheza-kernel
GPU_VERSION: sdm845
Re: [PATCH v3 4/6] drm/ci: uprev IGT
On 28/05/2024 23:40, Vignesh Raman wrote:
test-list.txt and test-list-full.txt are not generated for
cross-builds and they are required by drm-ci for testing
arm32 targets. This is fixed in igt-gpu-tools. So uprev
IGT to include the commit which fixes this issue. Also
disable building xe driver tests for non-intel platforms.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
v2:
- Split IGT uprev to seperate patch.
v3:
- No changes.
---
drivers/gpu/drm/ci/build-igt.sh | 4
drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
index b7d2a49a6db3..eddb5f782a5e 100644
--- a/drivers/gpu/drm/ci/build-igt.sh
+++ b/drivers/gpu/drm/ci/build-igt.sh
@@ -45,6 +45,10 @@ MESON_OPTIONS="-Doverlay=disabled\
-Dlibunwind=enabled \
-Dprefix=/igt"
+if [[ "$KERNEL_ARCH" = "arm64" ]] || [[ "$KERNEL_ARCH" = "arm" ]]; then
+MESON_OPTIONS="$MESON_OPTIONS -Dxe_driver=disabled"
+fi
+
mkdir -p /igt
meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 8f32de63d92e..1b29c3b6406b 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -5,7 +5,7 @@ variables:
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
- IGT_VERSION: d2af13d9f5be5ce23d996e4afd3e45990f5ab977
+ IGT_VERSION: 0df7b9b97f9da0e364f5ee30fe331004b8c86b56
DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git
DEQP_RUNNER_GIT_TAG: v0.15.0
Re: [PATCH v3 5/6] drm/ci: skip driver specific tests
On 28/05/2024 23:40, Vignesh Raman wrote: Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Reviewed-by: Dmitry Baryshkov Signed-off-by: Vignesh Raman Acked-by: Helen Koike --- v2: - Skip xe tests for amdgpu and virtio. v3: - No changes. --- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15 ++- drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 11 ++- drivers/gpu/drm/ci/xfails/i915-apl-skips.txt| 11 ++- drivers/gpu/drm/ci/xfails/i915-cml-skips.txt| 9 + drivers/gpu/drm/ci/xfails/i915-glk-skips.txt| 11 ++- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt| 11 ++- drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt| 11 ++- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt| 11 ++- .../gpu/drm/ci/xfails/mediatek-mt8173-skips.txt | 12 .../gpu/drm/ci/xfails/mediatek-mt8183-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt | 11 +++ drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt | 14 +- .../msm-sc7180-trogdor-kingoftown-skips.txt | 12 .../msm-sc7180-trogdor-lazor-limozeen-skips.txt | 12 drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt | 12 .../gpu/drm/ci/xfails/rockchip-rk3288-skips.txt | 17 - .../gpu/drm/ci/xfails/rockchip-rk3399-skips.txt | 15 +++ .../gpu/drm/ci/xfails/virtio_gpu-none-skips.txt | 16 +++- 19 files changed, 229 insertions(+), 10 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt index e2c538a0f954..21d26d5e67c2 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt @@ -1,2 +1,15 @@ # Suspend to RAM seems to be broken on this machine -.*suspend.* \ No newline at end of file +.*suspend.* + +# Skip driver specific tests +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# Skip intel specific tests +gem_.* +i915_.* +xe_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt index fe55540a3f9a..1e80987cf584 100644 --- a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt @@ -1,4 +1,13 @@ # Suspend to RAM seems to be broken on this machine .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt index 3430b215c06e..0104f2ffa8ba 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt @@ -3,4 +3,13 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters # This is cascading issues -kms_3d \ No newline at end of file +kms_3d + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt index 6d3d7ddc377f..398ebe163ad0 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt @@ -1,2 +1,11 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* diff --git a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt index 4c7d00ce14bc..4f5419d62170 100644 --- a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt @@ -2,4 +2,13 @@ .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* diff --git a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt index 4c7d00ce14bc..4f5419d62170 100644 --- a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt @@ -2,4 +2,13 @@ .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No
Re: [PATCH v3 6/6] drm/ci: update xfails for the new testlist
On 29/05/2024 06:49, Vignesh Raman wrote: Hi Dmitry, On 29/05/24 13:30, Dmitry Baryshkov wrote: On Wed, May 29, 2024 at 08:10:49AM +0530, Vignesh Raman wrote: Now the testlist is used from IGT build, so update xfails with the new testlist. Set the timeout of all i915 jobs to 1h30m since some jobs takes more than 1 hour to complete. Reviewed-by: Dmitry Baryshkov This had an explicit '# msm testlist' at the end. Please don't drop important parts of tags. I didn't review fails/flakes for other platforms. Sorry I missed it. Will ask Helen to add the tag back when she merges this. I'll add it Acked-by: Helen Koike Thanks. Helen Regards, Vignesh Signed-off-by: Vignesh Raman --- v2: - Set the timeout of all i915 jobs to 1h30m and updated expectations file. v3: - Add a link to the email reporting the flaky tests to the maintainers. --- drivers/gpu/drm/ci/test.yml | 6 +- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 41 ++-- .../drm/ci/xfails/amdgpu-stoney-flakes.txt | 7 + .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 18 ++ drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 31 .../gpu/drm/ci/xfails/i915-amly-flakes.txt | 9 + drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 11 ++ drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 46 +++-- drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 6 + drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 15 ++ drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 38 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 + drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 41 +++- drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 7 + drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 15 ++ drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 42 ++--- drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 7 +- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 25 +++ drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 77 drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 17 ++ drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 63 --- drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 6 + drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 11 ++ .../drm/ci/xfails/mediatek-mt8173-fails.txt | 30 ++- .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 11 ++ .../drm/ci/xfails/mediatek-mt8173-skips.txt | 4 + .../drm/ci/xfails/mediatek-mt8183-fails.txt | 21 +-- .../drm/ci/xfails/mediatek-mt8183-skips.txt | 4 + .../gpu/drm/ci/xfails/meson-g12b-fails.txt | 24 +-- .../gpu/drm/ci/xfails/meson-g12b-skips.txt | 4 + .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 12 +- .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 4 + .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 7 + .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 6 + .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 12 ++ .../msm-sc7180-trogdor-kingoftown-fails.txt | 175 +- .../msm-sc7180-trogdor-kingoftown-flakes.txt | 8 + .../msm-sc7180-trogdor-kingoftown-skips.txt | 7 + ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 175 +- ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 6 + ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 4 + .../gpu/drm/ci/xfails/msm-sdm845-fails.txt | 38 +--- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 25 ++- .../gpu/drm/ci/xfails/msm-sdm845-skips.txt | 7 + .../drm/ci/xfails/rockchip-rk3288-fails.txt | 62 +-- .../drm/ci/xfails/rockchip-rk3288-skips.txt | 4 + .../drm/ci/xfails/rockchip-rk3399-fails.txt | 83 + .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 13 +- .../drm/ci/xfails/rockchip-rk3399-skips.txt | 4 + drivers/gpu/drm/ci/xfails/update-xfails.py | 4 +- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 94 +++--- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 4 + 53 files changed, 1023 insertions(+), 388 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml index 2615f67f6aa3..322cce714657 100644 --- a/drivers/gpu/drm/ci/test.yml +++ b/drivers/gpu/drm/ci/test.yml @@ -191,6 +191,7 @@ rockchip:rk3399: extends: - .lava-igt:x86_64 stage: i915 + timeout: "1h30m" variables:
[syzbot] [mm?] general protection fault in dequeue_hugetlb_folio_nodemask
Hello,
syzbot found the following issue on:
HEAD commit:0e1980c40b6e Add linux-next specific files for 20240531
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=166086f298
kernel config: https://syzkaller.appspot.com/x/.config?x=d9c3ca4e54577b88
dashboard link: https://syzkaller.appspot.com/bug?extid=c019f68a83ef9b456444
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian)
2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12f4094a98
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e1e43298
Downloadable assets:
disk image:
https://storage.googleapis.com/syzbot-assets/44fb1d8b5978/disk-0e1980c4.raw.xz
vmlinux:
https://storage.googleapis.com/syzbot-assets/a66ce5caf0b2/vmlinux-0e1980c4.xz
kernel image:
https://storage.googleapis.com/syzbot-assets/8992fc8fe046/bzImage-0e1980c4.xz
The issue was bisected to:
commit cd94d1b182d2986378550c9087571991bfee01d4
Author: Mario Limonciello
Date: Thu May 2 18:32:17 2024 +
dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11
users
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=176121c298
console output: https://syzkaller.appspot.com/x/log.txt?x=10e121c298
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c019f68a83ef9b456...@syzkaller.appspotmail.com
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU
13.0.4/13.0.11 users")
Oops: general protection fault, probably for non-canonical address
0xdc000489: [#1] PREEMPT SMP KASAN PTI
KASAN: probably user-memory-access in range
[0x2448-0x244f]
CPU: 1 PID: 5089 Comm: syz-executor257 Not tainted
6.10.0-rc1-next-20240531-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/02/2024
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48
83 7c 24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f
85 58 09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026ef
RDX: RSI: RDI:
RBP: c900035ef858 R08: 81f5e070 R09: f520006bdee8
R10: dc00 R11: f520006bdee8 R12:
R13: dc00 R14: R15:
FS: 64010380() GS:8880b950() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 005fdeb8 CR3: 7bd96000 CR4: 003506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
alloc_hugetlb_folio_nodemask+0xae/0x3f0 mm/hugetlb.c:2603
memfd_alloc_folio+0x15e/0x390 mm/memfd.c:75
memfd_pin_folios+0x1066/0x1720 mm/gup.c:3864
udmabuf_create+0x658/0x11c0 drivers/dma-buf/udmabuf.c:353
udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:420 [inline]
udmabuf_ioctl+0x304/0x4f0 drivers/dma-buf/udmabuf.c:451
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5151a7a369
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffd962ee9e8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd962eebb8 RCX: 7f5151a7a369
RDX: 22c0 RSI: 40187542 RDI: 0003
RBP: 7f5151aed610 R08: 7ffd962eebb8 R09: 7ffd962eebb8
R10: 7ffd962eebb8 R11: 0246 R12: 0001
R13: 7ffd962eeba8 R14: 0001 R15: 0001
Modules linked in:
---[ end trace ]---
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48
83 7c 24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f
85 58 09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026ef
RDX: RSI:
Re: [PATCH v3 0/6] drm/ci: uprev mesa/IGT and generate testlist
On 28/05/2024 23:40, Vignesh Raman wrote: Uprev mesa and IGT to the latest version and stop vendoring the testlist into the kernel. Instead, use the testlist from the IGT build to ensure we do not miss renamed or newly added tests. Update the xfails with the latest testlist run. Add farm variable and update device type variable. https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1187556 Vignesh Raman (6): drm/ci: uprev mesa version drm/ci: add farm variable drm/ci: generate testlist from build drm/ci: uprev IGT drm/ci: skip driver specific tests drm/ci: update xfails for the new testlist drivers/gpu/drm/ci/build-igt.sh | 41 +- drivers/gpu/drm/ci/build.sh |6 +- drivers/gpu/drm/ci/container.yml | 12 +- drivers/gpu/drm/ci/gitlab-ci.yml | 46 +- drivers/gpu/drm/ci/igt_runner.sh |9 +- drivers/gpu/drm/ci/image-tags.yml |2 +- drivers/gpu/drm/ci/lava-submit.sh |4 +- drivers/gpu/drm/ci/test.yml | 17 +- drivers/gpu/drm/ci/testlist.txt | 2761 - .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 41 +- .../drm/ci/xfails/amdgpu-stoney-flakes.txt|7 + .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 33 +- drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 31 + .../gpu/drm/ci/xfails/i915-amly-flakes.txt|9 + drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 22 +- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 46 +- drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt |6 + drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 38 + drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt |6 + drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 23 + drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 41 +- drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt |7 + drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 42 +- drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt |7 +- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 36 +- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 77 +- drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 28 +- drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 63 +- drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt |6 + drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 22 +- .../drm/ci/xfails/mediatek-mt8173-fails.txt | 30 +- .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 11 + .../drm/ci/xfails/mediatek-mt8173-skips.txt | 16 + .../drm/ci/xfails/mediatek-mt8183-fails.txt | 21 +- .../drm/ci/xfails/mediatek-mt8183-skips.txt | 18 + .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 24 +- .../gpu/drm/ci/xfails/meson-g12b-skips.txt| 18 + .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 12 +- .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 15 + .../gpu/drm/ci/xfails/msm-apq8096-fails.txt |7 + .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt |6 + .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 26 +- .../msm-sc7180-trogdor-kingoftown-fails.txt | 175 +- .../msm-sc7180-trogdor-kingoftown-flakes.txt |8 + .../msm-sc7180-trogdor-kingoftown-skips.txt | 19 + ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 175 +- ...m-sc7180-trogdor-lazor-limozeen-flakes.txt |6 + ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 16 + .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 38 +- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 25 +- .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 19 + .../drm/ci/xfails/rockchip-rk3288-fails.txt | 62 +- .../drm/ci/xfails/rockchip-rk3288-skips.txt | 21 +- .../drm/ci/xfails/rockchip-rk3399-fails.txt | 83 +- .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 13 +- .../drm/ci/xfails/rockchip-rk3399-skips.txt | 19 + drivers/gpu/drm/ci/xfails/update-xfails.py|4 +- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 94 +- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 20 +- 61 files changed, 1348 insertions(+), 3194 deletions(-) delete mode 100644 drivers/gpu/drm/ci/testlist.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt create mode 100644 drivers/gp
Re: [syzbot] [mm?] general protection fault in dequeue_hugetlb_folio_nodemask
On 6/6/2024 09:39, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0e1980c40b6e Add linux-next specific files for 20240531
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=166086f298
kernel config: https://syzkaller.appspot.com/x/.config?x=d9c3ca4e54577b88
dashboard link: https://syzkaller.appspot.com/bug?extid=c019f68a83ef9b456444
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian)
2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12f4094a98
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e1e43298
Downloadable assets:
disk image:
https://storage.googleapis.com/syzbot-assets/44fb1d8b5978/disk-0e1980c4.raw.xz
vmlinux:
https://storage.googleapis.com/syzbot-assets/a66ce5caf0b2/vmlinux-0e1980c4.xz
kernel image:
https://storage.googleapis.com/syzbot-assets/8992fc8fe046/bzImage-0e1980c4.xz
The issue was bisected to:
commit cd94d1b182d2986378550c9087571991bfee01d4
Author: Mario Limonciello
Date: Thu May 2 18:32:17 2024 +
dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11
users
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=176121c298
console output: https://syzkaller.appspot.com/x/log.txt?x=10e121c298
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c019f68a83ef9b456...@syzkaller.appspotmail.com
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU
13.0.4/13.0.11 users")
Oops: general protection fault, probably for non-canonical address
0xdc000489: [#1] PREEMPT SMP KASAN PTI
KASAN: probably user-memory-access in range
[0x2448-0x244f]
CPU: 1 PID: 5089 Comm: syz-executor257 Not tainted
6.10.0-rc1-next-20240531-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
04/02/2024
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026ef
RDX: RSI: RDI:
RBP: c900035ef858 R08: 81f5e070 R09: f520006bdee8
R10: dc00 R11: f520006bdee8 R12:
R13: dc00 R14: R15:
FS: 64010380() GS:8880b950() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 005fdeb8 CR3: 7bd96000 CR4: 003506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
alloc_hugetlb_folio_nodemask+0xae/0x3f0 mm/hugetlb.c:2603
memfd_alloc_folio+0x15e/0x390 mm/memfd.c:75
memfd_pin_folios+0x1066/0x1720 mm/gup.c:3864
udmabuf_create+0x658/0x11c0 drivers/dma-buf/udmabuf.c:353
udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:420 [inline]
udmabuf_ioctl+0x304/0x4f0 drivers/dma-buf/udmabuf.c:451
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5151a7a369
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6
48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48
c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffd962ee9e8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd962eebb8 RCX: 7f5151a7a369
RDX: 22c0 RSI: 40187542 RDI: 0003
RBP: 7f5151aed610 R08: 7ffd962eebb8 R09: 7ffd962eebb8
R10: 7ffd962eebb8 R11: 0246 R12: 0001
R13: 7ffd962eeba8 R14: 0001 R15: 0001
Modules linked in:
---[ end trace ]---
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026e
Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
On Thu, Jun 6, 2024 at 5:51 AM Cristian Ciocaltea
wrote:
>
> On 6/6/24 2:22 AM, Rob Herring wrote:
> > On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
> >> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
> >> found on Rockchip RK3588 SoC family.
> >>
> >> Since RK3588 uses different clocks than previous Rockchip SoCs and also
> >> requires a couple of reset lines and some additional properties, provide
> >> the required changes in the binding to accommodate all variants.
> >>
> >> Signed-off-by: Cristian Ciocaltea
> >> ---
> >> .../display/rockchip/rockchip,dw-hdmi.yaml | 127
> >> +++--
> >> 1 file changed, 90 insertions(+), 37 deletions(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> index 2aac62219ff6..60d6b815227f 100644
> >> ---
> >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> +++
> >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> @@ -10,12 +10,10 @@ maintainers:
> >>- Mark Yao
> >>
> >> description: |
> >> - The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> >> - with a companion PHY IP.
> >> -
> >> -allOf:
> >> - - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> >> - - $ref: /schemas/sound/dai-common.yaml#
> >> + For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
> >> + HDMI 1.4 TX controller IP with a companion PHY IP.
> >> + The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel
> >> (QP)
> >> + TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP
> >> block.
> >>
> >> properties:
> >>compatible:
> >> @@ -25,6 +23,7 @@ properties:
> >>- rockchip,rk3328-dw-hdmi
> >>- rockchip,rk3399-dw-hdmi
> >>- rockchip,rk3568-dw-hdmi
> >> + - rockchip,rk3588-dw-hdmi
> >>
> >>reg-io-width:
> >> const: 4
> >> @@ -40,36 +39,6 @@ properties:
> >>A 1.8V supply that powers up the SoC internal circuitry. The pin
> >> name on the
> >>SoC usually is HDMI_TX_AVDD_1V8.
> >>
> >> - clocks:
> >> -minItems: 2
> >> -items:
> >> - - {}
> >> - - {}
> >> - # The next three clocks are all optional, but shall be specified in
> >> this
> >> - # order when present.
> >> - - description: The HDMI CEC controller main clock
> >> - - description: Power for GRF IO
> >> - - description: External clock for some HDMI PHY (old clock name,
> >> deprecated)
> >> - - description: External clock for some HDMI PHY (new name)
> >> -
> >> - clock-names:
> >> -minItems: 2
> >> -items:
> >> - - {}
> >> - - {}
> >> - - enum:
> >> - - cec
> >> - - grf
> >> - - vpll
> >> - - ref
> >> - - enum:
> >> - - grf
> >> - - vpll
> >> - - ref
> >> - - enum:
> >> - - vpll
> >> - - ref
> >> -
> >>ddc-i2c-bus:
> >> $ref: /schemas/types.yaml#/definitions/phandle
> >> description:
> >> @@ -131,13 +100,97 @@ properties:
> >> required:
> >>- compatible
> >>- reg
> >> - - reg-io-width
> >>- clocks
> >>- clock-names
> >>- interrupts
> >>- ports
> >>- rockchip,grf
> >>
> >> +allOf:
> >> + - $ref: /schemas/sound/dai-common.yaml#
> >> + - if:
> >> + properties:
> >> +compatible:
> >> + contains:
> >> +enum:
> >> + - rockchip,rk3588-dw-hdmi
> >> +then:
> >> + properties:
> >> +reg:
> >> + maxItems: 1
> >> +
> >> +clocks:
> >> + minItems: 1
> >> + items:
> >> +- description: APB system interface clock
> >> +# The next clocks are optional, but shall be specified in this
> >> +# order when present.
> >> +- description: TMDS/FRL link clock
> >> +- description: EARC RX biphase clock
> >> +- description: Reference clock
> >> +- description: Audio interface clock
> >> +- description: Video datapath clock
> >> +
> >> +clock-names:
> >> + minItems: 1
> >> + items:
> >> +- const: pclk
> >> +- enum: [hdp, earc, ref, aud, hclk_vo1]
> >> +- enum: [earc, ref, aud, hclk_vo1]
> >> +- enum: [ref, aud, hclk_vo1]
> >> +- enum: [aud, hclk_vo1]
> >> +- const: hclk_vo1
> >> +
> >> +resets:
> >> + minItems: 2
> >> + maxItems: 2
> >> +
> >> +reset-names:
> >> + items:
> >> +- const: ref
> >> +- const: hdp
> >> +
> >> +interrupts:
> >> + minItems: 1
> >> + maxItems: 5
> >> +
> >> +rockchip,vo1_grf:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description:
Re: [RFC PATCH 6/8] rust: drm: gem: Add GEM object abstraction
Hi Danilo, Lina
> On 20 May 2024, at 14:24, Danilo Krummrich wrote:
>
> From: Asahi Lina
>
> The DRM GEM subsystem is the DRM memory management subsystem used by
> most modern drivers. Add a Rust abstraction to allow Rust DRM driver
> implementations to use it.
>
> Signed-off-by: Asahi Lina
> Co-developed-by: Danilo Krummrich
> Signed-off-by: Danilo Krummrich
> ---
> rust/bindings/bindings_helper.h | 1 +
> rust/helpers.c | 23 ++
> rust/kernel/drm/drv.rs | 4 +-
> rust/kernel/drm/gem/mod.rs | 406
> rust/kernel/drm/mod.rs | 1 +
> 5 files changed, 433 insertions(+), 2 deletions(-)
> create mode 100644 rust/kernel/drm/gem/mod.rs
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index c591811ccb67..b245db8d5a87 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/rust/helpers.c b/rust/helpers.c
> index dc2405772b1a..30e86bf00337 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -20,6 +20,7 @@
> * Sorted alphabetically.
> */
>
> +#include
> #include
> #include
> #include
> @@ -302,6 +303,28 @@ u64 rust_helper_pci_resource_len(struct pci_dev *pdev,
> int barnr)
> return pci_resource_len(pdev, barnr);
> }
>
> +#ifdef CONFIG_DRM
> +
> +void rust_helper_drm_gem_object_get(struct drm_gem_object *obj)
> +{
> + drm_gem_object_get(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_get);
> +
> +void rust_helper_drm_gem_object_put(struct drm_gem_object *obj)
> +{
> + drm_gem_object_put(obj);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_gem_object_put);
> +
> +__u64 rust_helper_drm_vma_node_offset_addr(struct drm_vma_offset_node *node)
> +{
> + return drm_vma_node_offset_addr(node);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_drm_vma_node_offset_addr);
> +
> +#endif
> +
> /*
> * `bindgen` binds the C `size_t` type as the Rust `usize` type, so we can
> * use it in contexts where Rust expects a `usize` like slice (array) indices.
> diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs
> index c5a63663ea21..063b420f57e5 100644
> --- a/rust/kernel/drm/drv.rs
> +++ b/rust/kernel/drm/drv.rs
> @@ -113,7 +113,7 @@ pub struct AllocOps {
> }
>
> /// Trait for memory manager implementations. Implemented internally.
> -pub trait AllocImpl: Sealed {
> +pub trait AllocImpl: Sealed + drm::gem::IntoGEMObject {
> /// The C callback operations for this memory manager.
> const ALLOC_OPS: AllocOps;
> }
> @@ -243,7 +243,7 @@ pub fn new(parent: &device::Device) -> Result {
> drm: drm::device::Device::new(parent, &vtable)?,
> registered: false,
> vtable,
> -fops: Default::default(), // TODO: GEM abstraction
> +fops: drm::gem::create_fops(),
> _pin: PhantomPinned,
> _p: PhantomData,
> })
> diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
> new file mode 100644
> index ..4cd85d5f1df8
> --- /dev/null
> +++ b/rust/kernel/drm/gem/mod.rs
> @@ -0,0 +1,406 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM GEM API
> +//!
> +//! C header:
> [`include/linux/drm/drm_gem.h`](../../../../include/linux/drm/drm_gem.h)
> +
> +use alloc::boxed::Box;
> +
> +use crate::{
> +alloc::flags::*,
> +bindings,
> +drm::{device, drv, file},
> +error::{to_result, Result},
> +prelude::*,
> +};
> +use core::{marker::PhantomPinned, mem, ops::Deref, ops::DerefMut};
> +
> +/// GEM object functions, which must be implemented by drivers.
> +pub trait BaseDriverObject: Sync + Send + Sized {
> +/// Create a new driver data object for a GEM object of a given size.
> +fn new(dev: &device::Device, size: usize) -> impl
> PinInit;
> +
> +/// Open a new handle to an existing object, associated with a File.
> +fn open(
> +_obj: &<::Driver as drv::Driver>::Object,
> +_file: &file::File<<::Driver as
> drv::Driver>::File>,
I wonder if these can be put into a type alias? As in,
type File = file::File<<::Driver as
drv::Driver>::File>;
etc
That would clean things up a bit.
> +) -> Result {
> +Ok(())
> +}
> +
> +/// Close a handle to an existing object, associated with a File.
> +fn close(
> +_obj: &<::Driver as drv::Driver>::Object,
> +_file: &file::File<<::Driver as
> drv::Driver>::File>,
> +) {
> +}
> +}
> +
> +/// Trait that represents a GEM object subtype
> +pub trait IntoGEMObject: Sized + crate::private::Sealed {
> +/// Owning driver for this type
> +type Driver: drv::Driver;
> +
> +/// Returns a reference to the raw `drm_gem_object` structure, which
> must be valid as long as
> +/// this owning object is valid.
> +fn gem_obj(&self) -> &bindings::drm_gem_object;
> +
> +/// Converts a pointer to a `drm_gem_object` into
Re: [PATCH v4] drm/msm/a6xx: use __unused__ to fix compiler warnings for gen7_* includes
On Wed, Jun 05, 2024 at 11:34:15AM -0700, Abhinav Kumar wrote:
> GCC diagnostic pragma method throws below warnings in some of the versions
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown
> option after '#pragma GCC diagnostic' kind [-Wpragmas]
> #pragma GCC diagnostic ignored "-Wunused-const-variable"
> ^
> In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:18:0:
> drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h:924:19: warning:
> 'gen7_0_0_external_core_regs' defined but not used [-Wunused-variable]
> static const u32 *gen7_0_0_external_core_regs[] = {
> ^
> In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:19:0:
> drivers/gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h:748:19: warning:
> 'gen7_2_0_external_core_regs' defined but not used [-Wunused-variable]
> static const u32 *gen7_2_0_external_core_regs[] = {
> ^
> In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:20:0:
> drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1188:43: warning:
> 'gen7_9_0_sptp_clusters' defined but not used [-Wunused-variable]
> static struct gen7_sptp_cluster_registers gen7_9_0_sptp_clusters[] = {
> ^
> drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1438:19: warning:
> 'gen7_9_0_external_core_regs' defined but not used [-Wunused-variable]
> static const u32 *gen7_9_0_external_core_regs[] = {
>
> Remove GCC version dependency by using __unused__ for the unused gen7_*
> includes.
>
> Changes in v2:
> - Fix the warnings in the commit text
> - Use __attribute((__unused__)) instead of local assignment
>
> changes in v3:
> - drop the Link from the auto add
>
> changes in v4:
> - replace __attribute((__unused__)) with __always_unused
>
> Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx")
> Suggested-by: Rob Clark
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/a6xx: Fix A702 UBWC mode
On Thu, Jun 06, 2024 at 01:10:49PM +0200, Konrad Dybcio wrote:
> UBWC_MODE is a one-bit-wide field, so a value of 2 is obviously bogus.
>
> Replace it with the correct value (0).
>
> Fixes: 18397519cb62 ("drm/msm/adreno: Add A702 support")
> Reported-by: Connor Abbott
> Closes:
> https://lore.kernel.org/linux-arm-msm/CACu1E7FTN=kwaDJMNiTmFspALzj2+Q-nvsN5ugi=vz4rdug...@mail.gmail.com/
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
