[PATCH] drm/doc: internals: remove section on PCI legacy support

[Randy Dunlap]

The functions that were described in this section of
drm-internals.rst were removed in NOV-2023, along with all of the
kernel-doc comments in the source file. This now causes a
docs build warning, so remove that section of the documentation also.

drivers/gpu/drm/drm_pci.c:1: warning: no structured comments found

Fixes: 2504c7ec728b ("drm: Remove source code for non-KMS drivers")
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/gpu/drm-internals.rst |   12 
 1 file changed, 12 deletions(-)

diff -- a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -153,18 +153,6 @@ Managed Resources
 .. kernel-doc:: include/drm/drm_managed.h
:internal:
 
-Bus-specific Device Registration and PCI Support
-
-
-A number of functions are provided to help with device registration. The
-functions deal with PCI and platform devices respectively and are only
-provided for historical reasons. These are all deprecated and shouldn't
-be used in new drivers. Besides that there's a few helpers for pci
-drivers.
-
-.. kernel-doc:: drivers/gpu/drm/drm_pci.c
-   :export:
-
 Open/Close, File Operations and IOCTLs
 ==
 

Re: [PATCH 3/6] drm/amdgpu: prefer snprintf over sprintf

[kernel test robot]

Hi Jani,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7 next-20240111]
[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/Jani-Nikula/drm-nouveau-acr-ga102-remove-unused-but-set-variable/20240111-014206
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/fea7a52924f98b1ac24f4a7e6ba21d7754422430.1704908087.git.jani.nikula%40intel.com
patch subject: [PATCH 3/6] drm/amdgpu: prefer snprintf over sprintf
config: sparc64-allmodconfig 
(https://download.01.org/0day-ci/archive/20240112/202401121126.i9vgrvmb-...@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240112/202401121126.i9vgrvmb-...@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/202401121126.i9vgrvmb-...@intel.com/

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c: In function 
'amdgpu_gfx_kiq_init_ring':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:61: warning: '%d' directive 
>> output may be truncated writing between 1 and 10 bytes into a region of size 
>> between 0 and 8 [-Wformat-truncation=]
 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
 | ^~
   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:50: note: directive argument in 
the range [0, 2147483647]
 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
 |  ^
   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:9: note: 'snprintf' output 
between 12 and 41 bytes into a destination of size 16
 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
 | ^~~
 333 |  xcc_id, ring->me, ring->pipe, ring->queue);
 |  ~~


vim +332 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c

   306  
   307  int amdgpu_gfx_kiq_init_ring(struct amdgpu_device *adev,
   308   struct amdgpu_ring *ring,
   309   struct amdgpu_irq_src *irq, int xcc_id)
   310  {
   311  struct amdgpu_kiq *kiq = &adev->gfx.kiq[xcc_id];
   312  int r = 0;
   313  
   314  spin_lock_init(&kiq->ring_lock);
   315  
   316  ring->adev = NULL;
   317  ring->ring_obj = NULL;
   318  ring->use_doorbell = true;
   319  ring->xcc_id = xcc_id;
   320  ring->vm_hub = AMDGPU_GFXHUB(xcc_id);
   321  ring->doorbell_index =
   322  (adev->doorbell_index.kiq +
   323   xcc_id * adev->doorbell_index.xcc_doorbell_range)
   324  << 1;
   325  
   326  r = amdgpu_gfx_kiq_acquire(adev, ring, xcc_id);
   327  if (r)
   328  return r;
   329  
   330  ring->eop_gpu_addr = kiq->eop_gpu_addr;
   331  ring->no_scheduler = true;
 > 332  snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d",
   333   xcc_id, ring->me, ring->pipe, ring->queue);
   334  r = amdgpu_ring_init(adev, ring, 1024, irq, 
AMDGPU_CP_KIQ_IRQ_DRIVER0,
   335   AMDGPU_RING_PRIO_DEFAULT, NULL);
   336  if (r)
   337  dev_warn(adev->dev, "(%d) failed to init kiq ring\n", 
r);
   338  
   339  return r;
   340  }
   341  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 07/11] drm/mediatek: Add secure layer config support for ovl

[林睿祥]

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

[Darrick J. Wong]

On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote:
> On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"  
> > wrote:
> > 
> > > > > Fixing this will require a bit of an API change, and prefeably 
> > > > > sorting out
> > > > > the hwpoison story for pages vs folio and where it is placed in the 
> > > > > shmem
> > > > > API.  For now use this one liner to disable large folios.
> > > > > 
> > > > > Reported-by: Darrick J. Wong 
> > > > > Signed-off-by: Christoph Hellwig 
> > > > 
> > > > Can someone who knows more about shmem.c than I do please review
> > > > https://lore.kernel.org/linux-xfs/20240103084126.513354-4-...@lst.de/
> > > > so that I can feel slightly more confident as hch and I sort through the
> > > > xfile.c issues?
> > > > 
> > > > For this patch,
> > > > Reviewed-by: Darrick J. Wong 
> > > 
> > > ...except that I'm still getting 2M THPs even with this enabled, so I
> > > guess either we get to fix it now, or create our own private tmpfs mount
> > > so that we can pass in huge=never, similar to what i915 does. :(
> > 
> > What is "this"?  Are you saying that $Subject doesn't work, or that the
> > above-linked please-review patch doesn't work?
> 
> shmem pays no attention to the mapping_large_folio_support() flag,
> so the proposed fix doesn't work.  It ought to, but it has its own way
> of doing it that predates mapping_large_folio_support existing.

Yep.  It turned out to be easier to fix xfile.c to deal with large
folios than I thought it would be.  Or so I think.  We'll see what
happens on fstestscloud overnight.

--D

Re: [v2 2/2] drm/panel: Add support for Novatek NT36672E panel driver

[Jessica Zhang]

On 1/8/2024 1:59 AM, Ritesh Kumar wrote:

Add support for the 1080x2408 Novatek NT36672E video mode
DSI panel driver.

Signed-off-by: Ritesh Kumar 


Reviewed-by: Jessica Zhang 



---
v2: Fixed review comments from Krzysztof
   - renamed the panel driver file to reflect that this is a novatek IC.
   - adjusted internal function names to reflect the same.
   - corrected compatible string accordingly.
   - updated CONFIG for the same.
---
  drivers/gpu/drm/panel/Kconfig |  10 +
  drivers/gpu/drm/panel/Makefile|   1 +
  .../gpu/drm/panel/panel-novatek-nt36672e.c| 643 ++
  3 files changed, 654 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672e.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..052aaef7d6a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -429,6 +429,16 @@ config DRM_PANEL_NOVATEK_NT36672A
  around the Novatek NT36672A display controller, such as some
  Tianma panels used in a few Xiaomi Poco F1 mobile phones.
  
+config DRM_PANEL_NOVATEK_NT36672E

+   tristate "Novatek NT36672E DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Novatek NT36672E DSI 
Video Mode
+ LCD panel module. The panel has a resolution of 1080x2408 and uses 24 
bit
+ RGB per pixel.
+
  config DRM_PANEL_NOVATEK_NT39016
tristate "Novatek NT39016 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..93a544a8937c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35560) += 
panel-novatek-nt35560.o
  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36523) += panel-novatek-nt36523.o
  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672E) += panel-novatek-nt36672e.o
  obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
  obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
  obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c 
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
new file mode 100644
index ..d4e85c2fc899
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -0,0 +1,643 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+static const char * const regulator_names[] = {
+   "vddi",
+   "avdd",
+   "avee",
+};
+
+static const unsigned long regulator_enable_loads[] = {
+   62000,
+   10,
+   10,
+};
+
+static const unsigned long regulator_disable_loads[] = {
+   80,
+   100,
+   100,
+};
+
+struct panel_desc {
+   const struct drm_display_mode *display_mode;
+   u32 width_mm;
+   u32 height_mm;
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+   const char *panel_name;
+   int (*init_sequence)(struct mipi_dsi_device *dsi);
+};
+
+struct nt36672e_panel {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+   struct gpio_desc *reset_gpio;
+   struct regulator_bulk_data supplies[3];
+   const struct panel_desc *desc;
+};
+
+static inline struct nt36672e_panel *to_nt36672e_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct nt36672e_panel, panel);
+}
+
+static int nt36672e_1080x2408_60hz_init(struct mipi_dsi_device *dsi)
+{
+   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x10);
+   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
+   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xc0, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xc1, 0x89, 0x28, 0x00, 0x08, 0x00, 0xaa, 
0x02,
+   0x0e, 0x00, 0x2b, 0x00, 0x07, 0x0d, 0xb7, 0x0c, 
0xb7);
+
+   mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x1b, 0xa0);
+   mipi_dsi_dcs_write_seq(dsi, 0xff, 0x20);
+   mipi_dsi_dcs_write_seq(dsi, 0xfb, 0x01);
+   mipi_dsi_dcs_write_seq(dsi, 0x01, 0x66);
+   mipi_dsi_dcs_write_seq(dsi, 0x06, 0x40);
+   mipi_dsi_dcs_write_seq(dsi, 0x07, 0x38);
+   mipi_dsi_dcs_write_seq(dsi, 0x2f, 0x83);
+   mipi_dsi_dcs_write_seq(dsi, 0x69, 0x91);
+   mipi_dsi_dcs_write_seq(dsi, 0x95, 0xd1);
+   mipi_dsi_dcs_write_seq(dsi, 0x96, 0xd1);
+   mipi_dsi_dcs_write_seq(dsi, 0xf2, 0x64);
+   mipi_dsi_dcs_write_seq(dsi, 0xf3, 0x54);
+   mipi_dsi_dcs_write_seq(dsi, 0xf4, 0x64);
+

Re: [PATCH 3/7] drm/amd/display: Add handling for new "active color format" property

[Werner Sembach]

Hi,

Am 10.01.24 um 18:15 schrieb Andri Yngvason:

Hi Werner,

mið., 10. jan. 2024 kl. 13:14 skrifaði Werner Sembach 
:

Hi,

Am 10.01.24 um 14:09 schrieb Daniel Vetter:

On Wed, 10 Jan 2024 at 13:53, Andri Yngvason  wrote:

mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :

On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:

+ /* Extract information from crtc to communicate it to userspace as 
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ struct dc_stream_state *stream;
+
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ stream = dm_new_crtc_state->stream;
+
+ if (stream) {
+ 
drm_connector_set_active_color_format_property(connector,
+ 
convert_dc_pixel_encoding_into_drm_color_format(
+ 
dm_new_crtc_state->stream->timing.pixel_encoding));
+ }
+ } else {
+ drm_connector_set_active_color_format_property(connector, 
0);

Just realized an even bigger reason why your current design doesn't work:
You don't have locking here.

And you cannot grab the required lock, which is
drm_dev->mode_config.mutex, because that would result in deadlocks. So
this really needs to use the atomic state based design I've described.


Maybe we should just drop "actual color format" and instead fail the
modeset if the "preferred color format" property cannot be satisfied?
It seems like the simplest thing to do here, though it is perhaps less
convenient for userspace. In that case, the "preferred color format"
property should just be called "color format".

Yeah that's more in line with how other atomic properties work. This
way userspace can figure out what works with a TEST_ONLY commit too.
And for this to work you probably want to have an "automatic" setting
too.
-Sima

The problem with TEST_ONLY probing is that color format settings are
interdependent: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_966634

So changing any other setting may require every color format to be TEST_ONLY
probed again.


If we put a bit map containing the possible color formats into
drm_mode_mode_info (I'm thinking that it could go into flags), we'd be
able to eliminate a bunch of combinations early on. Do you think that
would make things more bearable?


That would eliminate some, but note that for example YCBCR444 needs a faster 
pixel clock then YCBCR420, so it's interdependent with everything else that 
changes the required pixel clock like bpc, resolution and refresh rate.


So the config space is n-dimensional with no "right angle box" clearly 
separating working from non working combinations.


But I just had the idea:

Currently in KDE and Gnome UI you first select the resolution, to then wee what 
refresh rates are available. So I guess this concept could be appended to color 
properties -> Define a sequence for the different properties to be applied 
across all drivers and as soon as you select one, the next property in the 
sequence is TEST_ONLYed.


e.g.:

1. Select resolution -> Available refresh rates are updated

2. Select refresh rate -> Available color formats are updated

3. Select color format -> Available bpc are updated

etc.

So you can't select a bpc that doesn't fit your current color format. Changing 
color format can change the available bpc. One maybe counter intuitive thing 
here is that color format "auto" might not have all bpc settings available, as 
auto will for example actually be RGB which has higher pixel clock requirements 
then ycbcr420. And in this model, color format is always decided first. Or vice 
versa if bpc is decided to be before color format in the sequence.




I'm thinking, something like this:
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 128d09138ceb3..59980803cb89e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -124,6 +124,13 @@ extern "C" {
  #define  DRM_MODE_FLAG_PIC_AR_256_135 \
 (DRM_MODE_PICTURE_ASPECT_256_135<<19)

+/* Possible color formats (4 bits) */
+#define DRM_MODE_FLAG_COLOR_FORMAT_MASK (0x0f << 22)
+#define DRM_MODE_FLAG_COLOR_FORMAT_RGB (1 << 22)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR444 (1 << 23)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR422 (1 << 24)
+#define DRM_MODE_FLAG_COLOR_FORMAT_YCBCR420 (1 << 25)
+
  #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
  DRM_MODE_FLAG_NHSYNC | \
  DRM_MODE_FLAG_PVSYNC | \
@@ -136,7 +143,8 @@ extern "C" {
  DRM_MODE_FLAG_HSKEW |  \
   

Re: [PATCH] drm/msm/mdss: specify cfg bandwidth for SDM670

[Richard Acayan]

On Fri, Dec 15, 2023 at 03:32:22AM +0200, Dmitry Baryshkov wrote:
> Lower the requested CFG bus bandwidth for the SDM670 platform. The
> default value is 153600 kBps, which is twice as big as required by the
> platform according to the vendor kernel.
>
> Fixes: a55c8ff252d3 ("drm/msm/mdss: Handle the reg bus ICC path")
> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/gpu/drm/msm/msm_mdss.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 455b2e3a0cdd..35423d10aafa 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -562,6 +562,7 @@ static const struct msm_mdss_data sdm670_data = {
>   .ubwc_enc_version = UBWC_2_0,
>   .ubwc_dec_version = UBWC_2_0,
>   .highest_bank_bit = 1,
> + .reg_bus_bw = 76800,

This seems to be the bandwidth applied to the "cpu-cfg" path, but it is
not in the device tree yet and is not allowed by schema (for no
particular reason). In sdm670.dtsi, it would be defined as:

<&gladiator_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_DISPLAY_CFG 0>

Furthermore, I have not yet emailed the patches that I use to test the
display on SDM670, namely, the panel driver and device tree changes for
the Pixel 3a. Nevertheless, this does not break anything, even with the
interconnect path and everything needed to test.

Tested-by: Richard Acayan 

>  };
>  
>  static const struct msm_mdss_data sdm845_data = {
> -- 
> 2.39.2
>

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

[Matthew Wilcox]

On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"  
> wrote:
> 
> > > > Fixing this will require a bit of an API change, and prefeably sorting 
> > > > out
> > > > the hwpoison story for pages vs folio and where it is placed in the 
> > > > shmem
> > > > API.  For now use this one liner to disable large folios.
> > > > 
> > > > Reported-by: Darrick J. Wong 
> > > > Signed-off-by: Christoph Hellwig 
> > > 
> > > Can someone who knows more about shmem.c than I do please review
> > > https://lore.kernel.org/linux-xfs/20240103084126.513354-4-...@lst.de/
> > > so that I can feel slightly more confident as hch and I sort through the
> > > xfile.c issues?
> > > 
> > > For this patch,
> > > Reviewed-by: Darrick J. Wong 
> > 
> > ...except that I'm still getting 2M THPs even with this enabled, so I
> > guess either we get to fix it now, or create our own private tmpfs mount
> > so that we can pass in huge=never, similar to what i915 does. :(
> 
> What is "this"?  Are you saying that $Subject doesn't work, or that the
> above-linked please-review patch doesn't work?

shmem pays no attention to the mapping_large_folio_support() flag,
so the proposed fix doesn't work.  It ought to, but it has its own way
of doing it that predates mapping_large_folio_support existing.

Re: [PATCH 2/2] xfs: disable large folio support in xfile_create

[Andrew Morton]

On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"  wrote:

> > > Fixing this will require a bit of an API change, and prefeably sorting out
> > > the hwpoison story for pages vs folio and where it is placed in the shmem
> > > API.  For now use this one liner to disable large folios.
> > > 
> > > Reported-by: Darrick J. Wong 
> > > Signed-off-by: Christoph Hellwig 
> > 
> > Can someone who knows more about shmem.c than I do please review
> > https://lore.kernel.org/linux-xfs/20240103084126.513354-4-...@lst.de/
> > so that I can feel slightly more confident as hch and I sort through the
> > xfile.c issues?
> > 
> > For this patch,
> > Reviewed-by: Darrick J. Wong 
> 
> ...except that I'm still getting 2M THPs even with this enabled, so I
> guess either we get to fix it now, or create our own private tmpfs mount
> so that we can pass in huge=never, similar to what i915 does. :(

What is "this"?  Are you saying that $Subject doesn't work, or that the
above-linked please-review patch doesn't work?

Re: [PATCH v1] drm/msm/dp: correct configure Colorimetry Indicator Field at MISC0

[Kuogee Hsieh]

On 1/10/2024 3:38 PM, Dmitry Baryshkov wrote:

On Wed, 10 Jan 2024 at 22:18, Kuogee Hsieh  wrote:

MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At current
implementation, Colorimetry Indicator Field of MISC0 is not configured
correctly. This patch add support of RGB formats Colorimetry.

https://docs.kernel.org/process/submitting-patches.html#describe-your-changes

Also the commit message doesn't provide any details or what was incorrect.


Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/dp/dp_ctrl.c  |  5 ++--
  drivers/gpu/drm/msm/dp/dp_link.c  | 26 -
  drivers/gpu/drm/msm/dp/dp_panel.c | 48 +++
  drivers/gpu/drm/msm/dp/dp_panel.h |  2 ++
  4 files changed, 73 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 77a8d93..2ef89fb 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
- * Copyright (c) 2012-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012-2023, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights 
reserved
   */

  #define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
@@ -172,7 +173,7 @@ static void dp_ctrl_configure_source_params(struct 
dp_ctrl_private *ctrl)

 tb = dp_link_get_test_bits_depth(ctrl->link,
 ctrl->panel->dp_mode.bpp);
-   cc = dp_link_get_colorimetry_config(ctrl->link);
+   cc = dp_panel_get_misc_colorimetry_val(ctrl->panel);
 dp_catalog_ctrl_config_misc(ctrl->catalog, cc, tb);
 dp_panel_timing_cfg(ctrl->panel);
  }
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index 98427d4..21fa1a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2012-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights 
reserved
   */

  #define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
@@ -12,6 +13,11 @@

  #define DP_TEST_REQUEST_MASK   0x7F

+enum dynamic_range {
+   DP_DYNAMIC_RANGE_RGB_VESA,
+   DP_DYNAMIC_RANGE_RGB_CEA,
+};
+
  enum audio_sample_rate {
 AUDIO_SAMPLE_RATE_32_KHZ= 0x00,
 AUDIO_SAMPLE_RATE_44_1_KHZ  = 0x01,
@@ -1083,6 +1089,7 @@ int dp_link_process_request(struct dp_link *dp_link)
  int dp_link_get_colorimetry_config(struct dp_link *dp_link)
  {
 u32 cc;
+   enum dynamic_range dr;
 struct dp_link_private *link;

 if (!dp_link) {
@@ -1092,14 +1099,21 @@ int dp_link_get_colorimetry_config(struct dp_link 
*dp_link)

 link = container_of(dp_link, struct dp_link_private, dp_link);

-   /*
-* Unless a video pattern CTS test is ongoing, use RGB_VESA
-* Only RGB_VESA and RGB_CEA supported for now
-*/
+   /* unless a video pattern CTS test is ongoing, use CEA_VESA */
 if (dp_link_is_video_pattern_requested(link))
-   cc = link->dp_link.test_video.test_dyn_range;
+   dr = link->dp_link.test_video.test_dyn_range;

test_dyn_range has the value of (dpcd[DP_TEST_MISC0] &
DP_TEST_DYNAMIC_RANGE_CEA), so it can not be assigned to dr.

I don't feel like this has been tested.


yes, you are correct.

This code derived from down stream code.

I will fix it.


 else
-   cc = DP_TEST_DYNAMIC_RANGE_VESA;
+   dr = DP_DYNAMIC_RANGE_RGB_VESA;
+
+   /* Only RGB_VESA and RGB_CEA supported for now */
+   switch (dr) {
+   case DP_DYNAMIC_RANGE_RGB_CEA:
+   cc = BIT(2);

No undefined magic, please.


+   break;
+   case DP_DYNAMIC_RANGE_RGB_VESA:
+   default:
+   cc = 0;
+   }

 return cc;
  }
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 127f6af..785bb59 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * Copyright (c) 2012-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights 
reserved
   */

  #include "dp_panel.h"
@@ -386,6 +387,53 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
 return 0;
  }

+/*
+ * Mapper function which outputs colorimetry to be used for a
+ * given colorspace value when misc field of MSA is used to
+ * change the colorimetry. Currently only RGB formats have been
+ * added. This API will be extended to YUV once it's supported on DP.
+ */
+u8 dp_panel_get_misc_colorimetry_val(struct dp_panel *dp_panel)
+{
+   u8 colorimetry;
+   u32 colorspace;
+   u32 cc;

Re: disable large folios for shmem file used by xfs xfile

[Daniel Gomez]

On Wed, Jan 10, 2024 at 4:35 PM Matthew Wilcox  wrote:
>
> On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote:
> > Quoting Joonas Lahtinen (2024-01-10 17:20:24)
> > > However we specifically pass "huge=within_size" to vfs_kern_mount when
> > > creating a private mount of tmpfs for the purpose of i915 created
> > > allocations.
> > >
> > > Older hardware also had some address hashing bugs where 2M aligned
> > > memory caused a lot of collisions in TLB so we don't enable it always.
> > >
> > > You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function
> > > i915_gemfs_init for details and references.
> > >
> > > So in short, functionality wise we should be fine either default
> > > for using 2M pages or not. If they become the default, we'd probably
> > > want an option that would still be able to prevent them for performance
> > > regression reasons on older hardware.
> >
> > To maybe write out my concern better:
> >
> > Is there plan to enable huge pages by default in shmem?
>
> Not in the next kernel release, but eventually the plan is to allow
> arbitrary order folios to be used in shmem.  So you could ask it to create
> a 256kB folio for you, if that's the right size to manage memory in.
>
> How shmem and its various users go about choosing the right size is not
> quite clear to me yet.  Perhaps somebody else will do it before I get
> to it; I have a lot of different sub-projects to work on at the moment,
> and shmem isn't blocking any of them.  And I have a sneaking suspicion
> that more work is needed in the swap code to deal with arbitrary order
> folios, so that's another reason for me to delay looking at this ;-)

I have sent large folios support for shmem for the write and fallocate
path some releases ago. The main problem I was facing was a current
upstream problem with huge pages when seeking holes/data (fstests
generic/285 and generic/436). The strategy suggested was to use large
folios in an opportunistic way based on the file size. This hit the
same problem we currently have with huge pages and I considered that a
regression. We have made some progress to fix seeking in huge pages
upstream but is not yet finished. I can send the patches tomorrow for
further discussion.

>

Re: [PATCH 10/10] accel/ivpu: Remove deprecated DRM_IVPU_PARAM_CONTEXT_PRIORITY

[Jeffrey Hugo]

On 1/10/2024 7:33 AM, Jacek Lawrynowicz wrote:

On 05.01.2024 18:29, Jeffrey Hugo wrote:

On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:

From: "Wachowski, Karol" 

DRM_IVPU_PARAM_CONTEXT_PRIORITY has been deprecated because it
has been replaced with DRM_IVPU_JOB_PRIORITY levels set with
submit IOCTL and was unused anyway.

Signed-off-by: Wachowski, Karol 
Signed-off-by: Jacek Lawrynowicz 
---
   drivers/accel/ivpu/ivpu_drv.c | 11 ---
   drivers/accel/ivpu/ivpu_drv.h |  1 -
   drivers/accel/ivpu/ivpu_job.c |  3 +++
   include/uapi/drm/ivpu_accel.h | 21 -
   4 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index ec66c2c39877..546c0899bb9e 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -177,9 +177,6 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, 
void *data, struct drm_f
   case DRM_IVPU_PARAM_CONTEXT_BASE_ADDRESS:
   args->value = vdev->hw->ranges.user.start;
   break;
-    case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
-    args->value = file_priv->priority;
-    break;
   case DRM_IVPU_PARAM_CONTEXT_ID:
   args->value = file_priv->ctx.id;
   break;
@@ -219,17 +216,10 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, 
void *data, struct drm_f
     static int ivpu_set_param_ioctl(struct drm_device *dev, void *data, struct 
drm_file *file)
   {
-    struct ivpu_file_priv *file_priv = file->driver_priv;
   struct drm_ivpu_param *args = data;
   int ret = 0;
     switch (args->param) {
-    case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
-    if (args->value <= DRM_IVPU_CONTEXT_PRIORITY_REALTIME)
-    file_priv->priority = args->value;
-    else
-    ret = -EINVAL;
-    break;
   default:
   ret = -EINVAL;
   }
@@ -258,7 +248,6 @@ static int ivpu_open(struct drm_device *dev, struct 
drm_file *file)
   }
     file_priv->vdev = vdev;
-    file_priv->priority = DRM_IVPU_CONTEXT_PRIORITY_NORMAL;
   kref_init(&file_priv->ref);
   mutex_init(&file_priv->lock);
   diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 9b6e336626e3..7a6bc1918780 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -146,7 +146,6 @@ struct ivpu_file_priv {
   struct mutex lock; /* Protects cmdq */
   struct ivpu_cmdq *cmdq[IVPU_NUM_ENGINES];
   struct ivpu_mmu_context ctx;
-    u32 priority;
   bool has_mmu_faults;
   };
   diff --git a/drivers/accel/ivpu/ivpu_job.c b/drivers/accel/ivpu/ivpu_job.c
index 7206cf9cdb4a..82e40bb4803c 100644
--- a/drivers/accel/ivpu/ivpu_job.c
+++ b/drivers/accel/ivpu/ivpu_job.c
@@ -488,6 +488,9 @@ int ivpu_submit_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
   if (params->engine > DRM_IVPU_ENGINE_COPY)
   return -EINVAL;
   +    if (params->priority > DRM_IVPU_JOB_PRIORITY_REALTIME)
+    return -EINVAL;
+
   if (params->buffer_count == 0 || params->buffer_count > 
JOB_MAX_BUFFER_COUNT)
   return -EINVAL;
   diff --git a/include/uapi/drm/ivpu_accel.h b/include/uapi/drm/ivpu_accel.h
index de1944e42c65..cc9a0504ee2f 100644
--- a/include/uapi/drm/ivpu_accel.h
+++ b/include/uapi/drm/ivpu_accel.h
@@ -13,7 +13,7 @@ extern "C" {
   #endif
     #define DRM_IVPU_DRIVER_MAJOR 1
-#define DRM_IVPU_DRIVER_MINOR 0
+#define DRM_IVPU_DRIVER_MINOR 1


I remember when this driver was going through initial review before acceptance, 
Oded mentioned that the DRM driver version mechanism was deprecated and to not 
use it.  Based on that, it seems like you should not be incrementing the minor 
number.


I wanted to use minor version in tests to verify the UAPI but this is not very 
important. I can leave this as is.


     #define DRM_IVPU_GET_PARAM  0x00
   #define DRM_IVPU_SET_PARAM  0x01
@@ -64,11 +64,18 @@ extern "C" {
     #define DRM_IVPU_PLATFORM_TYPE_SILICON    0
   +/* Deprecated - to be removed */
   #define DRM_IVPU_CONTEXT_PRIORITY_IDLE    0
   #define DRM_IVPU_CONTEXT_PRIORITY_NORMAL    1
   #define DRM_IVPU_CONTEXT_PRIORITY_FOCUS    2
   #define DRM_IVPU_CONTEXT_PRIORITY_REALTIME  3


$SUBJECT suggests these are being removed, not just deprecated.  Also, 
shouldn't DRM_IVPU_PARAM_CONTEXT_PRIORITY which is a few lines above this be 
deprecated/removed/something?


OK, I'll correct the subject and add "deprecated" comment to 
DRM_IVPU_PARAM_CONTEXT_PRIORITY.


   +#define DRM_IVPU_JOB_PRIORITY_DEFAULT  0
+#define DRM_IVPU_JOB_PRIORITY_IDLE 1
+#define DRM_IVPU_JOB_PRIORITY_NORMAL   2
+#define DRM_IVPU_JOB_PRIORITY_FOCUS    3
+#define DRM_IVPU_JOB_PRIORITY_REALTIME 4
+
   /**
    * DRM_IVPU_CAP_METRIC_STREAMER
    *
@@ -286,6 +293,18 @@ struct drm_ivpu_submit {
    * to be executed. The offset has to be 8-byte aligned.
    */
   __u32 commands_offset;
+
+    /**
+ * @priority:
+ *
+ * Prior

[Bug 218368] amdgpu crashes on loading on both kernel-6.6.9 and kernel-6.1.69 at cold boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=218368

--- Comment #3 from nvaert1986 (nvaert1...@hotmail.com) ---
P.S.: The GPU is a Sapphire (AMD) Radeon 7900 XTX, I figured that might be
useful information. If any other information is required, then please let me
know.

-- 
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 0/3] Update LLVM Phabricator and Bugzilla links

[Fangrui Song]

On Wed, Jan 10, 2024 at 4:46 PM Kees Cook  wrote:
>
> On Tue, Jan 09, 2024 at 03:16:28PM -0700, Nathan Chancellor wrote:
> > This series updates all instances of LLVM Phabricator and Bugzilla links
> > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue
> > shortlinks respectively.
> >
> > I split up the Phabricator patch into BPF selftests and the rest of the
> > kernel in case the BPF folks want to take it separately from the rest of
> > the series, there are obviously no dependency issues in that case. The
> > Bugzilla change was mechanical enough and should have no conflicts.
> >
> > I am aiming this at Andrew and CC'ing other lists, in case maintainers
> > want to chime in, but I think this is pretty uncontroversial (famous
> > last words...).
> >
> > ---
> > Nathan Chancellor (3):
> >   selftests/bpf: Update LLVM Phabricator links
> >   arch and include: Update LLVM Phabricator links
> >   treewide: Update LLVM Bugzilla links
> >
> >  arch/arm64/Kconfig |  4 +--
> >  arch/powerpc/Makefile  |  4 +--
> >  arch/powerpc/kvm/book3s_hv_nested.c|  2 +-
> >  arch/riscv/Kconfig |  2 +-
> >  arch/riscv/include/asm/ftrace.h|  2 +-
> >  arch/s390/include/asm/ftrace.h |  2 +-
> >  arch/x86/power/Makefile|  2 +-
> >  crypto/blake2b_generic.c   |  2 +-
> >  drivers/firmware/efi/libstub/Makefile  |  2 +-
> >  drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c   |  2 +-
> >  drivers/media/test-drivers/vicodec/codec-fwht.c|  2 +-
> >  drivers/regulator/Kconfig  |  2 +-
> >  include/asm-generic/vmlinux.lds.h  |  2 +-
> >  include/linux/compiler-clang.h |  2 +-
> >  lib/Kconfig.kasan  |  2 +-
> >  lib/raid6/Makefile |  2 +-
> >  lib/stackinit_kunit.c  |  2 +-
> >  mm/slab_common.c   |  2 +-
> >  net/bridge/br_multicast.c  |  2 +-
> >  security/Kconfig   |  2 +-
> >  tools/testing/selftests/bpf/README.rst | 32 
> > +++---
> >  tools/testing/selftests/bpf/prog_tests/xdpwall.c   |  2 +-
> >  .../selftests/bpf/progs/test_core_reloc_type_id.c  |  2 +-
> >  23 files changed, 40 insertions(+), 40 deletions(-)
> > ---
> > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
> > change-id: 20240109-update-llvm-links-d03f9d649e1e
> >
> > Best regards,
> > --
> > Nathan Chancellor 
> >
>
> Excellent! Thanks for doing this. I spot checked a handful I was
> familiar with and everything looks good to me.
>
> Reviewed-by: Kees Cook 
>
> --
> Kees Cook
>

These reviews.llvm.org links would definitely be kept like
https://lists.llvm.org/pipermail/llvm-dev/ or cfe-dev links
(discussions have been migrated to Discourse).
However, I agree that the github repo link looks more official. I have
clicked a few links and they look good.

Since I maintain reviews.llvm.org and created the static archive [1],

Acked-by: Fangrui Song 

[1]: https://discourse.llvm.org/t/llvm-phabricator-turndown/76137

-- 
宋方睿

Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links

[Nathan Chancellor]

Hi Alexei,

On Thu, Jan 11, 2024 at 12:00:50PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor  wrote:
> >
> > Hi Yonghong,
> >
> > On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> > >
> > > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > > has been abandoned in favor of GitHub pull requests. While the majority
> > > > of links in the kernel sources still work because of the work Fangrui
> > > > has done turning the dynamic Phabricator instance into a static archive,
> > > > there are some issues with that work, so preemptively convert all the
> > > > links in the kernel sources to point to the commit on GitHub.
> > > >
> > > > Most of the commits have the corresponding differential review link in
> > > > the commit message itself so there should not be any loss of fidelity in
> > > > the relevant information.
> > > >
> > > > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > > > in the area.
> > > >
> > > > Link: 
> > > > https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > > > Signed-off-by: Nathan Chancellor 
> > >
> > > Ack with one nit below.
> > >
> > > Acked-by: Yonghong Song 
> >
> > 
> >
> > > > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > > >   .. code-block:: console
> > > > -  test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073? 
> > > > unexpected error: -4007
> > > > +  test_xdpwall:FAIL:Does LLVM have 
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > > >  unexpected error: -4007
> > > > -__ https://reviews.llvm.org/D109073
> > > > +__ 
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> > >
> > > To be consistent with other links, could you add the missing last alnum 
> > > '5' to the above link?
> >
> > Thanks a lot for catching this and providing an ack. Andrew, could you
> > squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
> 
> Please send a new patch.
> We'd like to take all bpf patches through the bpf tree to avoid conflicts.

Very well, I've sent a standalone v2 on top of bpf-next:

https://lore.kernel.org/20240111-bpf-update-llvm-phabricator-links-v2-1-9a7ae976b...@kernel.org/

Andrew, just drop selftests-bpf-update-llvm-phabricator-links.patch
altogether in that case, the other two patches are fine to go via -mm I
think.

Cheers,
Nathan

Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links

[Alexei Starovoitov]

On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor  wrote:
>
> Hi Yonghong,
>
> On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> >
> > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > has been abandoned in favor of GitHub pull requests. While the majority
> > > of links in the kernel sources still work because of the work Fangrui
> > > has done turning the dynamic Phabricator instance into a static archive,
> > > there are some issues with that work, so preemptively convert all the
> > > links in the kernel sources to point to the commit on GitHub.
> > >
> > > Most of the commits have the corresponding differential review link in
> > > the commit message itself so there should not be any loss of fidelity in
> > > the relevant information.
> > >
> > > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > > in the area.
> > >
> > > Link: 
> > > https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > > Signed-off-by: Nathan Chancellor 
> >
> > Ack with one nit below.
> >
> > Acked-by: Yonghong Song 
>
> 
>
> > > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > >   .. code-block:: console
> > > -  test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073? 
> > > unexpected error: -4007
> > > +  test_xdpwall:FAIL:Does LLVM have 
> > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > >  unexpected error: -4007
> > > -__ https://reviews.llvm.org/D109073
> > > +__ 
> > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> >
> > To be consistent with other links, could you add the missing last alnum '5' 
> > to the above link?
>
> Thanks a lot for catching this and providing an ack. Andrew, could you
> squash this update into selftests-bpf-update-llvm-phabricator-links.patch?

Please send a new patch.
We'd like to take all bpf patches through the bpf tree to avoid conflicts.

Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links

[Nathan Chancellor]

Hi Yonghong,

On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> 
> On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > has been abandoned in favor of GitHub pull requests. While the majority
> > of links in the kernel sources still work because of the work Fangrui
> > has done turning the dynamic Phabricator instance into a static archive,
> > there are some issues with that work, so preemptively convert all the
> > links in the kernel sources to point to the commit on GitHub.
> > 
> > Most of the commits have the corresponding differential review link in
> > the commit message itself so there should not be any loss of fidelity in
> > the relevant information.
> > 
> > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > in the area.
> > 
> > Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > Signed-off-by: Nathan Chancellor 
> 
> Ack with one nit below.
> 
> Acked-by: Yonghong Song 



> > @@ -304,6 +304,6 @@ from running test_progs will look like:
> >   .. code-block:: console
> > -  test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073? 
> > unexpected error: -4007
> > +  test_xdpwall:FAIL:Does LLVM have 
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> >  unexpected error: -4007
> > -__ https://reviews.llvm.org/D109073
> > +__ 
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> 
> To be consistent with other links, could you add the missing last alnum '5' 
> to the above link?

Thanks a lot for catching this and providing an ack. Andrew, could you
squash this update into selftests-bpf-update-llvm-phabricator-links.patch?

diff --git a/tools/testing/selftests/bpf/README.rst 
b/tools/testing/selftests/bpf/README.rst
index b9a493f66557..e56034abb3c2 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -306,4 +306,4 @@ from running test_progs will look like:
 
   test_xdpwall:FAIL:Does LLVM have 
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
 unexpected error: -4007
 
-__ 
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
+__ 
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5

Re: [PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[Xaver Hugl]

Great, thank you!

Am Do., 11. Jan. 2024 um 19:05 Uhr schrieb André Almeida <
andrealm...@igalia.com>:

> Em 11/01/2024 14:59, Xaver Hugl escreveu:
> > Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser
> > mailto:cont...@emersion.fr>>:
> >
> > Are we sure that all drivers handle these two props properly with
> async
> > page-flips? This is a new codepath not taken by the legacy uAPI.
> >
> > I've only tested on amdgpu so far. Afacs the other drivers that would
> need
> > testing / that support atomic and async pageflips are
> > - i915
> > - noueveau (though atomic is disabled by default, so maybe it doesn't
> > matter?)
> > - vc4
> > - atmel-hlcdc
> >
> > The first two I can test, the latter I don't have the hardware for. I
> > don't know if I can
> > extensively test fb_damage_clips either / how I'd even know if it's
> > being applied
> > correctly, but in the worst case I'd expect the driver to not do the
> > optimizations the
> > property allows.
> >
> > As an alternative to this, would it be okay to expose a driver hook for
> > optional
> > driver-specific checks that drm_atomic_set_property can delegate to, and
> > only
> > allow this with the properties and hardware that's been tested? Then more
> > properties (like cursor position changes on amdgpu) could be easily
> > added later
> > on too.
>
> I'm working on some mechanism to allow overlay planes on amdgpu, and I
> think I can add your needs to it. I'll share in the mailing list when I
> have something more concrete.
>

Re: [PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[Xaver Hugl]

Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser :

> Are we sure that all drivers handle these two props properly with async
> page-flips? This is a new codepath not taken by the legacy uAPI.
>
I've only tested on amdgpu so far. Afacs the other drivers that would need
testing / that support atomic and async pageflips are
- i915
- noueveau (though atomic is disabled by default, so maybe it doesn't
matter?)
- vc4
- atmel-hlcdc

The first two I can test, the latter I don't have the hardware for. I don't
know if I can
extensively test fb_damage_clips either / how I'd even know if it's being
applied
correctly, but in the worst case I'd expect the driver to not do the
optimizations the
property allows.

As an alternative to this, would it be okay to expose a driver hook for
optional
driver-specific checks that drm_atomic_set_property can delegate to, and
only
allow this with the properties and hardware that's been tested? Then more
properties (like cursor position changes on amdgpu) could be easily added
later
on too.

[PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[Xaver Hugl]

Like with FB_ID, the driver never has to do bandwidth validation to use
these properties, so there's no reason not to allow them.

Signed-off-by: Xaver Hugl 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index aee4a65d4959..06d476f5a746 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1108,7 +1108,9 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
-   if (async_flip && prop != config->prop_fb_id) {
+   if (async_flip && prop != config->prop_fb_id &&
+   prop != config->prop_in_fence_fd &&
+   prop != config->prop_fb_damage_clips) {
ret = drm_atomic_plane_get_property(plane, plane_state,
prop, &old_val);
ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
-- 
2.43.0

Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel

[Linus Walleij]

On Thu, Jan 11, 2024 at 4:28 PM Luca Weiss  wrote:

> In some internal documentation it says "LCD Driver IC" "HX83112A" and I
> don't see any reference to Truly 5P65 anywhere.

In the Android directory I pointed to I see this file:
HX83112_Android_Driver/Truly_5p65_module_fw/UpdateFW.bat

(Notice the 5p65 fw dir is *inside* the HX82112 dir)

And in that file:
adb push TRULY_5P65_1080_2160_HX83112A_D01C01.bin
/system/etc/firmware/Himax_firmware.bin

Clearly indicating that they are pushing a Truly 5P65 firmware into
the Himax display firmware directory.

To be fair, that is the driver for the touchscreen part of HX83112A,
but ... Truly is a well known manufacturer of display controllers?

But... given that you have a @fairphone.com mal address and
a working relationship with them, can't you just ask?

> On their website they have this sentence:

All OEMs want to look like everything is their own product. It is
business as usual.

Further on the same note since I guess you have a datasheet)
please bring in #defines for the commands (the first byte in the
write sequences, for examples:

+   mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x02);
+   mipi_dsi_dcs_write_seq(dsi, 0xd8,
+  0xaa, 0xff, 0xff, 0xff, 0xff, 0xff, 0xaa, 0xff,
+  0xff, 0xff, 0xff, 0xff);
+   mipi_dsi_dcs_write_seq(dsi, 0xbd, 0x03);

Clearly 0xbd is HX83112_CMD_SETREGBANK?
(This is easily spotted from the similar structure in the
existing panel-himax-hx8394.c.) So please add #defines
for all commands you know, especially if you have a datasheet
because we reviewers don't have them and "it's just magic
bytes" isn't very compelling. It adds a lot to understanding.

I strongly suspect other Himax displays such as HX8394 to
be using a Truly controller as well, hence the similarities.

In a datasheet for their TFT800480-84-V1-E display controller
Truly kept the init sequence name of void LCD_INIT_HX8290(void)
for example.

Yours,
Linus Walleij

Re: [PATCH v1 0/8] drm/ci: Add support for GPU and display testing

[Daniel Stone]

Hi Vignesh,

On Wed, 10 Jan 2024 at 10:47, Vignesh Raman  wrote:
> On 09/01/24 19:08, Daniel Stone wrote:
> > A better sequencing would be something like:
> >1. add ANX7625 config
> >2. refactor _existing_ MTK display jobs to use YAML includes, change
> > the existing job name, and rename the existing xfail set, remove
> > IGT_FORCE_DRIVER from the script since it's now set by the job
> >3. add MTK Panfrost+PVR GPU jobs with new xfails, add xfail entry to
> > MAINTAINERS
> >4+5: same as 2+3 but for Amlogic
> >6+7: same as 2+3 but for Rockchip
> >
> > Then the separate rename/update xfail commits just disappear, as does
> > the removal of IGT_FORCE_DRIVER, because it's just done incrementally
> > as part of the commits which change the related functionality. It's
> > extremely important that every change can work standalone, instead of
> > introducing intermediate breakage which is only fixed in later commits
> > in the series.
>
> Thank you for reviewing the patches. I agree, will follow this sequence
> and send a v2 version.

Alongside Rob's patch to add msm-specific tests to the runlist, we'd
need to add the Panfrost-specific tests. Whilst we're here, we might
as well add the vc4/v3d/etnaviv/lima tests so they can use it in
future.

Panfrost should also skip kms_.* tests - since it's not a KMS driver,
it can't run the KMS tests, so there's no point in trying.

Cheers,
Daniel

Re: [PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[André Almeida]

Em 11/01/2024 14:59, Xaver Hugl escreveu:
Am Do., 11. Jan. 2024 um 18:13 Uhr schrieb Simon Ser 
mailto:cont...@emersion.fr>>:


Are we sure that all drivers handle these two props properly with async
page-flips? This is a new codepath not taken by the legacy uAPI.

I've only tested on amdgpu so far. Afacs the other drivers that would need
testing / that support atomic and async pageflips are
- i915
- noueveau (though atomic is disabled by default, so maybe it doesn't 
matter?)

- vc4
- atmel-hlcdc

The first two I can test, the latter I don't have the hardware for. I 
don't know if I can
extensively test fb_damage_clips either / how I'd even know if it's 
being applied
correctly, but in the worst case I'd expect the driver to not do the 
optimizations the

property allows.

As an alternative to this, would it be okay to expose a driver hook for 
optional
driver-specific checks that drm_atomic_set_property can delegate to, and 
only

allow this with the properties and hardware that's been tested? Then more
properties (like cursor position changes on amdgpu) could be easily 
added later

on too.


I'm working on some mechanism to allow overlay planes on amdgpu, and I 
think I can add your needs to it. I'll share in the mailing list when I 
have something more concrete.

Re: [PATCH v1] drm/msm/dp: remove mdss_dp_test_bit_depth_to_bpc()

[Abhinav Kumar]

On 1/11/2024 9:14 AM, Kuogee Hsieh wrote:

mdss_dp_test_bit_depth_to_bpc() can be replace by
mdss_dp_test_bit_depth_to_bpp() / 3. Hence remove it.

Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/dp/dp_debug.c |  2 +-
  drivers/gpu/drm/msm/dp/dp_link.h  | 23 ---
  2 files changed, 1 insertion(+), 24 deletions(-)



Reviewed-by: Abhinav Kumar 

[Bug 218368] amdgpu crashes on loading on both kernel-6.6.9 and kernel-6.1.69 at cold boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=218368

--- Comment #2 from nvaert1986 (nvaert1...@hotmail.com) ---
Jan 11 18:20:27  pc02 kernel: WARNING: CPU: 24 PID: 468 at 0xc06b26f1
Jan 11 18:20:27  pc02 kernel: Modules linked in: amdgpu(+) drm_ttm_helper
snd_hda_codec_hdmi ttm amdxcp drm_exec gpu_sched i2c_algo_bit kvm_amd drm_buddy
snd_hda_intel mt7921e drm_suballoc_helper snd_intel_dspcfg mt7921_common
drm_display_helper mt792x_lib snd_hda_codec cec mt76_connac_lib igc
snd_hda_core mt>
Jan 11 18:20:27  pc02 kernel: CPU: 24 PID: 468 Comm: (udev-worker) Tainted: G  
 W  O   6.6.9-gentoo #2
Jan 11 18:20:27  pc02 kernel: Hardware name: ASUS System Product Name/ROG STRIX
X670E-A GAMING WIFI, BIOS 1807 12/14/2023
Jan 11 18:20:27  pc02 kernel: RIP: 0010:0xc06b26f1
Jan 11 18:20:27  pc02 kernel: Code: c0 74 33 48 8b 4e 10 48 83 39 00 74 29 89
d1 48 8d 04 88 8b 08 85 c9 74 11 f0 ff 08 74 07 31 c0 e9 14 eb 60 cf e9 9f fd
ff ff <0f> 0b b8 ea ff ff ff e9 03 eb 60 cf b8 ea ff ff ff e9 f9 ea 60 cf
Jan 11 18:20:27  pc02 kernel: RSP: 0018:b7a6028bfb38 EFLAGS: 00010246
Jan 11 18:20:27  pc02 kernel: RAX: 9db705a29f8c RBX: 9db717219098 RCX:

Jan 11 18:20:27  pc02 kernel: RDX: 0003 RSI: 9db7172278f0 RDI:
9db71720
Jan 11 18:20:27  pc02 kernel: RBP: 9db7172100f8 R08:  R09:
9dc63d897b40
Jan 11 18:20:27  pc02 kernel: R10: 0003 R11: 9050ef28 R12:
9db7172104c8
Jan 11 18:20:27  pc02 kernel: R13: 9db717200010 R14: 9db71720 R15:
ff01
Jan 11 18:20:27  pc02 kernel: FS:  7ff1f6fa5340()
GS:9dc63dc0() knlGS:
Jan 11 18:20:27  pc02 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jan 11 18:20:27  pc02 kernel: CR2: 7f657532049c CR3: 0001141f6000 CR4:
00f50ee0
Jan 11 18:20:27  pc02 kernel: PKRU: 5554
Jan 11 18:20:27  pc02 kernel: Call Trace:
Jan 11 18:20:27  pc02 kernel:  
Jan 11 18:20:27  pc02 kernel:  ? 0x8f18ee7f
Jan 11 18:20:27  pc02 kernel:  ? 0xc06b26f1
Jan 11 18:20:27  pc02 kernel:  ? 0x8fc8705e
Jan 11 18:20:27  pc02 kernel:  ? 0x8fcaba9a
Jan 11 18:20:27  pc02 kernel:  ? 0x8fcabb77
Jan 11 18:20:27  pc02 kernel:  ? 0x8fe0120a
Jan 11 18:20:27  pc02 kernel:  ? 0xc06b26f1
Jan 11 18:20:27  pc02 kernel:  ? 0x8fcc1205
Jan 11 18:20:27  pc02 kernel:  0xc063a3d7
Jan 11 18:20:27  pc02 kernel:  0xc06267f1
Jan 11 18:20:27  pc02 kernel:  ? 0x8f1b88a9
Jan 11 18:20:27  pc02 kernel:  0xc062c1a1
Jan 11 18:20:27  pc02 kernel:  0xc0623824
Jan 11 18:20:27  pc02 kernel:  0x8f6b8754
Jan 11 18:20:27  pc02 kernel:  0x8f7f82ce
Jan 11 18:20:27  pc02 kernel:  ? 0x8f7f8760
Jan 11 18:20:27  pc02 kernel:  0x8f7f84ce
Jan 11 18:20:27  pc02 kernel:  0x8f7f858a
Jan 11 18:20:27  pc02 kernel:  0x8f7f87e3
Jan 11 18:20:27  pc02 kernel:  0x8f7f6390
Jan 11 18:20:27  pc02 kernel:  0x8f7f75d7
Jan 11 18:20:27  pc02 kernel:  0x8f7f9414
Jan 11 18:20:27  pc02 kernel:  ? 0xc0d8a000
Jan 11 18:20:27  pc02 kernel:  0x8f000723
Jan 11 18:20:27  pc02 kernel:  0x8f20ee3b
Jan 11 18:20:27  pc02 kernel:  0x8f210fd1
Jan 11 18:20:27  pc02 kernel:  0x8f21112c
Jan 11 18:20:27  pc02 kernel:  0x8f211351
Jan 11 18:20:27  pc02 kernel:  0x8fcab7c4
Jan 11 18:20:27  pc02 kernel:  0x8fe000c7
Jan 11 18:20:27  pc02 kernel: RIP: 0033:0x7ff1f7b4eca9
Jan 11 18:20:27  pc02 kernel: Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00
00 00 90 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 8b 0d 2f e1 0c 00 f7 d8 64 89 01 48
Jan 11 18:20:27  pc02 kernel: RSP: 002b:7ffd84d4f018 EFLAGS: 0246
ORIG_RAX: 0139
Jan 11 18:20:27  pc02 kernel: RAX: ffda RBX: 5641b982ad80 RCX:
7ff1f7b4eca9
Jan 11 18:20:27  pc02 kernel: RDX:  RSI: 7ff1f7c3b2df RDI:
0017
Jan 11 18:20:27  pc02 kernel: RBP:  R08:  R09:

Jan 11 18:20:27  pc02 kernel: R10: 0050 R11: 0246 R12:
7ff1f7c3b2df
Jan 11 18:20:27  pc02 kernel: R13: 0002 R14: 5641b9844ba0 R15:

Jan 11 18:20:27  pc02 kernel:  
Jan 11 18:20:27  pc02 kernel: ---[ end trace  ]---
Jan 11 18:20:27  pc02 kernel: [ cut here ]
Jan 11 18:20:27  pc02 kernel: WARNING: CPU: 24 PID: 468 at 0xc06b26f1
Jan 11 18:20:27  pc02 kernel: Modules linked in: amdgpu(+) drm_ttm_helper
snd_hda_codec_hdmi ttm amdxcp drm_exec gpu_sched i2c_algo_bit kvm_amd drm_buddy
snd_hda_intel mt7921e drm_suballoc_helper snd_intel_dspcfg mt7921_common
drm_display_helper mt792x_lib snd_hda_codec cec mt76_connac_lib igc
snd_hda_core mt>
Jan 11 18:20:27  pc02 kernel: CPU: 24 PID: 468 Comm: (udev-worker) Tai

[Bug 218368] amdgpu crashes on loading on both kernel-6.6.9 and kernel-6.1.69 at cold boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=218368

--- Comment #1 from nvaert1986 (nvaert1...@hotmail.com) ---
an 11 18:20:27 pc02 kernel: [drm] failed to load ucode UNKNOWN UCODE(0xE) 
Jan 11 18:20:27 pc02 kernel: [drm] psp gfx command LOAD_IP_FW(0x6) failed and
response status is (0x0)
Jan 11 18:20:27 pc02 kernel: [drm:0xc06c23d5] *ERROR* Fail to stop psp
ring
Jan 11 18:20:27 pc02 kernel: [drm:0xc06bde91] *ERROR* PSP firmware
loading failed
Jan 11 18:20:27 pc02 kernel: [drm:0xc06246b5] *ERROR* hw_init of IP
block  failed -22
Jan 11 18:20:27 pc02 kernel: amdgpu :03:00.0: amdgpu: amdgpu_device_ip_init
failed
Jan 11 18:20:27 pc02 kernel: amdgpu :03:00.0: amdgpu: Fatal error during
GPU init
Jan 11 18:20:27 pc02 kernel: amdgpu :03:00.0: amdgpu: amdgpu: finishing
device.
Jan 11 18:20:27 pc02 kernel: [ cut here ]
Jan 11 18:20:27 pc02 kernel: WARNING: CPU: 24 PID: 468 at 0xc06b26f1
Jan 11 18:20:27 pc02 kernel: Modules linked iJan 11 18:20:27 pc02 kernel: 
0xc0623824
Jan 11 18:20:27 pc02 kernel:  0x8f6b8754
Jan 11 18:20:27 pc02 kernel:  0x8f7f82ce
Jan 11 18:20:27 pc02 kernel:  ? 0x8f7f8760
Jan 11 18:20:27 pc02 kernel:  0x8f7f84ce
Jan 11 18:20:27 pc02 kernel:  0x8f7f858a
Jan 11 18:20:27 pc02 kernel:  0x8f7f87e3
Jan 11 18:20:27 pc02 kernel:  0x8f7f6390
Jan 11 18:20:27 pc02 kernel:  0x8f7f75d7
Jan 11 18:20:27 pc02 kernel:  0x8f7f9414
Jan 11 18:20:27 pc02 kernel:  ? 0xc0d8a000
Jan 11 18:20:27 pc02 kernel:  0x8f000723
Jan 11 18:20:27 pc02 kernel:  0x8f20ee3b
Jan 11 18:20:27 pc02 kernel:  0x8f210fd1
Jan 11 18:20:27 pc02 kernel:  0x8f21112c
Jan 11 18:20:27 pc02 kernel:  0x8f211351
Jan 11 18:20:27 pc02 kernel:  0x8fcab7c4
Jan 11 18:20:27 pc02 kernel:  0x8fe000c7
Jan 11 18:20:27 pc02 kernel: RIP: 0033:0x7ff1f7b4eca9
Jan 11 18:20:27 pc02 kernel: Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00
00 90 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 8b 0d 2f e1 0c 00 f7 d8 64 89 01 48
Jan 11 18:20:27 pc02 kernel: RSP: 002b:7ffd84d4f018 EFLAGS: 0246
ORIG_RAX: 0139
Jan 11 18:20:27 pc02 kernel: RAX: ffda RBX: 5641b982ad80 RCX:
7ff1f7b4eca9
Jan 11 18:20:27 pc02 kernel: RDX:  RSI: 7ff1f7c3b2df RDI:
0017
Jan 11 18:20:27 pc02 kernel: RBP:  R08:  R09:

Jan 11 18:20:27 pc02 kernel: R10: 0050 R11: 0246 R12:
7ff1f7c3b2df
Jan 11 18:20:27 pc02 kernel: R13: 0002 R14: 5641b9844ba0 R15:

Jan 11 18:20:27 pc02 kernel:  
Jan 11 18:20:27 pc02 kernel: ---[ end trace  ]---
Jan 11 18:20:27 pc02 kernel: [ cut here ]
n: amdgpu(+) drm_ttm_helper snd_hda_codec_hdmi ttm amdxcp drm_exec gpu_sched
i2c_algo_bit kvm_amd drm_buddy snd_hda_intel mt7921e drm_suballoc_helper
snd_intel_dspcfg mt7921_common drm_display_helper mt792x_lib snd_hda_codec cec
mt76_connac_lib igc snd_hda_core mt>
Jan 11 18:20:27 pc02 kernel: CPU: 24 PID: 468 Comm: (udev-worker) Tainted: G   
   O   6.6.9-gentoo #2
Jan 11 18:20:27 pc02 kernel: Hardware name: ASUS System Product Name/ROG STRIX
X670E-A GAMING WIFI, BIOS 1807 12/14/2023
Jan 11 18:20:27 pc02 kernel: RIP: 0010:0xc06b26f1
Jan 11 18:20:27 pc02 kernel: Code: c0 74 33 48 8b 4e 10 48 83 39 00 74 29 89 d1
48 8d 04 88 8b 08 85 c9 74 11 f0 ff 08 74 07 31 c0 e9 14 eb 60 cf e9 9f fd ff
ff <0f> 0b b8 ea ff ff ff e9 03 eb 60 cf b8 ea ff ff ff e9 f9 ea 60 cf
Jan 11 18:20:27 pc02 kernel: RSP: 0018:b7a6028bfb38 EFLAGS: 00010246
Jan 11 18:20:27 pc02 kernel: RAX: 9db705a29f80 RBX: 9db717218580 RCX:

Jan 11 18:20:27 pc02 kernel: RDX:  RSI: 9db7172278f0 RDI:
9db71720
Jan 11 18:20:27 pc02 kernel: RBP: 9db7172100e8 R08:  R09:
9dc63d897b40
Jan 11 18:20:27 pc02 kernel: R10: 0003 R11: 9050ef28 R12:
9db7172104c8
Jan 11 18:20:27 pc02 kernel: R13: 9db717200010 R14: 9db71720 R15:
ff01
Jan 11 18:20:27 pc02 kernel: FS:  7ff1f6fa5340()
GS:9dc63dc0() knlGS:
Jan 11 18:20:27 pc02 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jan 11 18:20:27 pc02 kernel: CR2: 7f657532049c CR3: 0001141f6000 CR4:
00f50ee0
Jan 11 18:20:27 pc02 kernel: PKRU: 5554
Jan 11 18:20:27 pc02 kernel: Call Trace:
Jan 11 18:20:27 pc02 kernel:  
Jan 11 18:20:27 pc02 kernel:  ? 0x8f18ee7f
Jan 11 18:20:27 pc02 kernel:  ? 0xc06b26f1
Jan 11 18:20:27 pc02 kernel:  ? 0x8fc8705e
Jan 11 18:20:27 pc02 kernel:  ? 0x8fcaba9a
Jan 11 18:20:27 pc02 kernel:  ? 0x8fcabb77
Jan 11 18:20:27 pc02 kernel:  ? 0x8fe0120a
Jan 11 18:20:27 pc02 kernel:  ? 0xc06b26f1

Re: [PATCH v5 0/8] iio: new DMABUF based API, v5

[Andrew Davis]

On 1/11/24 3:20 AM, Paul Cercueil wrote:

Hi Andrew,

Le lundi 08 janvier 2024 à 15:12 -0600, Andrew Davis a écrit :

On 12/19/23 11:50 AM, Paul Cercueil wrote:

[V4 was: "iio: Add buffer write() support"][1]

Hi Jonathan,

This is a respin of the V3 of my patchset that introduced a new
interface based on DMABUF objects [2].

The V4 was a split of the patchset, to attempt to upstream buffer
write() support first. But since there is no current user upstream,
it
was not merged. This V5 is about doing the opposite, and contains
the
new DMABUF interface, without adding the buffer write() support. It
can
already be used with the upstream adi-axi-adc driver.

In user-space, Libiio uses it to transfer back and forth blocks of
samples between the hardware and the applications, without having
to
copy the data.

On a ZCU102 with a FMComms3 daughter board, running Libiio from the
pcercuei/dev-new-dmabuf-api branch [3], compiled with
WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
    sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
    Throughput: 116 MiB/s

Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON):
    sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
    Throughput: 475 MiB/s

This benchmark only measures the speed at which the data can be
fetched
to iio_rwdev's internal buffers, and does not actually try to read
the
data (e.g. to pipe it to stdout). It shows that fetching the data
is
more than 4x faster using the new interface.

When actually reading the data, the performance difference isn't
that
impressive (maybe because in case of DMABUF the data is not in
cache):

WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
    sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
status=progress
    2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s

WITH_LOCAL_DMABUF_API=ON:
    sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
status=progress
    2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s

One interesting thing to note is that fileio is (currently)
actually
faster than the DMABUF interface if you increase a lot the buffer
size.
My explanation is that the cache invalidation routine takes more
and
more time the bigger the DMABUF gets. This is because the DMABUF is
backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by
up
to 16 thousands pages, that have to be invalidated one by one. This
can
be addressed by using huge pages, but the udmabuf driver does not
(yet)
support creating DMABUFs backed by huge pages.



Have you tried DMABUFs created using the DMABUF System heap exporter?
(drivers/dma-buf/heaps/system_heap.c) It should be able to handle
larger allocation better here, and if you don't have any active
mmaps or vmaps then it can skip CPU-side coherency maintenance
(useful for device to device transfers).


I didn't know about it!

But udmabuf also allows you to skip CPU-side coherency maintenance,
since DMABUFs have two ioctls to start/finish CPU access anyway.



The only way it lets you skip that is if your application just doesn't
call those begin/end ioctls, which is wrong. That may work on a system
where CPU caches can be snooped by all devices that could attach to
a buffer(x86), but that might not work on others(ARM). So calling
those begin/end ioctls is required[0]. If maintenance is not actually
needed then the kernel will turn those calls into NOPs for you, but only
the kernel can know when that is correct (based on the running system
and the devices attached to that buffer), not userspace.


Allocating DMABUFs out of user pages has a bunch of other issues you
might run into also. I'd argue udmabuf is now completely superseded
by DMABUF system heaps. Try it out :)


I'm curious, what other issues?



For starters the {begin,end}_cpu_access() callbacks don't actually
sync the pages for any of the devices attached to the DMABUF, it
only makes a fake mapping for the misc device(CPU) then syncs with
that. That probably works for the QEMU case it was designed for where
the device is always a VM instance running on the same CPU, but for
any real devices the sync never happens towards them.

I have some patches fixing the above I'll post this cycle, but it
wont help with folks doing reads/wrties on the original shmem/memfd
outside of the begin/end ioctls. So there is a fundamental issue
with the buffer's backing memory's ownership/lifecycle that makes
udmabuf broken by design.

The DMABUF System Heap owns the backing memory and manages that
memory's lifecycle as all correct DMABUF exporters must.


The good thing about udmabuf is that the memory is backed by pages, so
we can use MSG_ZEROCOPY on sockets to transfer the mmapped data over
the network (having a DMABUF interface to the network stack would be
better, but I'm not opening that can of worms).



Yes, having a DMABUF importer interface for the network stack would be
the best long-term solution here, and one will probably end up being
needed for zero-copy buffer passing directly betwee

[Bug 218368] New: amdgpu crashes on loading on both kernel-6.6.9 and kernel-6.1.69 at cold boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=218368

Bug ID: 218368
   Summary: amdgpu crashes on loading on both kernel-6.6.9 and
kernel-6.1.69 at cold boot
   Product: Drivers
   Version: 2.5
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P3
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: nvaert1...@hotmail.com
Regression: No

The amdgpu driver crashes frequently whenever I cold boot my system. The issue
has not occurred so far when rebooting the system. I can see the screen (when
efifb is running) and then as soon as amdgpu is loaded my screen goes blank. I
press ctrl - alt - del to reboot the system.

-- 
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 v1] drm/msm/dp: remove mdss_dp_test_bit_depth_to_bpc()

[Dmitry Baryshkov]

On Thu, 11 Jan 2024 at 19:14, Kuogee Hsieh  wrote:
>
> mdss_dp_test_bit_depth_to_bpc() can be replace by
> mdss_dp_test_bit_depth_to_bpp() / 3. Hence remove it.
>
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_debug.c |  2 +-
>  drivers/gpu/drm/msm/dp/dp_link.h  | 23 ---
>  2 files changed, 1 insertion(+), 24 deletions(-)

Thank you!

Reviewed-by: Dmitry Baryshkov 

-- 
With best wishes
Dmitry

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

[Andri Yngvason]

mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone :
> >
> > This thing here works entirely differently, and I think we need somewhat
> > new semantics for this:
> >
> > - I agree it should be read-only for userspace, so immutable sounds right.
> >
> > - But I also agree with Daniel Stone that this should be tied more
> >   directly to the modeset state.
> >
> > So I think the better approach would be to put the output type into
> > drm_connector_state, require that drivers compute it in their
> > ->atomic_check code (which in the future would allow us to report it out
> > for TEST_ONLY commits too), and so guarantee that the value is updated
> > right after the kms ioctl returns (and not somewhen later for non-blocking
> > commits).
>
> That's exactly the point. Whether userspace gets an explicit
> notification or it has to 'know' when to read isn't much of an issue -
> just as long as it's well defined. I think the suggestion of 'do it in
> atomic_check and then it's guaranteed to be readable when the commit
> completes' is a good one.
>
> I do still have some reservations - for instance, why do we have the
> fallback to auto when userspace has explicitly requested a certain
> type? - but they may have been covered previously.
>

We discussed this further on IRC and this is summary of that discussion:

Sima proposed a new type of property that can be used to git feedback to
userspace after atomic ioctl. The user supplies a list of output properties
that they want to query and the kernel fills it in before returning from the
ioctl. This would help to get some information about why things failed
during TEST_ONLY.

Emersion raised the point that you might not know how much memory is needed
beforehand for the returned properties, to which sima replied: blob
property. There was some discussion about how that makes it possible to leak
kernel memory, especially if userspace does not know about a new property
blob. Emersion pointed out that userspace should only request properties
that it understands and pq agreed.

Emersion asked how the user should inform the kernel that it's done with the
blob, to which sima replied: DRM_IOCTL_MODE_DESTROYPROPBLOB. Sima also
mentioned using some sort of weak reference garbage collection scheme for
properties and there was some further discussion, but I'm not sure there was
any conclusion.

I asked if it made sense to add color format capabilities to the mode info
struct, but the conclusion was that it wouldn't really be useful because we
need TEST_ONLY anyway to see if the color format setting is compatible with
other settings.

I asked again if we should drop the "active color format" property as it
seems to be more trouble than it's worth for now. pq mentioned that there
are 2 separate use cases (in his words):
- People playing with setting UI would like to know what "auto" would result
  in, but that's just nice to have
- The other use case is the flicker-free boot into known configuration He
  went on to point out that the main problem with "auto" is that any modeset
  could make the driver decide differently. This means that we cannot fully
  rely on the previously set property.

However, leaving out "active color property" did not put us in a worse
situation than before, so the conclusion was that we should leave it out for
now. For GUI selectors, the current TEST_ONLY should be good enough, and all
the fancy stuff discussed previously isn't needed for now.

To summarise the summary: this means that we will drop the "active
color format" property and rename the "preferred color format"
property to "force color format" or just "color format" and failing to
satisfy that constraint will fail the modeset rather than falling back
to the "auto" behaviour.

Cheers,
Andri

[PATCH v1] drm/msm/dp: remove mdss_dp_test_bit_depth_to_bpc()

[Kuogee Hsieh]

mdss_dp_test_bit_depth_to_bpc() can be replace by
mdss_dp_test_bit_depth_to_bpp() / 3. Hence remove it.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_debug.c |  2 +-
 drivers/gpu/drm/msm/dp/dp_link.h  | 23 ---
 2 files changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 3bba901..534079e 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -105,7 +105,7 @@ static int dp_test_data_show(struct seq_file *m, void *data)
seq_printf(m, "vdisplay: %d\n",
debug->link->test_video.test_v_height);
seq_printf(m, "bpc: %u\n",
-   dp_link_bit_depth_to_bpc(bpc));
+   dp_link_bit_depth_to_bpp(bpc) / 3);
} else {
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
index 9dd4dd9..83da170 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.h
+++ b/drivers/gpu/drm/msm/dp/dp_link.h
@@ -112,29 +112,6 @@ static inline u32 dp_link_bit_depth_to_bpp(u32 tbd)
}
 }
 
-/**
- * dp_test_bit_depth_to_bpc() - convert test bit depth to bpc
- * @tbd: test bit depth
- *
- * Returns the bits per comp (bpc) to be used corresponding to the
- * bit depth value. This function assumes that bit depth has
- * already been validated.
- */
-static inline u32 dp_link_bit_depth_to_bpc(u32 tbd)
-{
-   switch (tbd) {
-   case DP_TEST_BIT_DEPTH_6:
-   return 6;
-   case DP_TEST_BIT_DEPTH_8:
-   return 8;
-   case DP_TEST_BIT_DEPTH_10:
-   return 10;
-   case DP_TEST_BIT_DEPTH_UNKNOWN:
-   default:
-   return 0;
-   }
-}
-
 void dp_link_reset_phy_params_vx_px(struct dp_link *dp_link);
 u32 dp_link_get_test_bits_depth(struct dp_link *dp_link, u32 bpp);
 int dp_link_process_request(struct dp_link *dp_link);
-- 
2.7.4

Re: [PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[Simon Ser]

Are we sure that all drivers handle these two props properly with async
page-flips? This is a new codepath not taken by the legacy uAPI.

Style nit: the indentation is a bit off, the continuation lines don't
align with the parenthesis.

Re: [PATCH] drm: allow IN_FENCE_FD and FB_DAMAGE_CLIPS to be changed with async commits

[André Almeida]

Hi Xaver,

Em 11/01/2024 13:56, Xaver Hugl escreveu:

Like with FB_ID, the driver never has to do bandwidth validation to use
these properties, so there's no reason not to allow them.

Signed-off-by: Xaver Hugl 


Reviewed-by: André Almeida 


---
  drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index aee4a65d4959..06d476f5a746 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1108,7 +1108,9 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
  
-		if (async_flip && prop != config->prop_fb_id) {

+   if (async_flip && prop != config->prop_fb_id &&
+   prop != config->prop_in_fence_fd &&
+   prop != config->prop_fb_damage_clips) {
ret = drm_atomic_plane_get_property(plane, plane_state,
prop, &old_val);
ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);

Re: BUG / design challenge: vmwgfx + PRIME handle free == clobbering errno

[Xaver Hugl]

Am Mi., 10. Jan. 2024 um 01:28 Uhr schrieb Zack Rusin <
zack.ru...@broadcom.com>:

> On Tue, Jan 9, 2024 at 11:06 AM Xaver Hugl  wrote:
> >
> > Hi,
> >
> > KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT.
>
> Can you point me to the code that implements it? Just wanted to take a
> quick look, because I didn't see the cursor on KDE 6 after fixing the
> kernel oops.
>
It's here:
https://invent.kde.org/plasma/kwin/-/blob/a879c59a082707e0e7dfa8ebeb7b239551ec9c71/src/backends/drm/drm_gpu.cpp#L153

> > Tying the check to
> > DRM_CLIENT_CAP_ATOMIC instead would IMO make more sense though (even if
> it's
> > still weird) and would work with older versions of KWin and other
> compositors.
>
> Unfortunately xf86-video-modesetting advertises CLIENT_CAP_ATOMIC and
> uses GL where our GL driver assumes the prime object is not GEM. Not
> impossible, as mentioned before, we can always add code to the kernel
> that handles both but I don't think there's any particularly clean
> solutions here. We'll probably play with a few solutions and see which
> one is the cleanest.
>
> z
>

Ah, that's unfortunate.

Re: [PATCH RESEND v9 1/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

[Karolina Stolarek]

On 11.01.2024 15:59, Christian König wrote:

I've gone ahead and pushed this one to drm-misc-next.

Going to take a look at the rest as well.


Awesome, thanks a lot!

All the best,
Karolina



@Amar could you run another test round with those? And maybe ping Kenny 
if we can integrate them into the CI.


Thanks,
Christian.

Am 11.01.24 um 11:28 schrieb Karolina Stolarek:

Remove a leftover definition of page order and pass an empty flag value
in ttm_pool_pre_populated().

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
Reviewed-by: Dominik Karol Piątkowski 


Acked-by: Christian König 
---
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c

index 2d9cae8cd984..b97f7b6daf5b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -78,10 +78,9 @@ static struct ttm_pool 
*ttm_pool_pre_populated(struct kunit *test,

  struct ttm_test_devices *devs = priv->devs;
  struct ttm_pool *pool;
  struct ttm_tt *tt;
-    unsigned long order = __fls(size / PAGE_SIZE);
  int err;
-    tt = ttm_tt_kunit_init(test, order, caching, size);
+    tt = ttm_tt_kunit_init(test, 0, caching, size);
  KUNIT_ASSERT_NOT_NULL(test, tt);
  pool = kunit_kzalloc(test, sizeof(*pool), GFP_KERNEL);

[PULL] drm-misc-next

[Thomas Zimmermann]

Hi Dave and Sima,

this is the first PR for drm-misc-next for Linux v6.9. It's fairly small
compared to typical PRs; probably because of the holidays. Most of the
changes appear to by fixes. There's also support for a few more panels
and HDMI support for a Rockchip chipset.

Best regards
Thomas

drm-misc-next-2024-01-11:
drm-misc-next for v6.9:

UAPI Changes:

virtio:
- add Venus capset defines

Cross-subsystem Changes:

Core Changes:

- fix drm_fixp2int_ceil()
- documentation fixes
- clean ups
- allow DRM_MM_DEBUG with DRM=m
- build fixes for debugfs support
- EDID cleanups
- sched: error-handling fixes
- ttm: add tests

Driver Changes:

bridge:
- ite-6505: fix DP link-training bug
- samsung-dsim: fix error checking in probe
- tc358767: fix regmap usage

efifb:
- use copy of global screen_info state

hisilicon:
- fix EDID includes

mgag200:
- improve ioremap usage
- convert to struct drm_edid

nouveau:
- disp: use kmemdup()
- fix EDID includes
- documentation fixes

panel:
- ltk050h3146w: error-handling fixes
- panel-edp: support delay between power-on and enable; use put_sync in
  unprepare; support Mediatek MT8173 Chromebooks, BOE NV116WHM-N49 V8.0,
  BOE NV122WUM-N41, CSO MNC207QS1-1 plus DT bindings
- panel-lvds: support EDT ETML0700Z9NDHA plus DT bindings
- panel-novatek: FRIDA FRD400B25025-A-CTK plus DT bindings

qaic:
- fixes to BO handling
- make use of DRM managed release
- fix order of remove operations

rockchip:
- analogix_dp: get encoder port from DT
- inno_hdmi: support HDMI for RK3128
- lvds: error-handling fixes

simplefb:
- fix logging

ssd130x:
- support SSD133x plus DT bindings

tegra:
- fix error handling

tilcdc:
- make use of DRM managed release

v3d:
- show memory stats in debugfs

vc4:
- fix error handling in plane prepare_fb
- fix framebuffer test in plane helpers

vesafb:
- use copy of global screen_info state

virtio:
- cleanups

vkms:
- fix OOB access when programming the LUT
- Kconfig improvements

vmwgfx:
- unmap surface before changing plane state
- fix memory leak in error handling
- documentation fixes
The following changes since commit b1a2aa9bcbb88a7dc1c4df98dbf4f4df9ca79c9f:

  drm: ci: Update xfails (2023-12-13 15:18:30 -0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2024-01-11

for you to fetch changes up to 502756e23360d1192c496bc6791e97621e8578d8:

  drm/v3d: Show the memory-management stats on debugfs (2024-01-11 11:45:47 
-0300)


drm-misc-next for v6.9:

UAPI Changes:

virtio:
- add Venus capset defines

Cross-subsystem Changes:

Core Changes:

- fix drm_fixp2int_ceil()
- documentation fixes
- clean ups
- allow DRM_MM_DEBUG with DRM=m
- build fixes for debugfs support
- EDID cleanups
- sched: error-handling fixes
- ttm: add tests

Driver Changes:

bridge:
- ite-6505: fix DP link-training bug
- samsung-dsim: fix error checking in probe
- tc358767: fix regmap usage

efifb:
- use copy of global screen_info state

hisilicon:
- fix EDID includes

mgag200:
- improve ioremap usage
- convert to struct drm_edid

nouveau:
- disp: use kmemdup()
- fix EDID includes
- documentation fixes

panel:
- ltk050h3146w: error-handling fixes
- panel-edp: support delay between power-on and enable; use put_sync in
  unprepare; support Mediatek MT8173 Chromebooks, BOE NV116WHM-N49 V8.0,
  BOE NV122WUM-N41, CSO MNC207QS1-1 plus DT bindings
- panel-lvds: support EDT ETML0700Z9NDHA plus DT bindings
- panel-novatek: FRIDA FRD400B25025-A-CTK plus DT bindings

qaic:
- fixes to BO handling
- make use of DRM managed release
- fix order of remove operations

rockchip:
- analogix_dp: get encoder port from DT
- inno_hdmi: support HDMI for RK3128
- lvds: error-handling fixes

simplefb:
- fix logging

ssd130x:
- support SSD133x plus DT bindings

tegra:
- fix error handling

tilcdc:
- make use of DRM managed release

v3d:
- show memory stats in debugfs

vc4:
- fix error handling in plane prepare_fb
- fix framebuffer test in plane helpers

vesafb:
- use copy of global screen_info state

virtio:
- cleanups

vkms:
- fix OOB access when programming the LUT
- Kconfig improvements

vmwgfx:
- unmap surface before changing plane state
- fix memory leak in error handling
- documentation fixes


Alex Bee (13):
  drm/rockchip: vop: Add output selection registers for RK312x
  drm/rockchip: inno_hdmi: Fix video timing
  drm/rockchip: inno_hdmi: Remove YUV-based csc coefficents
  drm/rockchip: inno_hdmi: Drop irq struct member
  drm/rockchip: inno_hdmi: Remove useless include
  drm/rockchip: inno_hdmi: Subclass connector state
  drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
  drm/rockchip: inno_hdmi: Don't power up the phy after resetting
  drm/rockchip: inno_hdmi: Split power mode setting
  drm/rockchip: inno_hdmi: Add variant support
  drm/rockchip: inno_hdmi: Ad

Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel

[Luca Weiss]

On Thu Jan 11, 2024 at 3:57 PM CET, Linus Walleij wrote:
> On Wed, Jan 10, 2024 at 4:14 PM Luca Weiss  wrote:
>
> > Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A
> > driver IC, as found on the Fairphone 4 smartphone.
> >
> > Signed-off-by: Luca Weiss 
>
> This makes it sound like the Himax HX83112A is the driver IC.
>
> This does not seem to be the case:
> https://github.com/HimaxSoftware/HX83112_Android_Driver
>
> The driver IC seems to be a truly 5p65.

Hi Linus,

In some internal documentation it says "LCD Driver IC" "HX83112A" and I
don't see any reference to Truly 5P65 anywhere.

On their website they have this sentence:

  Himax offers display drivers for mobile handset displays that combine
  source driver, gate driver, timing controller, frame buffer, and DC to
  DC circuits into a single chip in various display technologies, such
  as TFT-LCD, LTPS, In-Cell Touch and AMOLED.

https://www.himax.com.tw/products/display-drivers/mobile-handset-applications/

While I'm not super well versed in panel driver ICs, this sounds like it
should be the one to take the name from?

Regards
Luca

>
> If this is right, could you rename the driver file to truly-5p65.c
> and all symbols containing hx83112 to truly_5965 or something
> that indicate the driver IC instead of the panel?
>
> My main concern is that the next display using the same IC
> need to find the right file to patch.
>
> Yours,
> Linus Walleij

Re: [PATCH RESEND v9 1/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

[Christian König]

I've gone ahead and pushed this one to drm-misc-next.

Going to take a look at the rest as well.

@Amar could you run another test round with those? And maybe ping Kenny 
if we can integrate them into the CI.


Thanks,
Christian.

Am 11.01.24 um 11:28 schrieb Karolina Stolarek:

Remove a leftover definition of page order and pass an empty flag value
in ttm_pool_pre_populated().

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
Reviewed-by: Dominik Karol Piątkowski 
Acked-by: Christian König 
---
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 2d9cae8cd984..b97f7b6daf5b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -78,10 +78,9 @@ static struct ttm_pool *ttm_pool_pre_populated(struct kunit 
*test,
struct ttm_test_devices *devs = priv->devs;
struct ttm_pool *pool;
struct ttm_tt *tt;
-   unsigned long order = __fls(size / PAGE_SIZE);
int err;
  
-	tt = ttm_tt_kunit_init(test, order, caching, size);

+   tt = ttm_tt_kunit_init(test, 0, caching, size);
KUNIT_ASSERT_NOT_NULL(test, tt);
  
  	pool = kunit_kzalloc(test, sizeof(*pool), GFP_KERNEL);

Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi

[Rob Herring]

On Wed, Jan 10, 2024 at 04:11:44PM +, Conor Dooley wrote:
> On Wed, Jan 10, 2024 at 12:23:37PM +0100, Geert Uytterhoeven wrote:
> > Hi Conor,
> > 
> > On Tue, Jan 9, 2024 at 7:06 PM Conor Dooley  wrote:
> > > On Tue, Jan 09, 2024 at 05:23:23PM +0900, Yoshinori Sato wrote:
> > > > Add Silicon Mortion Technology Corporation
> > 
> > Motion
> > 
> > > > https://www.siliconmotion.com/
> > > >
> > > > Signed-off-by: Yoshinori Sato 
> > > > ---
> > > >  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 94ed63d9f7de..a338bdd743ab 100644
> > > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > > @@ -1283,6 +1283,8 @@ patternProperties:
> > > >  description: Skyworks Solutions, Inc.
> > > >"^smartlabs,.*":
> > > >  description: SmartLabs LLC
> > > > +  "^smi,.*":
> > > > +description: Silicon Motion Technology Corporation
> > >
> > > How come "smi" is used for a company with this name?
> > > Why is it not something like SMTC? There's probably some history here
> > > that I am unaware of.
> > 
> > See Documentation/devicetree/bindings/display/sm501fb.txt
> > The stock ticker is "SIMO", though.
> > https://www.nasdaq.com/market-activity/stocks/simo
> 
> If there's an existing user, there's little reason to stand in the way I
> think.
> Acked-by: Conor Dooley 

Or reason not to apply, so I'm applying this.

BTW, 'RFC' is the standard way to say 'DO NOT MERGE'.

Rob

Re: [PATCH] drm/v3d: Show the memory-management stats on debugfs

[Maira Canal]

On 1/5/24 12:32, Melissa Wen wrote:

On 01/05, Maíra Canal wrote:

Dump the contents of the DRM MM allocator of the V3D driver. This will
help us to debug the VA ranges allocated.

Signed-off-by: Maíra Canal 
---
  drivers/gpu/drm/v3d/v3d_debugfs.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index f843a50d5dce..cdfe1d3bf5ee 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -260,11 +260,26 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
return 0;
  }

+static int v3d_debugfs_mm(struct seq_file *m, void *unused)
+{
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_debugfs_entry *entry = m->private;
+   struct drm_device *dev = entry->dev;
+   struct v3d_dev *v3d = to_v3d_dev(dev);
+
+   spin_lock(&v3d->mm_lock);
+   drm_mm_print(&v3d->mm, &p);
+   spin_unlock(&v3d->mm_lock);
+
+   return 0;
+}


LGTM.

Reviewed-by: Melissa Wen 


Pushed to drm-misc/drm-misc-next!

Best Regards,
- Maíra




+
  static const struct drm_debugfs_info v3d_debugfs_list[] = {
{"v3d_ident", v3d_v3d_debugfs_ident, 0},
{"v3d_regs", v3d_v3d_debugfs_regs, 0},
{"measure_clock", v3d_measure_clock, 0},
{"bo_stats", v3d_debugfs_bo_stats, 0},
+   {"v3d_mm", v3d_debugfs_mm, 0},
  };

  void
--
2.43.0

Re: [PATCH v2 2/4] drm/panel: Add driver for DJN HX83112A LCD panel

[Linus Walleij]

On Wed, Jan 10, 2024 at 4:14 PM Luca Weiss  wrote:

> Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A
> driver IC, as found on the Fairphone 4 smartphone.
>
> Signed-off-by: Luca Weiss 

This makes it sound like the Himax HX83112A is the driver IC.

This does not seem to be the case:
https://github.com/HimaxSoftware/HX83112_Android_Driver

The driver IC seems to be a truly 5p65.

If this is right, could you rename the driver file to truly-5p65.c
and all symbols containing hx83112 to truly_5965 or something
that indicate the driver IC instead of the panel?

My main concern is that the next display using the same IC
need to find the right file to patch.

Yours,
Linus Walleij

Re: [PATCH v2 1/6] dt-bindings: display: add dt-bindings for STM32 LVDS device

[Rob Herring]

On Thu, Jan 11, 2024 at 11:40:44AM +0100, Raphael Gallais-Pou wrote:
> Add "st,stm32-lvds" compatible.
> 
> Signed-off-by: Raphael Gallais-Pou 
> ---
> Changes in v2:
>   - Switch compatible and clock-cells related areas
>   - Remove faulty #include in the example.
>   - Add entry in MAINTAINERS
> ---
>  .../bindings/display/st,stm32-lvds.yaml   | 117 ++
>  MAINTAINERS   |   1 +
>  2 files changed, 118 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml 
> b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
> new file mode 100644
> index ..8dfc6e88f260
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics STM32 LVDS Display Interface Transmitter
> +
> +maintainers:
> +  - Raphael Gallais-Pou 
> +  - Yannick Fertre 
> +
> +description: |
> +  The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
> +  LVDS protocol: it maps the pixels received from the upstream Pixel-DMA 
> (LTDC)
> +  onto the LVDS PHY.
> +
> +  It regroups three sub blocks:

regroups means rearranging. Perhaps 'contains' or 'is composed of' 
instead.

> +- LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
> +  pixels onto the data lanes of the PHY
> +- LVDS PHY: parallelize the data and drives the LVDS data lanes
> +- LVDS wrapper: handles top-level settings
> +
> +  The LVDS controller driver supports the following high-level features:
> +- FDP-Link-I and OpenLDI (v0.95) protocols
> +- Single-Link or Dual-Link operation
> +- Single-Display or Double-Display (with the same content duplicated on 
> both)
> +- Flexible Bit-Mapping, including JEIDA and VESA
> +- RGB888 or RGB666 output
> +- Synchronous design, with one input pixel per clock cycle
> +
> +properties:
> +  compatible:
> +const: st,stm32-lvds

SoC specific compatible needed.

> +
> +  "#clock-cells":
> +const: 0

What clock is provided?

> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +items:
> +  - description: APB peripheral clock
> +  - description: Reference clock for the internal PLL
> +
> +  clock-names:
> +items:
> +  - const: pclk
> +  - const: ref
> +
> +  resets:
> +maxItems: 1
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |

Don't need '|' if no formatting to preserve.

> +  LVDS input port node, connected to the LTDC RGB output port.
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: |
> +  LVDS output port node, connected to a panel or bridge input port.
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - "#clock-cells"
> +  - reg
> +  - clocks
> +  - clock-names
> +  - resets
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +lvds: lvds@4806 {
> +compatible = "st,stm32-lvds";
> +reg = <0x4806 0x2000>;
> +#clock-cells = <0>;
> +clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
> +clock-names = "pclk", "ref";
> +resets = <&rcc LVDS_R>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +lvds_in: endpoint {
> +   remote-endpoint = <;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds_out0: endpoint {
> +   remote-endpoint = <&lvds_panel_in>;
> +};
> +};
> +};
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d959a6881f7..0b6ec5347195 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7193,6 +7193,7 @@ L:  dri-devel@lists.freedesktop.org
>  S:   Maintained
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  F:   Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
> +F:   Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
>  F:   drivers/gpu/drm/stm
>  
>  DRM DRIVERS FOR TI KEYSTONE
> -- 
> 2.25.1
> 

Re: [PATCH] drm/edid: Clean up errors in drm_edid.h

[Jani Nikula]

On Thu, 11 Jan 2024, Jani Nikula  wrote:
> On Thu, 11 Jan 2024, chenxuebing  wrote:
>> Fix the following errors reported by checkpatch:
>>
>> ERROR: do not use assignment in if condition
>>
>> Signed-off-by: chenxuebing 
>
> Reviewed-by: Jani Nikula 

And pushed to drm-misc-next, thanks for the patch.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/drm_edid.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 69c68804023f..9bcaf76f10fc 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3611,7 +3611,8 @@ static bool mode_in_range(const struct 
>> drm_display_mode *mode,
>>  if (!mode_in_vsync_range(mode, edid, t))
>>  return false;
>>  
>> -if ((max_clock = range_pixel_clock(edid, t)))
>> +max_clock = range_pixel_clock(edid, t);
>> +if (max_clock)
>>  if (mode->clock > max_clock)
>>  return false;

-- 
Jani Nikula, Intel

Re: [PATCH] drm/v3d: Free the job and assign it to NULL if initialization fails

[Maira Canal]

On 1/11/24 04:13, Iago Toral wrote:

Ok, thanks for checking, you can add my R-B on the original patch then.



Applied to drm-misc/drm-misc-next-fixes!

Best Regards,
- Maíra


Iago

El mié, 10-01-2024 a las 07:42 -0300, Maira Canal escribió:

Hi Iago,

On 1/10/24 03:48, Iago Toral wrote:

I think this is fine, but I was wondering if it would be simpler
and
easier to just remove the sched cleanup from v3d_job_init and
instead
always rely on callers to eventually call v3d_job_cleanup for fail
paths, where we are already calling v3d_job_cleanup.


If we just remove `drm_sched_job_cleanup()` from `v3d_job_init()` we
trigger a use-after-free warning by the job refcount:

[   34.367222] [ cut here ]
[   34.367235] refcount_t: underflow; use-after-free.
[   34.367274] WARNING: CPU: 0 PID: 1922 at lib/refcount.c:28
refcount_warn_saturate+0x108/0x148
[   34.367298] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
snd_seq snd_seq_device algif_hash aes_neon_bs aes_neon_blk
algif_skcipher af_alg bnep hid_logitech_hidpp brcmfmac_wcc brcmfmac
hci_uart btbcm bluetooth vc4 brcmutil cfg80211 bcm2835_v4l2(C)
bcm2835_mmal_vchiq(C) binfmt_misc snd_soc_hdmi_codec videobuf2_v4l2
cec
ecdh_generic drm_display_helper videobuf2_vmalloc ecc
videobuf2_memops
drm_dma_helper videobuf2_common drm_kms_helper dwc2 raspberrypi_hwmon
videodev snd_soc_core i2c_brcmstb rfkill libaes hid_logitech_dj mc
v3d
snd_bcm2835(C) i2c_bcm2835 pwm_bcm2835 snd_pcm_dmaengine snd_pcm
gpu_sched snd_timer drm_shmem_helper snd nvmem_rmem uio_pdrv_genirq
uio
i2c_dev drm dm_mod fuse drm_panel_orientation_quirks backlight
configfs
ip_tables x_tables ipv6
[   34.367434] CPU: 0 PID: 1922 Comm: v3d_submit_cl Tainted:
G C
  6.7.0-rc3-g632ca3c92f38-dirty #74
[   34.367441] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[   34.367444] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[   34.367450] pc : refcount_warn_saturate+0x108/0x148
[   34.367456] lr : refcount_warn_saturate+0x108/0x148
[   34.367462] sp : ffc08341bb90
[   34.367465] x29: ffc08341bb90 x28: ff8102962400 x27:
ffee5592de88
[   34.367473] x26: ff8116503e00 x25: ff81213e8800 x24:
0048
[   34.367481] x23: ff8101088000 x22: ffc08341bcf0 x21:
ffea
[   34.367489] x20: ff8102962400 x19: ff8102962600 x18:
ffee5beb3468
[   34.367497] x17: 0001 x16:  x15:
0004
[   34.367504] x14: ffee5c163738 x13: 0fff x12:
0003
[   34.367512] x11:  x10: 0027 x9 :
ada342fc9d5acc00
[   34.367519] x8 : ada342fc9d5acc00 x7 : 65646e75203a745f x6 :
746e756f63666572
[   34.367526] x5 : ffee5c3129da x4 : ffee5c2fc59e x3 :

[   34.367533] x2 :  x1 : ffc08341b930 x0 :
0026
[   34.367541] Call trace:
[   34.367544]  refcount_warn_saturate+0x108/0x148
[   34.367550]  v3d_submit_cl_ioctl+0x4cc/0x5e8 [v3d]
[   34.367588]  drm_ioctl_kernel+0xe0/0x120 [drm]
[   34.367767]  drm_ioctl+0x264/0x408 [drm]
[   34.367866]  __arm64_sys_ioctl+0x9c/0xe0
[   34.367877]  invoke_syscall+0x4c/0x118
[   34.367887]  el0_svc_common+0xb8/0xf0
[   34.367892]  do_el0_svc+0x28/0x40
[   34.367898]  el0_svc+0x38/0x88
[   34.367906]  el0t_64_sync_handler+0x84/0x100
[   34.367913]  el0t_64_sync+0x190/0x198
[   34.367917] ---[ end trace  ]---

Best Regards,
- Maíra



Iago

El mar, 09-01-2024 a las 11:28 -0300, Maíra Canal escribió:

Currently, if `v3d_job_init()` fails (e.g. in the IGT test "bad-
in-
sync",
where we submit an invalid in-sync to the IOCTL), then we end up
with
the following NULL pointer dereference:

[   34.146279] Unable to handle kernel NULL pointer dereference
at
virtual address 0078
[   34.146301] Mem abort info:
[   34.146306]   ESR = 0x9605
[   34.146315]   EC = 0x25: DABT (current EL), IL = 32 bits
[   34.146322]   SET = 0, FnV = 0
[   34.146328]   EA = 0, S1PTW = 0
[   34.146334]   FSC = 0x05: level 1 translation fault
[   34.146340] Data abort info:
[   34.146345]   ISV = 0, ISS = 0x0005, ISS2 = 0x
[   34.146351]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   34.146357]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   34.146366] user pgtable: 4k pages, 39-bit VAs,
pgdp=0001232e6000
[   34.146375] [0078] pgd=,
p4d=, pud=
[   34.146399] Internal error: Oops: 9605 [#1]
PREEMPT
SMP
[   34.146406] Modules linked in: rfcomm snd_seq_dummy
snd_hrtimer
snd_seq snd_seq_device algif_hash aes_neon_bs aes_neon_blk
algif_skcipher af_alg bnep hid_logitech_hidpp brcmfmac_wcc
brcmfmac
brcmutil hci_uart vc4 btbcm cfg80211 bluetooth bcm2835_v4l2(C)
snd_soc_hdmi_codec binfmt_misc cec drm_display_helper
hid_logitech_dj
bcm2835_mmal_vchiq(C) drm_dma_helper drm_kms_helper
videobuf2_v4l2
raspberrypi_hwmon ecdh_generic videobuf2_vmalloc videobuf2_memops
ecc
video

Re: [PATCH] Revert "drm/msm/gpu: Push gpu lock down past runpm"

[Daniel Vetter]

On Wed, Jan 10, 2024 at 06:54:53AM -0800, Rob Clark wrote:
> On Wed, Jan 10, 2024 at 2:50 AM Daniel Vetter  wrote:
> >
> > On Tue, Jan 09, 2024 at 10:22:17AM -0800, Rob Clark wrote:
> > > From: Rob Clark 
> > >
> > > This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
> > >
> > > Changing the locking order means that scheduler/msm_job_run() can race
> > > with the recovery kthread worker, with the result that the GPU gets an
> > > extra runpm get when we are trying to power it off.  Leaving the GPU in
> > > an unrecovered state.
> >
> > The recovery kthread is supposed to stop all the relevant schedulers,
> > which should remove any possible race conditions. So unless there's more
> > going on, or you have your own recovery kthread (don't, reuse the one from
> > the scheduler with your own work items, that's why you can provide that)
> > this looks like an incomplete/incorrect explanation ... ?
> >
> > Slightly confused
> 
> msm still uses it's own recovery, which pre-dates the scheduler
> conversion.  At one point (a yr or two back?) I started looking at
> integrating recovery w/ scheduler.. at the time I think you talked me
> out of it, but I don't remember the reason

hm ... most scheduler discussions I remember was around the "allocate your
own workqueue and hand that to scheduler to avoid races/deadlocks". Which
iirc Boris implemented a while ago. Once you have that workqueue you can
then also process any other error condition on there with the exact same
locking design (like hw error or page faults or whatever), not just
drm/sched tdr.

I don't remember anything else that ever came up at least at a fundamental
level ...

So if that discussion was older than 78efe21b6f8e ("drm/sched: Allow using
a dedicated workqueue for the timeout/fault tdr") you should be covered.
Fingers crossed :-)

Meanwhile if you do not use drm/sched tdr at all then doing the exact same
design but just on your own workqueue should also work. The critical thing
is really only:
- have one single-thread workqueue for all gpu recover
- bracket each handler in there with drm_sched_stop/start for all affected
  engines

No more races!

Cheers, Sima

> 
> BR,
> -R
> 
> > -Sima
> >
> > >
> > > I'll need to come up with a different scheme for appeasing lockdep.
> > >
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  drivers/gpu/drm/msm/msm_gpu.c| 11 +--
> > >  drivers/gpu/drm/msm/msm_ringbuffer.c |  7 +--
> > >  2 files changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > > index 095390774f22..655002b21b0d 100644
> > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > @@ -751,12 +751,14 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
> > > msm_gem_submit *submit)
> > >   struct msm_ringbuffer *ring = submit->ring;
> > >   unsigned long flags;
> > >
> > > - pm_runtime_get_sync(&gpu->pdev->dev);
> > > + WARN_ON(!mutex_is_locked(&gpu->lock));
> > >
> > > - mutex_lock(&gpu->lock);
> > > + pm_runtime_get_sync(&gpu->pdev->dev);
> > >
> > >   msm_gpu_hw_init(gpu);
> > >
> > > + submit->seqno = submit->hw_fence->seqno;
> > > +
> > >   update_sw_cntrs(gpu);
> > >
> > >   /*
> > > @@ -781,11 +783,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
> > > msm_gem_submit *submit)
> > >   gpu->funcs->submit(gpu, submit);
> > >   gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
> > >
> > > - hangcheck_timer_reset(gpu);
> > > -
> > > - mutex_unlock(&gpu->lock);
> > > -
> > >   pm_runtime_put(&gpu->pdev->dev);
> > > + hangcheck_timer_reset(gpu);
> > >  }
> > >
> > >  /*
> > > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
> > > b/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > index e0ed27739449..548f5266a7d3 100644
> > > --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> > > @@ -21,8 +21,6 @@ static struct dma_fence *msm_job_run(struct 
> > > drm_sched_job *job)
> > >
> > >   msm_fence_init(submit->hw_fence, fctx);
> > >
> > > - submit->seqno = submit->hw_fence->seqno;
> > > -
> > >   mutex_lock(&priv->lru.lock);
> > >
> > >   for (i = 0; i < submit->nr_bos; i++) {
> > > @@ -35,8 +33,13 @@ static struct dma_fence *msm_job_run(struct 
> > > drm_sched_job *job)
> > >
> > >   mutex_unlock(&priv->lru.lock);
> > >
> > > + /* TODO move submit path over to using a per-ring lock.. */
> > > + mutex_lock(&gpu->lock);
> > > +
> > >   msm_gpu_submit(gpu, submit);
> > >
> > > + mutex_unlock(&gpu->lock);
> > > +
> > >   return dma_fence_get(submit->hw_fence);
> > >  }
> > >
> > > --
> > > 2.43.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/vc4: don't check if plane->state->fb == state->fb

[Maira Canal]

On 1/8/24 05:43, Maxime Ripard wrote:

On Fri, 5 Jan 2024 14:58:36 -0300, Ma=C3=ADra Canal wrote:

Currently, when using non-blocking commits, we can see the following
kernel warning:
=20
[  110.908514] [ cut here ]
[  110.908529] refcount_t: underflow; use-after-free.
=20
[ ... ]


Acked-by: Maxime Ripard 


Pushed to drm-misc/drm-misc-next!

Best Regards,
- Maíra



Thanks!
Maxime

[PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE

[Luca Weiss]

Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
bridge/panel.o to drm_kms_helper object, we need to select
DRM_KMS_HELPER to make sure the file is actually getting built.

Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
be properly available:

  aarch64-linux-gnu-ld: drivers/phy/qualcomm/phy-qcom-qmp-combo.o: in function 
`qmp_combo_bridge_attach':
  drivers/phy/qualcomm/phy-qcom-qmp-combo.c:3204:(.text+0x8f4): undefined 
reference to `devm_drm_of_get_bridge'

Signed-off-by: Luca Weiss 
---
I can see "depends on DRM_KMS_HELPER" was removed with commit
3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")

I'm not too familiar with Kconfig but it feels more correct if
PHY_QCOM_QMP_COMBO selects DRM_PANEL_BRIDGE that that's enough; and it
doesn't also has to explicitly select DRM_KMS_HELPER because of how the
objects are built in the Makefile.

Alternatively solution to this patch could be adjusting this line in
include/drm/drm_bridge.h:

  -#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
  +#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE) && 
defined(CONFIG_DRM_KMS_HELPER)
   struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct 
device_node *node,
u32 port, u32 endpoint);

.. and then selecting DRM_KMS_HELPER for PHY_QCOM_QMP_COMBO.

But I think the solution in this patch is better. Let me know what you
think.
---
 drivers/gpu/drm/bridge/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ac9ec5073619..ae782b427829 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -8,6 +8,7 @@ config DRM_BRIDGE
 config DRM_PANEL_BRIDGE
def_bool y
depends on DRM_BRIDGE
+   select DRM_KMS_HELPER
select DRM_PANEL
help
  DRM bridge wrapper of DRM panels

---
base-commit: b9c3a1fa6fb324e691a03cf124b79f4842e65d76
change-id: 20240111-drm-panel-bridge-fixup-5c2977fb969f

Best regards,
-- 
Luca Weiss 

Re: [PATCH v5 2/2] phy: mtk-mipi-csi: add driver for CSI phy

[AngeloGioacchino Del Regno]

Il 11/01/24 11:17, Julien Stephan ha scritto:

From: Phi-bang Nguyen 

This is a new driver that supports the MIPI CSI CD-PHY version 0.5

The number of PHYs depend on the SoC.
Each PHY can support D-PHY only or CD-PHY configuration.
The driver supports only D-PHY mode, so CD-PHY
compatible PHY are configured in D-PHY mode.

Signed-off-by: Louis Kuo 
Signed-off-by: Phi-bang Nguyen 
[Julien Stephan: refactor code]
[Julien Stephan: simplify driver model: one instance per phy vs
one instance for all phys]
Co-developed-by: Julien Stephan 
Signed-off-by: Julien Stephan 


Reviewed-by: AngeloGioacchino Del Regno 

Re: [DO NOT MERGE v6 23/37] mfd: sm501: Convert platform_data to OF property

[Lee Jones]

On Tue, 09 Jan 2024, Yoshinori Sato wrote:

> Various parameters of SM501 can be set using platform_data,
> so parameters cannot be passed in the DeviceTree target.
> Expands the parameters set in platform_data so that they can be
> specified using DeviceTree properties.
> 
> Signed-off-by: Yoshinori Sato 
> ---
>  drivers/mfd/sm501.c   | 436 ++

How has this grown from 99 lines to 436 lines?

Most of it almost certainly needs moving (back?) out to the leaf
drivers.  A great deal of the properties parsed in here are only
relevant to a single device (display for instance).  Please move all
non-generic handling out to the relevant subsystems.

>  drivers/video/fbdev/sm501fb.c | 106 +
>  2 files changed, 542 insertions(+)

-- 
Lee Jones [李琼斯]

[PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave & Sima,

Here goes drm-intel-next-fixes towards 6.8 merge window now that
drm-intel-gt-next is also merged.

Most importantly fixes for linux-next added build warnings and then a
couple display fixes.

CI results for drm-next seem to have regressed with regards to the shard
runs somewhere in the past, so bit limited to assess for regressions but
BAT looks reasonable.

Best Regards, Joonas

***

drm-intel-next-fixes-2024-01-11:

- Fixes for kernel-doc warnings enforced in linux-next
- Another build warning fix for string formatting of intel_wakeref_t
- Display fixes for DP DSC BPC and C20 PLL state verification

The following changes since commit b76c01f1d950425924ee1c1377760de3c024ef78:

  Merge tag 'drm-intel-gt-next-2023-12-15' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2024-01-10 11:36:47 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2024-01-11

for you to fetch changes up to d505a16e00c35919fd9fe5735894645e0f70a415:

  drm/i915/perf: reconcile Excess struct member kernel-doc warnings (2024-01-10 
11:56:58 +0200)


- Fixes for kernel-doc warnings enforced in linux-next
- Another build warning fix for string formatting of intel_wakeref_t
- Display fixes for DP DSC BPC and C20 PLL state verification


Ankit Nautiyal (1):
  drm/i915/dp: Fix the max DSC bpc supported by source

Imre Deak (1):
  drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors

Jani Nikula (1):
  drm/i915: don't make assumptions about intel_wakeref_t type

Mika Kahola (1):
  drm/i915/display: Fix C20 pll selection for state verification

Randy Dunlap (4):
  drm/i915/gem: reconcile Excess struct member kernel-doc warnings
  drm/i915/gt: reconcile Excess struct member kernel-doc warnings
  drm/i915/guc: reconcile Excess struct member kernel-doc warnings
  drm/i915/perf: reconcile Excess struct member kernel-doc warnings

 drivers/gpu/drm/i915/display/intel_cx0_phy.c   | 25 +---
 drivers/gpu/drm/i915/display/intel_display_power.c |  4 +-
 drivers/gpu/drm/i915/display/intel_dp.c|  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c   | 10 +--
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h  |  4 +-
 drivers/gpu/drm/i915/gt/intel_gsc.h|  7 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h | 75 --
 drivers/gpu/drm/i915/i915_perf_types.h |  9 ++-
 8 files changed, 78 insertions(+), 58 deletions(-)

Re: [PATCH 5.10 1/1] drm/qxl: fix UAF on handle creation

[Greg Kroah-Hartman]

On Tue, Jan 09, 2024 at 02:08:25PM +0300, Fedor Pchelkin wrote:
> From: Wander Lairson Costa 
> 
> commit c611589b4259ed63b9b77be6872b1ce07ec0ac16 upstream.

Now queued up, thanks.

greg k-h

[PATCH v2 4/6] arm64: dts: st: add ltdc support on stm32mp251

[Raphael Gallais-Pou]

The LCD-TFT Display Controller (LTDC) handles display composition,
scaling and rotation. It provides a parallel digital RGB flow to be used
by display interfaces.

Signed-off-by: Raphael Gallais-Pou 
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi 
b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 93bc8a8908ce..064077e98dfd 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -212,6 +212,18 @@ i2c8: i2c@4604 {
status = "disabled";
};
 
+   ltdc: display-controller@4801 {
+   compatible = "st,stm32-ltdc";
+   reg = <0x4801 0x400>;
+   st,syscon = <&syscfg>;
+   interrupts = ,
+   ;
+   clocks = <&rcc CK_BUS_LTDC>, <&rcc CK_KER_LTDC>;
+   clock-names = "bus", "lcd";
+   resets = <&rcc LTDC_R>;
+   status = "disabled";
+   };
+
sdmmc1: mmc@4822 {
compatible = "st,stm32mp25-sdmmc2", 
"arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00353180>;
-- 
2.25.1

[PATCH v2 6/6] arm64: dts: st: add display support on stm32mp257f-ev

[Raphael Gallais-Pou]

This patch enables the following IPs on stm32mp257f-ev :
  * LTDC
  * LVDS
  * WSVGA LVDS panel (1024x600)
  * Panel backlight
  * Ilitek touchescreen

Signed-off-by: Raphael Gallais-Pou 
---
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts 
b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
index 0ea8e69bfb3d..ca2da988d91c 100644
--- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
+++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts
@@ -29,6 +29,43 @@ memory@8000 {
reg = <0x0 0x8000 0x1 0x0>;
};
 
+   panel_lvds: panel-lvds {
+   compatible = "edt,etml0700z9ndha", "panel-lvds";
+   enable-gpios = <&gpiog 15 GPIO_ACTIVE_HIGH>;
+   backlight = <&panel_lvds_backlight>;
+   status = "okay";
+
+   width-mm = <156>;
+   height-mm = <92>;
+   data-mapping = "vesa-24";
+
+   panel-timing {
+   clock-frequency = <5400>;
+   hactive = <1024>;
+   vactive = <600>;
+   hfront-porch = <150>;
+   hback-porch = <150>;
+   hsync-len = <21>;
+   vfront-porch = <24>;
+   vback-porch = <24>;
+   vsync-len = <21>;
+   };
+
+   port {
+   lvds_panel_in: endpoint {
+   remote-endpoint = <&lvds_out0>;
+   };
+   };
+   };
+
+   panel_lvds_backlight: panel-lvds-backlight {
+   compatible = "gpio-backlight";
+   gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
+   default-on;
+   default-brightness-level = <0>;
+   status = "okay";
+   };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -63,6 +100,15 @@ &i2c2 {
i2c-scl-falling-time-ns = <13>;
clock-frequency = <40>;
status = "okay";
+
+   ili2511: ili2511@41 {
+   compatible = "ilitek,ili251x";
+   reg = <0x41>;
+   interrupt-parent = <&gpioi>;
+   interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+   reset-gpios = <&gpiog 14 GPIO_ACTIVE_LOW>;
+   status = "okay";
+   };
 };
 
 &i2c8 {
@@ -75,6 +121,39 @@ &i2c8 {
status = "disabled";
 };
 
+;
+   };
+   };
+};
+
+&lvds {
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds_in: endpoint {
+   remote-endpoint = <;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   lvds_out0: endpoint {
+   remote-endpoint = <&lvds_panel_in>;
+   };
+   };
+   };
+};
+
 &sdmmc1 {
pinctrl-names = "default", "opendrain", "sleep";
pinctrl-0 = <&sdmmc1_b4_pins_a>;
-- 
2.25.1

[PATCH v2 5/6] arm64: dts: st: add lvds support on stm32mp255

[Raphael Gallais-Pou]

This patch adds LVDS support on stm32mp255.  The LVDS is used on
STM32MP2 as a display interface.  LVDS PLL clock is binded to the LTDC
input clock.

Signed-off-by: Raphael Gallais-Pou 
---
Changes in v2:
- Move patch to stm32mp255.dtsi after internal discussions
---
 arch/arm64/boot/dts/st/stm32mp255.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp255.dtsi 
b/arch/arm64/boot/dts/st/stm32mp255.dtsi
index e6fa596211f5..ac46a7dbed2d 100644
--- a/arch/arm64/boot/dts/st/stm32mp255.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp255.dtsi
@@ -7,3 +7,20 @@
 
 / {
 };
+
+, <&rcc CK_KER_LTDC>, <&lvds 0>;
+   clock-names = "bus", "lcd", "lvds";
+};
+
+&rifsc {
+   lvds: lvds@4806 {
+   #clock-cells = <0>;
+   compatible = "st,stm32-lvds";
+   reg = <0x4806 0x2000>;
+   clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+   clock-names = "pclk", "ref";
+   resets = <&rcc LVDS_R>;
+   status = "disabled";
+   };
+};
-- 
2.25.1

[PATCH v2 2/6] drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver

[Raphael Gallais-Pou]

The Low-Voltage Differential Signaling (LVDS) Display Interface
Transmitter handles the LVDS protocol: it maps the pixels received from
the upstream Pixel-DMA LCD-TFT Display Controller (LTDC) onto the LVDS
PHY.

It regroups three sub blocks:
* LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps
  its input pixels onto the data lanes of the PHY
* LVDS PHY: parallelize the data and drives the LVDS data lanes
* LVDS wrapper: handles top-level settings

The LVDS controller driver supports the following high-level features:
* FDP-Link-I and OpenLDI (v0.95) protocols
* Single-Link or Dual-Link operation
* Single-Display or Double-Display (with the same content
  duplicated on both)
* Flexible Bit-Mapping, including JEIDA and VESA
* RGB888 or RGB666 output
* Synchronous design, with one input pixel per clock cycle

Signed-off-by: Raphael Gallais-Pou 
---
Changes in v2:
- Fixed Camel Case macros
- Removed debug log
---
 drivers/gpu/drm/stm/Kconfig  |   11 +
 drivers/gpu/drm/stm/Makefile |2 +
 drivers/gpu/drm/stm/lvds.c   | 1225 ++
 3 files changed, 1238 insertions(+)
 create mode 100644 drivers/gpu/drm/stm/lvds.c

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index fa49cde43bb2..9627814d027c 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -20,3 +20,14 @@ config DRM_STM_DSI
select DRM_DW_MIPI_DSI
help
  Choose this option for MIPI DSI support on STMicroelectronics SoC.
+
+config DRM_STM_LVDS
+   tristate "STMicroelectronics LVDS Display Interface Transmitter DRM 
driver"
+   depends on DRM_STM
+   help
+ Enable support for LVDS encoders on STMicroelectronics SoC.
+ The STM LVDS is a bridge which serialize pixel stream onto
+ a LVDS protocol.
+
+ To compile this driver as a module, choose M here: the module will be
+ called lvds.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index 4df5caf01f35..ad740d6175a6 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -5,4 +5,6 @@ stm-drm-y := \
 
 obj-$(CONFIG_DRM_STM_DSI) += dw_mipi_dsi-stm.o
 
+obj-$(CONFIG_DRM_STM_LVDS) += lvds.o
+
 obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c
new file mode 100644
index ..beb8b7e437a0
--- /dev/null
+++ b/drivers/gpu/drm/stm/lvds.c
@@ -0,0 +1,1225 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, STMicroelectronics - All Rights Reserved
+ * Author(s): Raphaël GALLAIS-POU  for 
STMicroelectronics.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* LVDS Host registers */
+#define LVDS_CR0x  /* configuration register */
+#define LVDS_DMLCR00x0004  /* data mapping lsb configuration register 0 */
+#define LVDS_DMMCR00x0008  /* data mapping msb configuration register 0 */
+#define LVDS_DMLCR10x000C  /* data mapping lsb configuration register 1 */
+#define LVDS_DMMCR10x0010  /* data mapping msb configuration register 1 */
+#define LVDS_DMLCR20x0014  /* data mapping lsb configuration register 2 */
+#define LVDS_DMMCR20x0018  /* data mapping msb configuration register 2 */
+#define LVDS_DMLCR30x001C  /* data mapping lsb configuration register 3 */
+#define LVDS_DMMCR30x0020  /* data mapping msb configuration register 3 */
+#define LVDS_DMLCR40x0024  /* data mapping lsb configuration register 4 */
+#define LVDS_DMMCR40x0028  /* data mapping msb configuration register 4 */
+#define LVDS_CDL1CR0x002C  /* channel distrib link 1 configuration 
register */
+#define LVDS_CDL2CR0x0030  /* channel distrib link 2 configuration 
register */
+
+#define CDL1CR_DEFAULT 0x04321 /* Default value for CDL1CR */
+#define CDL2CR_DEFAULT 0x59876 /* Default value for CDL2CR */
+
+#define LVDS_DMLCR(bit)(LVDS_DMLCR0 + 0x8 * (bit))
+#define LVDS_DMMCR(bit)(LVDS_DMMCR0 + 0x8 * (bit))
+
+/* LVDS Wrapper registers */
+#define LVDS_WCLKCR0x11B0  /* Wrapper clock control register */
+
+#define LVDS_HWCFGR0x1FF0  /* HW configuration register*/
+#define LVDS_VERR  0x1FF4  /* Version register */
+#define LVDS_IPIDR 0x1FF8  /* Identification register  */
+#define LVDS_SIDR  0x1FFC  /* Size Identification register */
+
+/* Bitfield description */
+#define CR_LVDSEN  BIT(0)  /* LVDS PHY Enable */
+#define CR_HSPOL   BIT(1)  /* Horizontal Synchronization Polarity */
+#define CR_VSPOL   BIT(2)  /* Vertical Synchronization Polarity */
+#define CR_DEPOL   BIT(3)  /* Data Enable Polarity */
+#define CR_CI  BIT(4)  /* Control Internal (software controlled bit) */
+#define CR_LKMOD   BIT(5)  /* Link

[PATCH v2 3/6] drm/stm: ltdc: add lvds pixel clock

[Raphael Gallais-Pou]

The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.

While waiting for a complete update of the clock framework, this would
allow to use the LVDS.

Signed-off-by: Raphael Gallais-Pou 
Signed-off-by: Yannick Fertre 
---
Changes in v2:
- Fixed my address
- Fixed smatch warning
---
 drivers/gpu/drm/stm/ltdc.c | 19 +++
 drivers/gpu/drm/stm/ltdc.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..23011a8913bd 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
int target_max = target + CLK_TOLERANCE_HZ;
int result;
 
+   if (ldev->lvds_clk) {
+   result = clk_round_rate(ldev->lvds_clk, target);
+   DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+target, result);
+   }
+
result = clk_round_rate(ldev->pixel_clk, target);
 
DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1896,6 +1902,8 @@ void ltdc_suspend(struct drm_device *ddev)
 
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(ldev->pixel_clk);
+   if (ldev->lvds_clk)
+   clk_disable_unprepare(ldev->lvds_clk);
 }
 
 int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1918,13 @@ int ltdc_resume(struct drm_device *ddev)
DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
return ret;
}
+   if (ldev->lvds_clk) {
+   if (clk_prepare_enable(ldev->lvds_clk)) {
+   clk_disable_unprepare(ldev->pixel_clk);
+   DRM_ERROR("Unable to prepare lvds clock\n");
+   return -ENODEV;
+   }
+   }
 
return 0;
 }
@@ -1981,6 +1996,10 @@ int ltdc_load(struct drm_device *ddev)
}
}
 
+   ldev->lvds_clk = devm_clk_get(dev, "lvds");
+   if (IS_ERR(ldev->lvds_clk))
+   ldev->lvds_clk = NULL;
+
rstc = devm_reset_control_get_exclusive(dev, NULL);
 
mutex_init(&ldev->err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..4a60ce5b610c 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk;  /* lcd pixel clock */
+   struct clk *lvds_clk;   /* lvds pixel clock */
struct mutex err_lock;  /* protecting error_status */
struct ltdc_caps caps;
u32 irq_status;
-- 
2.25.1

[PATCH v2 1/6] dt-bindings: display: add dt-bindings for STM32 LVDS device

[Raphael Gallais-Pou]

Add "st,stm32-lvds" compatible.

Signed-off-by: Raphael Gallais-Pou 
---
Changes in v2:
- Switch compatible and clock-cells related areas
- Remove faulty #include in the example.
- Add entry in MAINTAINERS
---
 .../bindings/display/st,stm32-lvds.yaml   | 117 ++
 MAINTAINERS   |   1 +
 2 files changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml 
b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
new file mode 100644
index ..8dfc6e88f260
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+  - Raphael Gallais-Pou 
+  - Yannick Fertre 
+
+description: |
+  The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+  LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+  onto the LVDS PHY.
+
+  It regroups three sub blocks:
+- LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+  pixels onto the data lanes of the PHY
+- LVDS PHY: parallelize the data and drives the LVDS data lanes
+- LVDS wrapper: handles top-level settings
+
+  The LVDS controller driver supports the following high-level features:
+- FDP-Link-I and OpenLDI (v0.95) protocols
+- Single-Link or Dual-Link operation
+- Single-Display or Double-Display (with the same content duplicated on 
both)
+- Flexible Bit-Mapping, including JEIDA and VESA
+- RGB888 or RGB666 output
+- Synchronous design, with one input pixel per clock cycle
+
+properties:
+  compatible:
+const: st,stm32-lvds
+
+  "#clock-cells":
+const: 0
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: APB peripheral clock
+  - description: Reference clock for the internal PLL
+
+  clock-names:
+items:
+  - const: pclk
+  - const: ref
+
+  resets:
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+  LVDS input port node, connected to the LTDC RGB output port.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+  LVDS output port node, connected to a panel or bridge input port.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - "#clock-cells"
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+lvds: lvds@4806 {
+compatible = "st,stm32-lvds";
+reg = <0x4806 0x2000>;
+#clock-cells = <0>;
+clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+clock-names = "pclk", "ref";
+resets = <&rcc LVDS_R>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+lvds_in: endpoint {
+   remote-endpoint = <;
+};
+};
+
+port@1 {
+reg = <1>;
+lvds_out0: endpoint {
+   remote-endpoint = <&lvds_panel_in>;
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d959a6881f7..0b6ec5347195 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7193,6 +7193,7 @@ L:dri-devel@lists.freedesktop.org
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
+F: Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
 F: drivers/gpu/drm/stm
 
 DRM DRIVERS FOR TI KEYSTONE
-- 
2.25.1

[PATCH v2 0/6] Introduce STM32 LVDS driver

[Raphael Gallais-Pou]

This serie introduces a new DRM bridge driver for STM32MP257 platforms
based on Arm Cortex-35. It also adds an instance in the device-tree and
handle the inclusion of the driver within the DRM framework. First patch
adds a new panel compatible in the panel-lvds driver, which is used by
default on the STM32MP257.

Changes in v2:
- Dropped [1/8] because already merged
- Dropped [4/8] since not mandatory for this serie
- [1/6]: Switch compatible and clock-cells related areas
- [1/6]: Remove faulty #include in the example.
- [1/6]: Add missing entry in MAINTAINERS
- [2/6]: Removed CamelCase macros
- [2/6]: Removed hard to read debug log
- [3/6]: Fixed my address
- [3/6]: Fixed smatch warning
- [5/6]: Move changes to stm32mp255.dtsi

Raphael Gallais-Pou (6):
  dt-bindings: display: add dt-bindings for STM32 LVDS device
  drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver
  drm/stm: ltdc: add lvds pixel clock
  arm64: dts: st: add ltdc support on stm32mp251
  arm64: dts: st: add lvds support on stm32mp255
  arm64: dts: st: add display support on stm32mp257f-ev

 .../bindings/display/st,stm32-lvds.yaml   |  117 ++
 MAINTAINERS   |1 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi|   12 +
 arch/arm64/boot/dts/st/stm32mp255.dtsi|   17 +
 arch/arm64/boot/dts/st/stm32mp257f-ev1.dts|   79 ++
 drivers/gpu/drm/stm/Kconfig   |   11 +
 drivers/gpu/drm/stm/Makefile  |2 +
 drivers/gpu/drm/stm/ltdc.c|   19 +
 drivers/gpu/drm/stm/ltdc.h|1 +
 drivers/gpu/drm/stm/lvds.c| 1225 +
 10 files changed, 1484 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/st,stm32-lvds.yaml
 create mode 100644 drivers/gpu/drm/stm/lvds.c

-- 
2.25.1

[PATCH RESEND v9 8/8] drm/ttm/tests: Add TODO file

[Karolina Stolarek]

List improvements for the test suite with some notes.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/ttm/tests/TODO | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 drivers/gpu/drm/ttm/tests/TODO

diff --git a/drivers/gpu/drm/ttm/tests/TODO b/drivers/gpu/drm/ttm/tests/TODO
new file mode 100644
index ..3095c3225cec
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/TODO
@@ -0,0 +1,24 @@
+TODO
+=
+
+- Add a test case where the only evictable BO is busy
+- Add tests for ttm_bo_vm_ops (that includes ttm_bo_kmap() testing)
+- Update eviction tests so they use parametrized "from" memory type
+- Improve mock manager's implementation, e.g. allocate a block of
+  dummy memory that can be used when testing page mapping functions
+- Suggestion: Add test cases with external BOs
+- Suggestion: randomize the number and size of tested buffers in
+  ttm_bo_validate()
+- Agree on the naming convention
+
+Notes and gotchas
+=
+
+- We want to stick to running UML to provide hardware-independent testing
+- Triggering ttm_bo_vm_ops callbacks from KUnit (i.e. kernel) might be
+  a challenge, but it seems doable. Use selftests like
+  i915/gem/selftests/i915_gem_mman.c for inspiration
+- The test suite uses UML, so ioremap() returns NULL. Simply switching
+  to x86 won't solve the issue, because we also get NULL when trying to
+  remap RAM. This means that we can only test a part of ttm_bo_ioremap()
+  (helper called in ttm_bo_kmap() function)
-- 
2.34.1

[PATCH RESEND v9 7/8] drm/ttm/tests: Add tests for ttm_tt_populate

[Karolina Stolarek]

Add tests for functions that add and release pages to TTs. Test the
swapin operation. Export ttm_tt_unpopulate, ttm_tt_swapin and
ttm_tt_swapout symbols for testing purposes.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c | 119 
 drivers/gpu/drm/ttm/ttm_tt.c|   3 +
 2 files changed, 122 insertions(+)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index a33a426a814d..b626228124aa 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -256,6 +256,120 @@ static void ttm_tt_destroy_basic(struct kunit *test)
ttm_tt_destroy(devs->ttm_dev, bo->ttm);
 }
 
+static void ttm_tt_populate_null_ttm(struct kunit *test)
+{
+   const struct ttm_test_devices *devs = test->priv;
+   struct ttm_operation_ctx ctx = { };
+   int err;
+
+   err = ttm_tt_populate(devs->ttm_dev, NULL, &ctx);
+   KUNIT_ASSERT_EQ(test, err, -EINVAL);
+}
+
+static void ttm_tt_populate_populated_ttm(struct kunit *test)
+{
+   const struct ttm_test_devices *devs = test->priv;
+   struct ttm_operation_ctx ctx = { };
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   struct page *populated_page;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_tt_populate(devs->ttm_dev, tt, &ctx);
+   KUNIT_ASSERT_EQ(test, err, 0);
+   populated_page = *tt->pages;
+
+   err = ttm_tt_populate(devs->ttm_dev, tt, &ctx);
+   KUNIT_ASSERT_PTR_EQ(test, populated_page, *tt->pages);
+}
+
+static void ttm_tt_unpopulate_basic(struct kunit *test)
+{
+   const struct ttm_test_devices *devs = test->priv;
+   struct ttm_operation_ctx ctx = { };
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_tt_populate(devs->ttm_dev, tt, &ctx);
+   KUNIT_ASSERT_EQ(test, err, 0);
+   KUNIT_ASSERT_TRUE(test, ttm_tt_is_populated(tt));
+
+   ttm_tt_unpopulate(devs->ttm_dev, tt);
+   KUNIT_ASSERT_FALSE(test, ttm_tt_is_populated(tt));
+}
+
+static void ttm_tt_unpopulate_empty_ttm(struct kunit *test)
+{
+   const struct ttm_test_devices *devs = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   ttm_tt_unpopulate(devs->ttm_dev, tt);
+   /* Expect graceful handling of unpopulated TTs */
+}
+
+static void ttm_tt_swapin_basic(struct kunit *test)
+{
+   const struct ttm_test_devices *devs = test->priv;
+   int expected_num_pages = BO_SIZE >> PAGE_SHIFT;
+   struct ttm_operation_ctx ctx = { };
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   int err, num_pages;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   err = ttm_tt_init(tt, bo, 0, ttm_cached, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_tt_populate(devs->ttm_dev, tt, &ctx);
+   KUNIT_ASSERT_EQ(test, err, 0);
+   KUNIT_ASSERT_TRUE(test, ttm_tt_is_populated(tt));
+
+   num_pages = ttm_tt_swapout(devs->ttm_dev, tt, GFP_KERNEL);
+   KUNIT_ASSERT_EQ(test, num_pages, expected_num_pages);
+   KUNIT_ASSERT_NOT_NULL(test, tt->swap_storage);
+   KUNIT_ASSERT_TRUE(test, tt->page_flags & TTM_TT_FLAG_SWAPPED);
+
+   /* Swapout depopulates TT, allocate pages and then swap them in */
+   err = ttm_pool_alloc(&devs->ttm_dev->pool, tt, &ctx);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_tt_swapin(tt);
+   KUNIT_ASSERT_EQ(test, err, 0);
+   KUNIT_ASSERT_NULL(test, tt->swap_storage);
+   KUNIT_ASSERT_FALSE(test, tt->page_flags & TTM_TT_FLAG_SWAPPED);
+}
+
 static struct kunit_case ttm_tt_test_cases[] = {
KUNIT_CASE_PARAM(ttm_tt_init_basic, ttm_tt_init_basic_gen_params),
KUNIT_CASE(ttm_tt_init_misaligned),
@@ -267,6 +381,11 @@ static struct kunit_case ttm_tt_test_cases[] = {
KUNIT_CASE(ttm_tt_create_ttm_exists),
KUNIT_CASE(ttm_tt_create_failed),
KUNIT_CASE(ttm_tt_destroy_basic),
+   KUNIT_CASE(ttm_tt_populate_null_ttm),
+   KUNIT_CASE(ttm_tt_populate_populated_ttm),
+   KUNIT_C

[PATCH RESEND v9 6/8] drm/ttm/tests: Add eviction testing

[Karolina Stolarek]

Add tests for ttm_bo_validate that focus on BO eviction and swapout.
Update device funcs definition with eviction-related callbacks. Add
alternative funcs where evict_flags() routes eviction to a domain
that can't allocate resources (dubbed "busy manager" in the tests).
Extract the common path of ttm_device init into a function.

Signed-off-by: Karolina Stolarek 
---
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 426 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 113 -
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   7 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  |  28 ++
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |   2 +
 5 files changed, 568 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index bf4bae25aec9..c7aa5e087597 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -758,6 +758,424 @@ static void 
ttm_bo_validate_move_fence_not_signaled(struct kunit *test)
ttm_mock_manager_fini(priv->ttm_dev, snd_mem);
 }
 
+static void ttm_bo_validate_swapout(struct kunit *test)
+{
+   struct ttm_test_devices *priv = test->priv;
+   unsigned long size_big, size = ALIGN(BO_SIZE, PAGE_SIZE);
+   enum ttm_bo_type bo_type = ttm_bo_type_device;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t mem_type = TTM_PL_VRAM;
+   struct ttm_buffer_object *bo_small, *bo_big;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   struct sysinfo si;
+   int err;
+
+   si_meminfo(&si);
+   size_big = ALIGN(((uint64_t)si.totalram * si.mem_unit / 2), PAGE_SIZE);
+
+   ttm_mock_manager_init(priv->ttm_dev, mem_type, size_big + size);
+
+   place = ttm_place_kunit_init(test, mem_type, 0);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   bo_small = kunit_kzalloc(test, sizeof(*bo_small), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo_small);
+
+   drm_gem_private_object_init(priv->drm, &bo_small->base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo_small, bo_type, placement,
+  PAGE_SIZE, &ctx, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   KUNIT_EXPECT_EQ(test, err, 0);
+   dma_resv_unlock(bo_small->base.resv);
+
+   bo_big = ttm_bo_kunit_init(test, priv, size_big);
+
+   dma_resv_lock(bo_big->base.resv, NULL);
+   err = ttm_bo_validate(bo_big, placement, &ctx);
+   dma_resv_unlock(bo_big->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_NOT_NULL(test, bo_big->resource);
+   KUNIT_EXPECT_EQ(test, bo_big->resource->mem_type, mem_type);
+   KUNIT_EXPECT_EQ(test, bo_small->resource->mem_type, TTM_PL_SYSTEM);
+   KUNIT_EXPECT_TRUE(test, bo_small->ttm->page_flags & 
TTM_TT_FLAG_SWAPPED);
+
+   ttm_bo_put(bo_big);
+   ttm_bo_put(bo_small);
+
+   ttm_mock_manager_fini(priv->ttm_dev, mem_type);
+}
+
+static void ttm_bo_validate_happy_evict(struct kunit *test)
+{
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bos, *bo_val;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = ttm_bo_type_device;
+   uint32_t bo_no = 3;
+   uint32_t small = SZ_8K, medium = SZ_512K,
+big = MANAGER_SIZE - (small + medium);
+   uint32_t bo_sizes[] = { small, medium, big };
+   uint32_t mem_type = TTM_PL_VRAM, mem_type_evict = TTM_PL_SYSTEM;
+   struct ttm_operation_ctx ctx_init = { }, ctx_val  = { };
+   int i, err;
+
+   ttm_mock_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
+
+   place = ttm_place_kunit_init(test, mem_type, 0);
+   placement = ttm_placement_kunit_init(test, place, 1, place, 1);
+
+   bos = kunit_kmalloc_array(test, bo_no, sizeof(*bos), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bos);
+
+   memset(bos, 0, sizeof(*bos) * bo_no);
+   for (i = 0; i < bo_no; i++) {
+   drm_gem_private_object_init(priv->drm, &bos[i].base, 
bo_sizes[i]);
+   err = ttm_bo_init_reserved(priv->ttm_dev, &bos[i], bo_type, 
placement,
+  PAGE_SIZE, &ctx_init, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   dma_resv_unlock(bos[i].base.resv);
+   }
+
+   bo_val = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+   bo_val->type = bo_type;
+
+   ttm_bo_reserve(bo_val, false, false, NULL);
+   err = ttm_bo_validate(bo_val, placement, &ctx_val);
+   ttm_bo_unreserve(bo_val);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, bos[0].resource->mem_type, mem_type_evict);
+   KUNIT_EXPECT_TRUE(test, bos[0].ttm->page_flags & 
TTM_TT_FLAG_ZERO_ALLOC);
+   KUNIT_EXPECT_TRUE(test, bos[0].ttm->page_flag

[PATCH RESEND v9 4/8] drm/ttm/tests: Add tests with mock resource managers

[Karolina Stolarek]

Add mock resource manager to test ttm_bo_validate() with non-system
placements. Update KConfig entry to enable DRM Buddy allocator, used
by the mock manager. Update move function to do more than just assign
a resource.

Signed-off-by: Karolina Stolarek 
Reviewed-by: Christian König 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/Kconfig   |   1 +
 drivers/gpu/drm/ttm/tests/.kunitconfig|   1 +
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 276 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  39 ++-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   2 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  | 207 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |  31 ++
 8 files changed, 556 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 6ec33d36f3a4..b9b464fc4dd7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -201,6 +201,7 @@ config DRM_TTM_KUNIT_TEST
 default n
 depends on DRM && KUNIT && MMU
 select DRM_TTM
+select DRM_BUDDY
 select DRM_EXPORT_FOR_TESTS if m
 select DRM_KUNIT_TEST_HELPERS
 default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig 
b/drivers/gpu/drm/ttm/tests/.kunitconfig
index 75fdce0cd98e..9228ce9b913c 100644
--- a/drivers/gpu/drm/ttm/tests/.kunitconfig
+++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
@@ -2,3 +2,4 @@ CONFIG_KUNIT=y
 CONFIG_DRM=y
 CONFIG_DRM_KUNIT_TEST_HELPERS=y
 CONFIG_DRM_TTM_KUNIT_TEST=y
+CONFIG_DRM_BUDDY=y
diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 2e5ed63fb414..f3149de77541 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_tt_test.o \
 ttm_bo_test.o \
 ttm_bo_validate_test.o \
+ttm_mock_manager.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 1d50e4ba9775..5f6c24979f83 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -8,12 +8,15 @@
 #include 
 
 #include "ttm_kunit_helpers.h"
+#include "ttm_mock_manager.h"
 
 #define BO_SIZESZ_4K
+#define MANAGER_SIZE   SZ_1M
 
 struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
+   uint32_t mem_type;
bool with_ttm;
 };
 
@@ -106,6 +109,49 @@ static void ttm_bo_init_reserved_sys_man(struct kunit 
*test)
ttm_bo_put(bo);
 }
 
+static void ttm_bo_init_reserved_mock_man(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = params->bo_type;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t mem_type = TTM_PL_VRAM;
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   int err;
+
+   ttm_mock_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   place = ttm_place_kunit_init(test, mem_type, 0);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   drm_gem_private_object_init(priv->drm, &bo->base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+  PAGE_SIZE, &ctx, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
+   KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+   KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+   if (bo_type != ttm_bo_type_kernel)
+   KUNIT_EXPECT_TRUE(test,
+ 
drm_mm_node_allocated(&bo->base.vma_node.vm_node));
+
+   ttm_resource_free(bo, &bo->resource);
+   ttm_bo_put(bo);
+   ttm_mock_manager_fini(priv->ttm_dev, mem_type);
+}
+
 static void ttm_bo_init_reserved_resv(struct kunit *test)
 {
struct ttm_test_devices *priv = test->priv;
@@ -140,6 +186,51 @@ static void ttm_bo_init_reserved_resv(struct kunit *test)
ttm_bo_put(bo);
 }
 
+static void ttm_bo_validate_basic(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;

[PATCH RESEND v9 5/8] drm/ttm/tests: Add test cases dependent on fence signaling

[Karolina Stolarek]

Add test cases that check how the state of dma fences in BO's
reservation object influence the ttm_bo_validation() flow. Do similar
tests for resource manager's move fence.

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
---
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 305 ++
 1 file changed, 305 insertions(+)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 5f6c24979f83..bf4bae25aec9 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -2,6 +2,8 @@
 /*
  * Copyright © 2023 Intel Corporation
  */
+#include 
+#include 
 
 #include 
 #include 
@@ -13,11 +15,14 @@
 #define BO_SIZESZ_4K
 #define MANAGER_SIZE   SZ_1M
 
+static struct spinlock fence_lock;
+
 struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
uint32_t mem_type;
bool with_ttm;
+   bool no_gpu_wait;
 };
 
 static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
@@ -39,6 +44,43 @@ static struct ttm_placement *ttm_placement_kunit_init(struct 
kunit *test,
return placement;
 }
 
+static const char *fence_name(struct dma_fence *f)
+{
+   return "ttm-bo-validate-fence";
+}
+
+static const struct dma_fence_ops fence_ops = {
+   .get_driver_name = fence_name,
+   .get_timeline_name = fence_name,
+};
+
+static struct dma_fence *alloc_mock_fence(struct kunit *test)
+{
+   struct dma_fence *fence;
+
+   fence = kunit_kzalloc(test, sizeof(*fence), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, fence);
+
+   dma_fence_init(fence, &fence_ops, &fence_lock, 0, 0);
+
+   return fence;
+}
+
+static void dma_resv_kunit_active_fence_init(struct kunit *test,
+struct dma_resv *resv,
+enum dma_resv_usage usage)
+{
+   struct dma_fence *fence;
+
+   fence = alloc_mock_fence(test);
+   dma_fence_enable_sw_signaling(fence);
+
+   dma_resv_lock(resv, NULL);
+   dma_resv_reserve_fences(resv, 1);
+   dma_resv_add_fence(resv, fence, usage);
+   dma_resv_unlock(resv);
+}
+
 static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case 
*t,
  char *desc)
 {
@@ -460,6 +502,262 @@ static void ttm_bo_validate_multihop(struct kunit *test)
ttm_mock_manager_fini(priv->ttm_dev, final_mem);
 }
 
+static const struct ttm_bo_validate_test_case ttm_bo_no_placement_cases[] = {
+   {
+   .description = "Buffer object in system domain, no page vector",
+   },
+   {
+   .description = "Buffer object in system domain with an existing 
page vector",
+   .with_ttm = true,
+   },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_no_placement, ttm_bo_no_placement_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_validate_no_placement_signaled(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_tt *old_tt;
+   struct ttm_placement *placement;
+   struct ttm_resource_manager *man;
+   uint32_t mem_type = TTM_PL_SYSTEM;
+   enum ttm_bo_type bo_type = ttm_bo_type_device;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   uint32_t flags;
+   int err;
+
+   place = ttm_place_kunit_init(test, mem_type, 0);
+   man = ttm_manager_type(priv->ttm_dev, mem_type);
+
+   bo = ttm_bo_kunit_init(test, test->priv, size);
+   bo->type = bo_type;
+
+   if (params->with_ttm) {
+   old_tt = priv->ttm_dev->funcs->ttm_tt_create(bo, 0);
+   ttm_pool_alloc(&priv->ttm_dev->pool, old_tt, &ctx);
+   bo->ttm = old_tt;
+   }
+
+   err = ttm_resource_alloc(bo, place, &bo->resource);
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_ASSERT_EQ(test, man->usage, size);
+
+   placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, placement);
+
+   ttm_bo_reserve(bo, false, false, NULL);
+   err = ttm_bo_validate(bo, placement, &ctx);
+   ttm_bo_unreserve(bo);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_ASSERT_EQ(test, man->usage, 0);
+   KUNIT_ASSERT_NOT_NULL(test, bo->ttm);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, 0);
+
+   if (params->with_ttm) {
+   flags = bo->ttm->page_flags;
+
+   KUNIT_ASSERT_PTR_EQ(test, bo->ttm, old_tt);
+   KUNIT_ASSERT_FALSE(test, flags & TTM_TT_FLAG_PRIV_POPULATED);
+   KUNIT_ASSERT_TRUE(test, flags & TTM_TT_FLAG_ZERO_ALLOC);
+   }
+
+   ttm_bo_put(bo);
+}
+
+static int threaded_dma_resv_signal(v

[PATCH RESEND v9 3/8] drm/ttm/tests: Test simple BO creation and validation

[Karolina Stolarek]

Add tests for ttm_bo_init_reserved() and ttm_bo_validate() that use
sys manager. Define a simple move function in ttm_device_funcs. Expose
destroy callback of the buffer object to make testing of
ttm_bo_init_reserved() behaviour easier.

Signed-off-by: Karolina Stolarek 
Reviewed-by: Christian König 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 211 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  14 +-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   1 +
 4 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 468535f7eed2..2e5ed63fb414 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_resource_test.o \
 ttm_tt_test.o \
 ttm_bo_test.o \
+ttm_bo_validate_test.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
new file mode 100644
index ..1d50e4ba9775
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_4K
+
+struct ttm_bo_validate_test_case {
+   const char *description;
+   enum ttm_bo_type bo_type;
+   bool with_ttm;
+};
+
+static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
+ struct ttm_place *places,
+ unsigned int num_places,
+ struct ttm_place 
*busy_places,
+ unsigned int 
num_busy_places)
+{
+   struct ttm_placement *placement;
+
+   placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, placement);
+
+   placement->num_placement = num_places;
+   placement->placement = places;
+   placement->num_busy_placement = num_busy_places;
+   placement->busy_placement = busy_places;
+
+   return placement;
+}
+
+static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case 
*t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+static const struct ttm_bo_validate_test_case ttm_bo_type_cases[] = {
+   {
+   .description = "Buffer object for userspace",
+   .bo_type = ttm_bo_type_device,
+   },
+   {
+   .description = "Kernel buffer object",
+   .bo_type = ttm_bo_type_kernel,
+   },
+   {
+   .description = "Shared buffer object",
+   .bo_type = ttm_bo_type_sg,
+   },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_types, ttm_bo_type_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_init_reserved_sys_man(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = params->bo_type;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   int err;
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   drm_gem_private_object_init(priv->drm, &bo->base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+  PAGE_SIZE, &ctx, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
+   KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+   KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+   KUNIT_EXPECT_EQ(test, bo->page_alignment, PAGE_SIZE);
+   KUNIT_EXPECT_PTR_EQ(test, bo->destroy, &dummy_ttm_bo_destroy);
+   KUNIT_EXPECT_EQ(test, bo->pin_count, 0);
+   KUNIT_EXPECT_NULL(test, bo->bulk_move);
+   KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
+   KUNIT_EXPECT_FALSE(test, ttm_tt_is_populated(bo->ttm));
+   KUNIT_EXPECT_NOT_NULL(test, (void *)bo->base.resv->fences);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+   if (bo_type != ttm_bo_type_kernel)
+   KUNIT_EXPE

[PATCH RESEND v9 2/8] drm/ttm/tests: Use an init function from the helpers lib

[Karolina Stolarek]

Add a new helper function that also initializes the device. Use it in
ttm_tt test suite and delete the local definition.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 14 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |  1 +
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 15 +--
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 7b7c1fa805fc..899a54dbe443 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -150,6 +150,20 @@ int ttm_test_devices_init(struct kunit *test)
 }
 EXPORT_SYMBOL_GPL(ttm_test_devices_init);
 
+int ttm_test_devices_all_init(struct kunit *test)
+{
+   struct ttm_test_devices *priv;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, priv);
+
+   priv = ttm_test_devices_all(test);
+   test->priv = priv;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ttm_test_devices_all_init);
+
 void ttm_test_devices_fini(struct kunit *test)
 {
ttm_test_devices_put(test, test->priv);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index 2f51c833a536..53bb5834939f 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -39,6 +39,7 @@ void ttm_test_devices_put(struct kunit *test, struct 
ttm_test_devices *devs);
 
 /* Generic init/fini for tests that only need DRM/TTM devices */
 int ttm_test_devices_init(struct kunit *test);
+int ttm_test_devices_all_init(struct kunit *test);
 void ttm_test_devices_fini(struct kunit *test);
 
 #endif // TTM_KUNIT_HELPERS_H
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index fd4502c18de6..a33a426a814d 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -15,19 +15,6 @@ struct ttm_tt_test_case {
uint32_t extra_pages_num;
 };
 
-static int ttm_tt_test_init(struct kunit *test)
-{
-   struct ttm_test_devices *priv;
-
-   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
-   KUNIT_ASSERT_NOT_NULL(test, priv);
-
-   priv = ttm_test_devices_all(test);
-   test->priv = priv;
-
-   return 0;
-}
-
 static const struct ttm_tt_test_case ttm_tt_init_basic_cases[] = {
{
.description = "Page-aligned size",
@@ -285,7 +272,7 @@ static struct kunit_case ttm_tt_test_cases[] = {
 
 static struct kunit_suite ttm_tt_test_suite = {
.name = "ttm_tt",
-   .init = ttm_tt_test_init,
+   .init = ttm_test_devices_all_init,
.exit = ttm_test_devices_fini,
.test_cases = ttm_tt_test_cases,
 };
-- 
2.34.1

[PATCH RESEND v9 1/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

[Karolina Stolarek]

Remove a leftover definition of page order and pass an empty flag value
in ttm_pool_pre_populated().

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
Reviewed-by: Dominik Karol Piątkowski 
Acked-by: Christian König 
---
 drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 2d9cae8cd984..b97f7b6daf5b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -78,10 +78,9 @@ static struct ttm_pool *ttm_pool_pre_populated(struct kunit 
*test,
struct ttm_test_devices *devs = priv->devs;
struct ttm_pool *pool;
struct ttm_tt *tt;
-   unsigned long order = __fls(size / PAGE_SIZE);
int err;
 
-   tt = ttm_tt_kunit_init(test, order, caching, size);
+   tt = ttm_tt_kunit_init(test, 0, caching, size);
KUNIT_ASSERT_NOT_NULL(test, tt);
 
pool = kunit_kzalloc(test, sizeof(*pool), GFP_KERNEL);
-- 
2.34.1

[PATCH RESEND v9 0/8] Improve test coverage of TTM

[Karolina Stolarek]

Introduce tests for ttm_bo_validate()/ttm_bo_init_validate() that exercise
simple BO placement as well as eviction (including the case where the evict
domain also requires eviction to fit the incoming buffer). Prepare KUnit
helpers to handle such scenarios and add a mock VRAM manager. This series also
includes some updates to the helpers and more definitions used to define
"special" memory domains (e.g., one that can't allocate resources or is busy),
as well as a drive-by fix for one of the tests.

There are a couple of areas in which this test suite can be improved.
Suggestions for future work can be found in the TODO file, added as the final
patch in the series.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests

To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.

Many thanks,
Karolina

v9:
 - Drop tests with basic test cases, they are merged now
 - Add three final patches -- tests for ttm_tt_(un)populate, eviction testing
   and a TODO file, with suggestions on how to improve these tests
 - Delete the initialization of spinlock in
   ttm_bo_validate_move_fence_signaled(), it not used at all (Andi)
 - Just return the error code threaded_fence_signal(), don't save it to a
   local variable (Andi)
 - Use ttm_bo_unreserve() in tests checking different move fence states (Andi)

v8:
 - Add Tested-by tags to commits that introduce tests
 - Improve the comment for ttm_bo_reserve_deadlock() subtest (Andi)
 - Actually clean up the resource when "error_free_blocks" is hit in
   ttm_mock_manager_alloc(). Without that change, we hit
   DEBUG_LOCKS_WARN_ON(lock->magic != lock) warning when cleaning up
   the resource manager because we try clean up an incomplete, orphaned
   resource. That's not good, and this could bite us back in the future.

v7:
 - Drop size argument from ttm_place_kunit_init(), it's no longer needed
 - Delete a TODO comment from ttm_bo_validate_tests.c
 - First evict BOs before calling ttm_resource_manager_set_used() in
   ttm_mock_manager_fini()
 - Stop calling ttm_resource_manager_cleanup() as a part of the mock manager
   fini sequence. It frees a move fence that is allocated via KUnit allocator,
   which gets freed again as a part of the test cleanup
 - Set use_tt to true in mock manager and stop passing in the flag for it
 - Make ttm_dev_empty_funcs static
   (drivers/gpu/drm/ttm/tests/ttm_tt_test.c:232:25: sparse: sparse:
   symbol 'ttm_dev_empty_funcs' was not declared. Should it be static?)
 - Cast bo->base.resv->fences to a generic pointer before it's checked by
   KUnit (drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c:98:9:
   sparse: sparse: incompatible types in comparison expression (different
   base types))
 - Clean up mock managers in ttm_bo_validate_move_fence_not_signaled subtest

v6:
  - Include tests for ttm_bo_init_reserved() and ttm_bo_validate(), with
a mock resource manager (patches 6-8; no eviction testing)
  - Add ttm_test_devices_all_init() helper to also init ttm_device instance
  - Remove fpfn and lpfn from ttm_place_kunit_init() helper -- these fields
are neither used nor tested

v5:
  - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
  - First unreserve the object before calling ww_acquire_fini() in
ttm_bo_reserve_double_resv subtest
  - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to suggestions
how to fix it in a different way)
  - Use a genuine GEM object in ttm_buffer_object instead of an empty one

v3:
  - Instead of modifying the main TTM Makefile, use
EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are tested but
not widely exported. Thanks to this change, TTM tests can be built
as modules, even when non-exported functions are used
  - Change the description of a patch that fixes ttm_pool_pre_populated()

v2:
  - Remove Makefile for KUnit tests and move the definitions to the
TTM's one
  - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
are built as one. This allows building the tests as a module, even
if it uses functions that are not exported
  - Fix ttm_pool_pre_populated(); a wrong flag was passed to
ttm_tt_kunit_init() function

Karolina Stolarek (8):
  drm/ttm/tests: Fix argument in ttm_tt_kunit_init()
  drm/ttm/tests: Use an init function from the helpers lib
  drm/ttm/tests: Test simple BO creation and validation
  drm/ttm/tests: Add tests with mock resource managers
  drm/ttm/tests: Add test cases dependent on fence signaling
  drm/ttm/tests: Add eviction testing
  drm/ttm/tests: Add tests for ttm_tt_populate
  drm/ttm/tests: Add TODO file

 drivers/gpu/drm/Kconfig   |1 +
 drivers/gpu/drm/ttm/tests/.kunitconfig|1 +
 drivers/gpu/drm/ttm/tests/Makefile|2 +
 drivers/gpu/drm/ttm/tests/TODO|   24 +
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 1218 ++

[PATCH v5 2/2] phy: mtk-mipi-csi: add driver for CSI phy

[Julien Stephan]

From: Phi-bang Nguyen 

This is a new driver that supports the MIPI CSI CD-PHY version 0.5

The number of PHYs depend on the SoC.
Each PHY can support D-PHY only or CD-PHY configuration.
The driver supports only D-PHY mode, so CD-PHY
compatible PHY are configured in D-PHY mode.

Signed-off-by: Louis Kuo 
Signed-off-by: Phi-bang Nguyen 
[Julien Stephan: refactor code]
[Julien Stephan: simplify driver model: one instance per phy vs
one instance for all phys]
Co-developed-by: Julien Stephan 
Signed-off-by: Julien Stephan 
---
 MAINTAINERS   |   1 +
 drivers/phy/mediatek/Kconfig  |  12 +
 drivers/phy/mediatek/Makefile |   2 +
 .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h|  62 
 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c   | 294 ++
 5 files changed, 371 insertions(+)
 create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h
 create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 37dfa99b0eb0..ca413ff49d78 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13574,6 +13574,7 @@ M:  Julien Stephan 
 M: Andy Hsieh 
 S: Supported
 F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
+F: drivers/phy/mediatek/phy-mtk-mipi-csi-0-5*
 
 MEDIATEK MMC/SD/SDIO DRIVER
 M: Chaotian Jing 
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 3125ecb5d119..3849b7c87d28 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -58,6 +58,18 @@ config PHY_MTK_HDMI
help
  Support HDMI PHY for Mediatek SoCs.
 
+config PHY_MTK_MIPI_CSI_0_5
+   tristate "MediaTek MIPI CSI CD-PHY v0.5 Driver"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on OF
+   select GENERIC_PHY
+   help
+ Enable this to support the MIPI CSI CD-PHY receiver version 0.5.
+ The driver supports multiple CSI cdphy ports simultaneously.
+
+ To compile this driver as a module, choose M here: the
+ module will be called phy-mtk-mipi-csi-0-5.
+
 config PHY_MTK_MIPI_DSI
tristate "MediaTek MIPI-DSI Driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index c9a50395533e..f6e24a47e081 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -15,6 +15,8 @@ phy-mtk-hdmi-drv-y+= phy-mtk-hdmi-mt8173.o
 phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8195.o
 obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
 
+obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o
+
 phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
 phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
 phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h 
b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h
new file mode 100644
index ..97b4c27a1699
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2023, MediaTek Inc.
+ * Copyright (c) 2023, BayLibre Inc.
+ */
+
+#ifndef __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__
+#define __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__
+
+/*
+ * CSI1 and CSI2 are identical, and similar to CSI0. All CSIX macros are
+ * applicable to the three PHYs. Where differences exist, they are denoted by
+ * macro names using CSI0 and CSI1, the latter being applicable to CSI1 and
+ * CSI2 alike.
+ */
+
+#define MIPI_RX_ANA00_CSIXA0x
+#define RG_CSI0A_CPHY_EN   BIT(0)
+#define RG_CSIXA_EQ_PROTECT_EN BIT(1)
+#define RG_CSIXA_BG_LPF_EN BIT(2)
+#define RG_CSIXA_BG_CORE_ENBIT(3)
+#define RG_CSIXA_DPHY_L0_CKMODE_EN BIT(5)
+#define RG_CSIXA_DPHY_L0_CKSEL BIT(6)
+#define RG_CSIXA_DPHY_L1_CKMODE_EN BIT(8)
+#define RG_CSIXA_DPHY_L1_CKSEL BIT(9)
+#define RG_CSIXA_DPHY_L2_CKMODE_EN BIT(11)
+#define RG_CSIXA_DPHY_L2_CKSEL BIT(12)
+
+#define MIPI_RX_ANA18_CSIXA0x0018
+#define RG_CSI0A_L0_T0AB_EQ_IS GENMASK(5, 4)
+#define RG_CSI0A_L0_T0AB_EQ_BW GENMASK(7, 6)
+#define RG_CSI0A_L1_T1AB_EQ_IS GENMASK(21, 20)
+#define RG_CSI0A_L1_T1AB_EQ_BW GENMASK(23, 22)
+#define RG_CSI0A_L2_T1BC_EQ_IS GENMASK(21, 20)
+#define RG_CSI0A_L2_T1BC_EQ_BW GENMASK(23, 22)
+#define RG_CSI1A_L0_EQ_IS  GENMASK(5, 4)
+#define RG_CSI1A_L0_EQ_BW  GENMASK(7, 6)
+#define RG_CSI1A_L1_EQ_IS  GENMASK(21, 20)
+#define RG_CSI1A_L1_EQ_BW  GENMASK(23, 22)
+#define RG_CSI1A_L2_EQ_IS  GENMASK(5, 4

[PATCH v5 1/2] dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5

[Julien Stephan]

From: Florian Sylvestre 

This adds the bindings, for the MIPI CD-PHY module v0.5 embedded in
some Mediatek soc, such as the mt8365

Signed-off-by: Florian Sylvestre 
Signed-off-by: Julien Stephan 
Reviewed-by: Rob Herring 
---
 .../bindings/phy/mediatek,mt8365-csi-rx.yaml  | 79 +++
 MAINTAINERS   |  6 ++
 2 files changed, 85 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml

diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml 
b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
new file mode 100644
index ..2127a5732f73
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek, BayLibre
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt8365-csi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Sensor Interface MIPI CSI CD-PHY
+
+maintainers:
+  - Julien Stephan 
+  - Andy Hsieh 
+
+description:
+  The SENINF CD-PHY is a set of CD-PHY connected to the SENINF CSI-2
+  receivers. The number of PHYs depends on the SoC model.
+  Depending on the SoC model, each PHYs can be either CD-PHY or D-PHY only
+  capable.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt8365-csi-rx
+
+  reg:
+maxItems: 1
+
+  num-lanes:
+enum: [2, 3, 4]
+
+  '#phy-cells':
+enum: [0, 1]
+description: |
+  If the PHY doesn't support mode selection then #phy-cells must be 0 and
+  PHY mode is described using phy-type property.
+  If the PHY supports mode selection, then #phy-cells must be 1 and mode
+  is set in the PHY cells. Supported modes are:
+- PHY_TYPE_DPHY
+- PHY_TYPE_CPHY
+  See include/dt-bindings/phy/phy.h for constants.
+
+  phy-type:
+description:
+  If the PHY doesn't support mode selection then this set the operating 
mode.
+  See include/dt-bindings/phy/phy.h for constants.
+const: 10
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+  - compatible
+  - reg
+  - num-lanes
+  - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+soc {
+  #address-cells = <2>;
+  #size-cells = <2>;
+
+  csi0_rx: phy@11c1 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c1 0 0x2000>;
+num-lanes = <2>;
+#phy-cells = <1>;
+  };
+
+  csi1_rx: phy@11c12000 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c12000 0 0x2000>;
+phy-type = ;
+num-lanes = <2>;
+#phy-cells = <0>;
+  };
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index cc92b10a4cad..37dfa99b0eb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13569,6 +13569,12 @@ F: 
Documentation/devicetree/bindings/media/mediatek-vpu.txt
 F: drivers/media/platform/mediatek/vcodec/
 F: drivers/media/platform/mediatek/vpu/
 
+MEDIATEK MIPI-CSI CDPHY DRIVER
+M: Julien Stephan 
+M: Andy Hsieh 
+S: Supported
+F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
+
 MEDIATEK MMC/SD/SDIO DRIVER
 M: Chaotian Jing 
 S: Maintained
-- 
2.43.0

[PATCH v5 0/2] phy: mtk-mipi-csi: add driver for CSI phy

[Julien Stephan]

Adding a new driver for the MIPI CSI CD-PHY module v 0.5 embedded in
some Mediatek soc, such as the MT8365

This driver was adapted from 
https://patchwork.kernel.org/project/linux-mediatek/cover/20200708104023.3225-1-louis@mediatek.com/

v1 can be found here: 
https://lore.kernel.org/all/20230403071929.360911-1-jstep...@baylibre.com/

v2 can be found here: 
https://lore.kernel.org/all/20230515090551.1251389-1-jstep...@baylibre.com/

v3 can be found here: 
https://lore.kernel.org/all/20230524083033.486490-1-jstep...@baylibre.com/

v4 can be found here: 
https://lore.kernel.org/linux-phy/20230620121928.1231745-1-jstep...@baylibre.com/

Changelog
Changes in v5:
- rebase on latest master scheduled for 6.8-rc1
- sort alphabetically CONFIG_PHY_MTK_MIPI_CSI_0_5 in Kconfig and Makefile
- put lines under 100 chars on one line

Changes in v4:
include/dt-bindings/phy/phy.h:
- remove commit adding PHY_TYPE_CDPHY definition

Binding file:
- use the standard phy-type property instead of a custom one so
  rename mediatek,phy-type -> phy-type
- phy-type property is made optional: when present, describes the
  phy type and the operating mode
- phy-cell is modified to accept a phy argument representing the
  phy operating mode if phy-type is not specified
- adding new property num-lanes

Driver:
- add a custom xlate function to handle phy cells
- update probe function to retrieve the new value phy-type
  instead of the mediatek,phy-type
- remove useless struct define `struct mtk_mipi_dphy;`
- rename some functin/variable from `xx_dphy_xx` to `xx_cdphy_xx`
- update probe function to read num-lanes property

Changes in v3:
Binding file:
- rename compatible string
  mediatek,phy-mipi-csi-0-5 -> mediatek,mt8365-csi-rx
- rename binding file to be as compatible string
- change property mediatek,is_cdphy -> mediatek,phy-type using an
  enum value instead of boolean for scalability
- remove status property from example nodes
- rename example node name 'mipi_rx_csi0: mipi_rx_csi0@11c1' ->
  'csi0_rx: phy@11c1'
- put reg address in lower case

include/dt-bindings/phy/phy.h:
- add PHY_TYPE_CDPHY definition

Driver:
- rename compatible string
- rename property mediatek,is_cdphy -> mediatek,phy-type
- rename CSIx* macro to CSIX* (x -> X)
- fix style issue on the driver data structure
- update MODULE_DESCRIPTION as suggested by Angelo
  and update the kconfig module description to match it
- add dphy /cdphy eq tuning function to factor the code
  and increase readability
- fix typo __PHY_MTK__MIPI_CSI__C_0_5_RX_REG_H_ -->
  __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H_
- reword commit message to update my contributions
- added missing copyright
- added module name in Kconfig

Changes in v2:
- fix all comments on bindings
- move the binding chunk from driver to binding commit
- fix dt_binding_check error (reported by DT_CHECKER_FLAGS)
- use a more generic compatible string
- add a new dt properties to simplify the driver
  "mediatek,is_cdphy"
- rename the driver and the corresponding file to include
  version
- drop of_match_ptr()
- use devm_platform_ioremap_resource
- use phy-mtk-io.h api instead of regmap
- rework the driver to use dt nodes to declare PHY instead of an
  array in the driver
- remove useless define for unused registers
- remove support for CSI0A/B because it cannot be tested, and it
  simplifies the driver for a first review
- edit commit message and bindings to be more descriptive about the
  hardware

Florian Sylvestre (1):
  dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5

Phi-bang Nguyen (1):
  phy: mtk-mipi-csi: add driver for CSI phy

 .../bindings/phy/mediatek,mt8365-csi-rx.yaml  |  79 +
 MAINTAINERS   |   7 +
 drivers/phy/mediatek/Kconfig  |  12 +
 drivers/phy/mediatek/Makefile |   2 +
 .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h|  62 
 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c   | 294 ++
 6 files changed, 456 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
 create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h
 create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c

-- 
2.43.0

[PATCH v3 2/2] drm/imx/dcss: have all init functions use devres

[Philipp Stanner]

dcss currently allocates and ioremaps quite a few resources in its probe
function's call graph. Devres now provides convenient functions which
perform the same task but do the cleanup automatically.

Port all memory allocations and ioremap() calls to the devres
counterparts.

Signed-off-by: Philipp Stanner 
---
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 14 +++---
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 15 ---
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 12 ++--
 drivers/gpu/drm/imx/dcss/dcss-dev.h|  1 -
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 25 ++---
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 12 +++-
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 23 ---
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 24 +---
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 11 +++
 9 files changed, 30 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c 
b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
index c9b54bb2692d..58e12ec65f80 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
@@ -41,15 +41,15 @@ void dcss_blkctl_cfg(struct dcss_blkctl *blkctl)
 int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long blkctl_base)
 {
struct dcss_blkctl *blkctl;
+   struct device *dev = dcss->dev;
 
-   blkctl = kzalloc(sizeof(*blkctl), GFP_KERNEL);
+   blkctl = devm_kzalloc(dev, sizeof(*blkctl), GFP_KERNEL);
if (!blkctl)
return -ENOMEM;
 
-   blkctl->base_reg = ioremap(blkctl_base, SZ_4K);
+   blkctl->base_reg = devm_ioremap(dev, blkctl_base, SZ_4K);
if (!blkctl->base_reg) {
dev_err(dcss->dev, "unable to remap BLK CTRL base\n");
-   kfree(blkctl);
return -ENOMEM;
}
 
@@ -60,11 +60,3 @@ int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long 
blkctl_base)
 
return 0;
 }
-
-void dcss_blkctl_exit(struct dcss_blkctl *blkctl)
-{
-   if (blkctl->base_reg)
-   iounmap(blkctl->base_reg);
-
-   kfree(blkctl);
-}
diff --git a/drivers/gpu/drm/imx/dcss/dcss-ctxld.c 
b/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
index 3a84cb3209c4..444511d0f382 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
@@ -199,10 +199,11 @@ static int dcss_ctxld_alloc_ctx(struct dcss_ctxld *ctxld)
 
 int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long ctxld_base)
 {
+   struct device *dev = dcss->dev;
struct dcss_ctxld *ctxld;
int ret;
 
-   ctxld = kzalloc(sizeof(*ctxld), GFP_KERNEL);
+   ctxld = devm_kzalloc(dev, sizeof(*ctxld), GFP_KERNEL);
if (!ctxld)
return -ENOMEM;
 
@@ -217,7 +218,7 @@ int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long 
ctxld_base)
goto err;
}
 
-   ctxld->ctxld_reg = ioremap(ctxld_base, SZ_4K);
+   ctxld->ctxld_reg = devm_ioremap(dev, ctxld_base, SZ_4K);
if (!ctxld->ctxld_reg) {
dev_err(dcss->dev, "ctxld: unable to remap ctxld base\n");
ret = -ENOMEM;
@@ -226,18 +227,14 @@ int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long 
ctxld_base)
 
ret = dcss_ctxld_irq_config(ctxld, to_platform_device(dcss->dev));
if (ret)
-   goto err_irq;
+   goto err;
 
dcss_ctxld_hw_cfg(ctxld);
 
return 0;
 
-err_irq:
-   iounmap(ctxld->ctxld_reg);
-
 err:
dcss_ctxld_free_ctx(ctxld);
-   kfree(ctxld);
 
return ret;
 }
@@ -246,11 +243,7 @@ void dcss_ctxld_exit(struct dcss_ctxld *ctxld)
 {
free_irq(ctxld->irq, ctxld);
 
-   if (ctxld->ctxld_reg)
-   iounmap(ctxld->ctxld_reg);
-
dcss_ctxld_free_ctx(ctxld);
-   kfree(ctxld);
 }
 
 static int dcss_ctxld_enable_locked(struct dcss_ctxld *ctxld)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c 
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index d448bf1c205e..597e9b7bd4bf 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -109,8 +109,6 @@ static int dcss_submodules_init(struct dcss_dev *dcss)
dcss_ctxld_exit(dcss->ctxld);
 
 ctxld_err:
-   dcss_blkctl_exit(dcss->blkctl);
-
dcss_clocks_disable(dcss);
 
return ret;
@@ -124,7 +122,6 @@ static void dcss_submodules_stop(struct dcss_dev *dcss)
dcss_ss_exit(dcss->ss);
dcss_dtg_exit(dcss->dtg);
dcss_ctxld_exit(dcss->ctxld);
-   dcss_blkctl_exit(dcss->blkctl);
dcss_clocks_disable(dcss);
 }
 
@@ -190,7 +187,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
return ERR_PTR(-EBUSY);
}
 
-   dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
+   dcss = devm_kzalloc(dev, sizeof(*dcss), GFP_KERNEL);
if (!dcss)
return ERR_PTR(-ENOMEM);
 
@@ -201,7 +198,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)

[PATCH v3 1/2] drm/imx/dcss: request memory region

[Philipp Stanner]

The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.

Implement the region-request through the corresponding managed
devres-function.

Signed-off-by: Philipp Stanner 
---
 drivers/gpu/drm/imx/dcss/dcss-dev.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c 
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 4f3af0dfb344..d448bf1c205e 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -170,6 +170,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
struct resource *res;
struct dcss_dev *dcss;
const struct dcss_type_data *devtype;
+   resource_size_t res_len;
 
devtype = of_device_get_match_data(dev);
if (!devtype) {
@@ -183,6 +184,12 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
return ERR_PTR(-EINVAL);
}
 
+   res_len = res->end - res->start;
+   if (!devm_request_mem_region(dev, res->start, res_len, "dcss")) {
+   dev_err(dev, "cannot request memory region\n");
+   return ERR_PTR(-EBUSY);
+   }
+
dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
if (!dcss)
return ERR_PTR(-ENOMEM);
-- 
2.43.0

[PATCH v3 0/2] drm/imx/dcss: implement region request and devres

[Philipp Stanner]

OK, I messed up the ARM64 build. That's what you get for living on x86
for years and decades. Mea culpa. Should work now.

--

Changes in v3:
- Fix build errors (missing variable, forgotten remove to call of deleted
  function)

Changes in v2:
- Add the region-request to this patch-series. That was previously a
  separate patch.

dcss currently does not request its memory resource. This series adds
that request with devres. As we're at it, it also ports all the ioremaps
and associated allocations to devres.

I can build this, but I don't have the hardware available to test it. So
you might want to have a closer look.

P.

Philipp Stanner (2):
  drm/imx/dcss: request memory region
  drm/imx/dcss: have all init functions use devres

 drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 14 +++---
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 15 ---
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 19 +--
 drivers/gpu/drm/imx/dcss/dcss-dev.h|  1 -
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 25 ++---
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 12 +++-
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 23 ---
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 24 +---
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 11 +++
 9 files changed, 37 insertions(+), 107 deletions(-)

-- 
2.43.0

[PULL] drm-misc-next-fixes

[Maxime Ripard]

Hi,

Here's this week drm-misc-next-fixes PR.

Maxime

drm-misc-next-fixes-2024-01-11:
A fix for the v3d register readout, and two compilation fixes for
rockchip.
The following changes since commit eee706839333ec0643f1b4898a37588025bf4cb5:

  drm/imagination: pvr_device.h: fix all kernel-doc warnings (2024-01-02 
11:50:05 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2024-01-11

for you to fetch changes up to 89fe46019a62bc1d0cb49c9615cb3520096c4bc1:

  drm/v3d: Fix support for register debugging on the RPi 4 (2024-01-09 14:21:47 
-0300)


A fix for the v3d register readout, and two compilation fixes for
rockchip.


Cristian Ciocaltea (2):
  drm/rockchip: vop2: Drop superfluous include
  drm/rockchip: vop2: Drop unused if_dclk_rate variable

Maíra Canal (1):
  drm/v3d: Fix support for register debugging on the RPi 4

 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c |  4 +---
 drivers/gpu/drm/v3d/v3d_debugfs.c| 20 ++--
 2 files changed, 11 insertions(+), 13 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH] drm/edid: Clean up errors in drm_edid.h

[Jani Nikula]

On Thu, 11 Jan 2024, chenxuebing  wrote:
> Fix the following errors reported by checkpatch:
>
> ERROR: do not use assignment in if condition
>
> Signed-off-by: chenxuebing 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_edid.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 69c68804023f..9bcaf76f10fc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3611,7 +3611,8 @@ static bool mode_in_range(const struct drm_display_mode 
> *mode,
>   if (!mode_in_vsync_range(mode, edid, t))
>   return false;
>  
> - if ((max_clock = range_pixel_clock(edid, t)))
> + max_clock = range_pixel_clock(edid, t);
> + if (max_clock)
>   if (mode->clock > max_clock)
>   return false;

-- 
Jani Nikula, Intel

Re: [PATCH] drm: Clean up errors in drm_dp_mst_topology.h

[Jani Nikula]

On Thu, 11 Jan 2024, chenxuebing  wrote:
> Fix the following errors reported by checkpatch:
>
> ERROR: space prohibited before open square bracket '['

Same here, checkpatch just isn't clever enough to realize it's within a
macro.

BR,
Jani.

>
> Signed-off-by: chenxuebing 
> ---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index bd6c24d4213c..a4a24ec11b80 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -100,7 +100,7 @@ static bool drm_dp_mst_port_downstream_of_branch(struct 
> drm_dp_mst_port *port,
>  
>  #define DBG_PREFIX "[dp_mst]"
>  
> -#define DP_STR(x) [DP_ ## x] = #x
> +#define DP_STR(x)[DP_ ## x] = #x
>  
>  static const char *drm_dp_mst_req_type_str(u8 req_type)
>  {
> @@ -131,7 +131,7 @@ static const char *drm_dp_mst_req_type_str(u8 req_type)
>  }
>  
>  #undef DP_STR
> -#define DP_STR(x) [DP_NAK_ ## x] = #x
> +#define DP_STR(x)[DP_NAK_ ## x] = #x
>  
>  static const char *drm_dp_mst_nak_reason_str(u8 nak_reason)
>  {
> @@ -156,7 +156,7 @@ static const char *drm_dp_mst_nak_reason_str(u8 
> nak_reason)
>  }
>  
>  #undef DP_STR
> -#define DP_STR(x) [DRM_DP_SIDEBAND_TX_ ## x] = #x
> +#define DP_STR(x)[DRM_DP_SIDEBAND_TX_ ## x] = #x
>  
>  static const char *drm_dp_mst_sideband_tx_state_str(int state)
>  {

-- 
Jani Nikula, Intel

Re: [PATCH] drm: Clean up errors in drm_dp_helper.h

[Jani Nikula]

On Thu, 11 Jan 2024, chenxuebing  wrote:
> Fix the following errors reported by checkpatch:
>
> ERROR: space prohibited before open square bracket '['

Nah, checkpatch just isn't clever enough to realize it's within a macro.

BR,
Jani.

>
> Signed-off-by: chenxuebing 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index b1ca3a1100da..2704bf703040 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2133,7 +2133,7 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux)
>  }
>  EXPORT_SYMBOL(drm_dp_aux_unregister);
>  
> -#define PSR_SETUP_TIME(x) [DP_PSR_SETUP_TIME_ ## x >> 
> DP_PSR_SETUP_TIME_SHIFT] = (x)
> +#define PSR_SETUP_TIME(x)[DP_PSR_SETUP_TIME_ ## x >> 
> DP_PSR_SETUP_TIME_SHIFT] = (x)
>  
>  /**
>   * drm_dp_psr_setup_time() - PSR setup in time usec

-- 
Jani Nikula, Intel

Re: [PATCH] drm: use ATOMIC64_INIT() for atomic64_t

[Jani Nikula]

On Thu, 11 Jan 2024, Jonathan Gray  wrote:
> use ATOMIC64_INIT() not ATOMIC_INIT() for atomic64_t
>
> Fixes: 3f09a0cd4ea3 ("drm: Add common fdinfo helper")
> Signed-off-by: Jonathan Gray 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 446458aca8e9..d3b10dd91584 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -149,7 +149,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
>   */
>  struct drm_file *drm_file_alloc(struct drm_minor *minor)
>  {
> - static atomic64_t ident = ATOMIC_INIT(0);
> + static atomic64_t ident = ATOMIC64_INIT(0);

I think we should probably redefine both ATOMIC_INIT and ATOMIC64_INIT
to cast the result to the correct type to avoid this problem once and
for all.

If we had

#define ATOMIC_INIT(i) (atomic_t){ (i) }

and

#define ATOMIC64_INIT(i) (atomic64_t){ (i) }

we'd get a build failure using them incorrectly.

BR,
Jani.


>   struct drm_device *dev = minor->dev;
>   struct drm_file *file;
>   int ret;

-- 
Jani Nikula, Intel

[PATCH] drm/radeon/ni_dpm: Clean up errors in nislands_smc.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/nislands_smc.h | 51 +--
 1 file changed, 17 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/radeon/nislands_smc.h 
b/drivers/gpu/drm/radeon/nislands_smc.h
index 42f3bab0f9ee..097893c38915 100644
--- a/drivers/gpu/drm/radeon/nislands_smc.h
+++ b/drivers/gpu/drm/radeon/nislands_smc.h
@@ -27,8 +27,7 @@
 
 #define NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE 16
 
-struct PP_NIslands_Dpm2PerfLevel
-{
+struct PP_NIslands_Dpm2PerfLevel {
 uint8_t MaxPS;
 uint8_t TgtAct;
 uint8_t MaxPS_StepInc;
@@ -44,8 +43,7 @@ struct PP_NIslands_Dpm2PerfLevel
 
 typedef struct PP_NIslands_Dpm2PerfLevel PP_NIslands_Dpm2PerfLevel;
 
-struct PP_NIslands_DPM2Parameters
-{
+struct PP_NIslands_DPM2Parameters {
 uint32_tTDPLimit;
 uint32_tNearTDPLimit;
 uint32_tSafePowerLimit;
@@ -53,8 +51,7 @@ struct PP_NIslands_DPM2Parameters
 };
 typedef struct PP_NIslands_DPM2Parameters PP_NIslands_DPM2Parameters;
 
-struct NISLANDS_SMC_SCLK_VALUE
-{
+struct NISLANDS_SMC_SCLK_VALUE {
 uint32_tvCG_SPLL_FUNC_CNTL;
 uint32_tvCG_SPLL_FUNC_CNTL_2;
 uint32_tvCG_SPLL_FUNC_CNTL_3;
@@ -66,8 +63,7 @@ struct NISLANDS_SMC_SCLK_VALUE
 
 typedef struct NISLANDS_SMC_SCLK_VALUE NISLANDS_SMC_SCLK_VALUE;
 
-struct NISLANDS_SMC_MCLK_VALUE
-{
+struct NISLANDS_SMC_MCLK_VALUE {
 uint32_tvMPLL_FUNC_CNTL;
 uint32_tvMPLL_FUNC_CNTL_1;
 uint32_tvMPLL_FUNC_CNTL_2;
@@ -84,8 +80,7 @@ struct NISLANDS_SMC_MCLK_VALUE
 
 typedef struct NISLANDS_SMC_MCLK_VALUE NISLANDS_SMC_MCLK_VALUE;
 
-struct NISLANDS_SMC_VOLTAGE_VALUE
-{
+struct NISLANDS_SMC_VOLTAGE_VALUE {
 uint16_t value;
 uint8_t  index;
 uint8_t  padding;
@@ -93,8 +88,7 @@ struct NISLANDS_SMC_VOLTAGE_VALUE
 
 typedef struct NISLANDS_SMC_VOLTAGE_VALUE NISLANDS_SMC_VOLTAGE_VALUE;
 
-struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL
-{
+struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL {
 uint8_t arbValue;
 uint8_t ACIndex;
 uint8_t displayWatermark;
@@ -132,8 +126,7 @@ struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL
 
 typedef struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL 
NISLANDS_SMC_HW_PERFORMANCE_LEVEL;
 
-struct NISLANDS_SMC_SWSTATE
-{
+struct NISLANDS_SMC_SWSTATE {
uint8_t flags;
uint8_t levelCount;
uint8_t padding2;
@@ -156,8 +149,7 @@ struct NISLANDS_SMC_SWSTATE_SINGLE {
 #define NISLANDS_SMC_VOLTAGEMASK_VDDCI 2
 #define NISLANDS_SMC_VOLTAGEMASK_MAX   4
 
-struct NISLANDS_SMC_VOLTAGEMASKTABLE
-{
+struct NISLANDS_SMC_VOLTAGEMASKTABLE {
 uint8_t  highMask[NISLANDS_SMC_VOLTAGEMASK_MAX];
 uint32_t lowMask[NISLANDS_SMC_VOLTAGEMASK_MAX];
 };
@@ -166,8 +158,7 @@ typedef struct NISLANDS_SMC_VOLTAGEMASKTABLE 
NISLANDS_SMC_VOLTAGEMASKTABLE;
 
 #define NISLANDS_MAX_NO_VREG_STEPS 32
 
-struct NISLANDS_SMC_STATETABLE
-{
+struct NISLANDS_SMC_STATETABLE {
uint8_t thermalProtectType;
uint8_t systemFlags;
uint8_t maxVDDCIndexInPPTable;
@@ -203,8 +194,7 @@ typedef struct NISLANDS_SMC_STATETABLE 
NISLANDS_SMC_STATETABLE;
 #define SMC_NISLANDS_LKGE_LUT_NUM_OF_VOLT_ENTRIES 16
 #define SMC_NISLANDS_BIF_LUT_NUM_OF_ENTRIES 4
 
-struct SMC_NISLANDS_MC_TPP_CAC_TABLE
-{
+struct SMC_NISLANDS_MC_TPP_CAC_TABLE {
 uint32_ttpp[SMC_NISLANDS_MC_TPP_CAC_NUM_OF_ENTRIES];
 uint32_tcacValue[SMC_NISLANDS_MC_TPP_CAC_NUM_OF_ENTRIES];
 };
@@ -212,8 +202,7 @@ struct SMC_NISLANDS_MC_TPP_CAC_TABLE
 typedef struct SMC_NISLANDS_MC_TPP_CAC_TABLE SMC_NISLANDS_MC_TPP_CAC_TABLE;
 
 
-struct PP_NIslands_CACTABLES
-{
+struct PP_NIslands_CACTABLES {
 uint32_tcac_bif_lut[SMC_NISLANDS_BIF_LUT_NUM_OF_ENTRIES];
 uint32_t
cac_lkge_lut[SMC_NISLANDS_LKGE_LUT_NUM_OF_TEMP_ENTRIES][SMC_NISLANDS_LKGE_LUT_NUM_OF_VOLT_ENTRIES];
 
@@ -257,8 +246,7 @@ typedef struct PP_NIslands_CACTABLES PP_NIslands_CACTABLES;
 #define SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE 32
 #define SMC_NISLANDS_MC_REGISTER_ARRAY_SET_COUNT 20
 
-struct SMC_NIslands_MCRegisterAddress
-{
+struct SMC_NIslands_MCRegisterAddress {
 uint16_t s0;
 uint16_t s1;
 };
@@ -266,15 +254,13 @@ struct SMC_NIslands_MCRegisterAddress
 typedef struct SMC_NIslands_MCRegisterAddress SMC_NIslands_MCRegisterAddress;
 
 
-struct SMC_NIslands_MCRegisterSet
-{
+struct SMC_NIslands_MCRegisterSet {
 uint32_t value[SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE];
 };
 
 typedef struct SMC_NIslands_MCRegisterSet SMC_NIslands_MCRegisterSet;
 
-struct SMC_NIslands_MCRegisters
-{
+struct SMC_NIslands_MCRegisters {
 uint8_t last;
 uin

Re: [PATCH] gma500: Clean up errors in psb_intel_sdvo_regs.h

[Jani Nikula]

On Thu, 11 Jan 2024, GuoHua Chen  wrote:
> Fix the following errors reported by checkpatch:
>
> ERROR: space required after that close brace '}'
>
> Signed-off-by: GuoHua Chen 
> ---
>  drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h 
> b/drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h
> index 600e79744d68..e358a6b1bcce 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h
> +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo_regs.h
> @@ -666,7 +666,7 @@ struct psb_intel_sdvo_enhancement_limits_reply {
>  #define SDVO_CMD_SET_TV_LUMA_FILTER  0x79
>  struct psb_intel_sdvo_enhancements_arg {
>  u16 value;
> -}__attribute__((packed));
> +} __attribute__((packed));

__packed is preferred over __attribute__((packed)) anyway...

BR,
Jani.



>  
>  #define SDVO_CMD_GET_DOT_CRAWL   0x70
>  #define SDVO_CMD_SET_DOT_CRAWL   0x71

-- 
Jani Nikula, Intel

Re: [PATCH 5/6] drm: enable (most) W=1 warnings by default across the subsystem

[Jani Nikula]

On Wed, 10 Jan 2024, Hamza Mahfooz  wrote:
> On 1/10/24 12:39, Jani Nikula wrote:
>> At least the i915 and amd drivers enable a bunch more compiler warnings
>> than the kernel defaults.
>> 
>> Extend most of the W=1 warnings to the entire drm subsystem by
>> default. Use the copy-pasted warnings from scripts/Makefile.extrawarn
>> with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and
>> keep up with them in the future.
>> 
>> This is similar to the approach currently used in i915.
>> 
>> Some of the -Wextra warnings do need to be disabled, just like in
>> Makefile.extrawarn, but take care to not disable them for W=2 or W=3
>> builds, depending on the warning.
>> 
>> There are too many -Wformat-truncation warnings to cleanly fix up front;
>> leave that warning disabled for now.
>> 
>> v2:
>> - Drop -Wformat-truncation (too many warnings)
>> - Drop -Wstringop-overflow (enabled by default upstream)
>> 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Maarten Lankhorst 
>> Cc: Maxime Ripard 
>> Cc: Thomas Zimmermann 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>> Cc: Pan, Xinhui 
>> Cc: Karol Herbst 
>> Cc: Lyude Paul 
>> Cc: Danilo Krummrich 
>> Cc: Rob Clark 
>> Cc: Abhinav Kumar 
>> Cc: Dmitry Baryshkov 
>> Cc: Sean Paul 
>> Cc: Marijn Suijten 
>> Cc: Hamza Mahfooz 
>> Acked-by: Javier Martinez Canillas 
>> Acked-by: Thomas Zimmermann 
>> Acked-by: Sui Jingfeng 
>> Signed-off-by: Jani Nikula 
>> ---
>>   drivers/gpu/drm/Makefile | 27 +++
>>   1 file changed, 27 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 104b42df2e95..8b6be830f7c3 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -5,6 +5,33 @@
>>   
>>   CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
>>   
>> +# Unconditionally enable W=1 warnings locally
>> +# --- begin copy-paste W=1 warnings from scripts/Makefile.extrawarn
>> +subdir-ccflags-y += -Wextra -Wunused -Wno-unused-parameter
>> +subdir-ccflags-y += -Wmissing-declarations
>> +subdir-ccflags-y += $(call cc-option, -Wrestrict)
>
> It would be safer to do something along the lines of:
>
> cond-flags := $(call cc-option, -Wrestrict) \
>   $(call cc-option, -Wunused-but-set-variable) \
>   $(call cc-option, -Wunused-const-variable) \
>   $(call cc-option, -Wunused-const-variable) \
>   $(call cc-option, -Wformat-overflow) \
>   $(call cc-option, -Wstringop-truncation)
> subdir-ccflags-y += $(cond-flags)
>
> Otherwise, you will end up breaking `$ make M=drivers/gpu/drm`
> for a bunch of people.

I discussed this with Alex on IRC yesterday. The above seems obviously
correct in that it just changes the evaluation time of $(call cc-option,
...). Apparently not having it may lead to:

scripts/Makefile.lib:10: *** Recursive variable 'KBUILD_CFLAGS' references 
itself (eventually).  Stop.

Of course, I could just throw that in and be happy, but me being me, I'd
really like to know what is going on here first. :)

For one thing, I always thought M=dir was only for out-of-tree modules,
though the IRC discussion seems to indicate a lot of people also use it
for in-tree modules. But I can't even make it to work for a lot of cases
on top of current drm-tip, without the changes here.

M=drivers/gpu/drm/i915 fails immediately. So does
M=drivers/gpu/drm/amd. And M=drivers/gpu/drm/nouveau. And
M=drivers/gpu/drm/radeon.

M=drivers/gpu/drm fails with the same cases as above. I always use
KBUILD_OUTPUT=dir but I don't know if it makes a difference, I didn't
try.

However M=drivers/gpu/drm/amd/amdgpu works.

The only way I could reproduce the "recursive variable" issue in that
was using:

subdir-ccflags-y = -Wextra

instead of:

subdir-ccflags-y := -Wextra

or:

subdir-ccflags-y += -Wextra

in amdgpu/Makefile

Since I use the latter form in this pach, I think it should be fine for
M=dir users even if M=dir doesn't really seem to generally work for
in-tree modules (at least not for me).

Cc: Masahiro


BR,
Jani.


>
>> +subdir-ccflags-y += -Wmissing-format-attribute
>> +subdir-ccflags-y += -Wmissing-prototypes
>> +subdir-ccflags-y += -Wold-style-definition
>> +subdir-ccflags-y += -Wmissing-include-dirs
>> +subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable)
>> +subdir-ccflags-y += $(call cc-option, -Wunused-const-variable)
>> +subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned)
>> +subdir-ccflags-y += $(call cc-option, -Wformat-overflow)
>> +# FIXME: fix -Wformat-truncation warnings and uncomment
>> +#subdir-ccflags-y += $(call cc-option, -Wformat-truncation)
>> +subdir-ccflags-y += $(call cc-option, -Wstringop-truncation)
>> +# The following turn off the warnings enabled by -Wextra
>> +ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),)
>> +subdir-ccflags-y += -Wno-missing-field-initializers
>> +subdir-ccflags-y += -Wno-type-limits
>> +subdir-ccflags-y += -Wno-shift-negative-value
>> +endif
>> +ifeq ($(findstring 3, $(KBUILD_EXTRA_WARN)),)
>

[PATCH] drm/radeon/evergreen_cs: Clean up errors in evergreen_cs.c

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: space required after that ',' (ctx:VxV)
ERROR: spaces required around that '>' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 0de79f3a7e3f..1fe6e0d883c7 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -33,8 +33,8 @@
 #include "evergreen_reg_safe.h"
 #include "cayman_reg_safe.h"
 
-#define MAX(a,b)   (((a)>(b))?(a):(b))
-#define MIN(a,b)   (((a)<(b))?(a):(b))
+#define MAX(a, b)   (((a) > (b)) ? (a) : (b))
+#define MIN(a, b)   (((a) < (b)) ? (a) : (b))
 
 #define REG_SAFE_BM_SIZE ARRAY_SIZE(evergreen_reg_safe_bm)
 
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in si.c

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: that open brace { should be on the previous line
ERROR: trailing statements should be on next lineo

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/si.c | 63 +
 1 file changed, 22 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 85e9cba49cec..93f197d96d8f 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -138,8 +138,7 @@ static void si_fini_pg(struct radeon_device *rdev);
 static void si_fini_cg(struct radeon_device *rdev);
 static void si_rlc_stop(struct radeon_device *rdev);
 
-static const u32 crtc_offsets[] =
-{
+static const u32 crtc_offsets[] = {
EVERGREEN_CRTC0_REGISTER_OFFSET,
EVERGREEN_CRTC1_REGISTER_OFFSET,
EVERGREEN_CRTC2_REGISTER_OFFSET,
@@ -148,8 +147,7 @@ static const u32 crtc_offsets[] =
EVERGREEN_CRTC5_REGISTER_OFFSET
 };
 
-static const u32 si_disp_int_status[] =
-{
+static const u32 si_disp_int_status[] = {
DISP_INTERRUPT_STATUS,
DISP_INTERRUPT_STATUS_CONTINUE,
DISP_INTERRUPT_STATUS_CONTINUE2,
@@ -162,8 +160,7 @@ static const u32 si_disp_int_status[] =
 #define DC_HPDx_INT_CONTROL(x)(DC_HPD1_INT_CONTROL + (x * 0xc))
 #define DC_HPDx_INT_STATUS_REG(x) (DC_HPD1_INT_STATUS  + (x * 0xc))
 
-static const u32 verde_rlc_save_restore_register_list[] =
-{
+static const u32 verde_rlc_save_restore_register_list[] = {
(0x8000 << 16) | (0x98f4 >> 2),
0x,
(0x8040 << 16) | (0x98f4 >> 2),
@@ -384,8 +381,7 @@ static const u32 verde_rlc_save_restore_register_list[] =
0x
 };
 
-static const u32 tahiti_golden_rlc_registers[] =
-{
+static const u32 tahiti_golden_rlc_registers[] = {
0xc424, 0x, 0x00601005,
0xc47c, 0x, 0x10104040,
0xc488, 0x, 0x010a,
@@ -394,8 +390,7 @@ static const u32 tahiti_golden_rlc_registers[] =
0xf4a8, 0x, 0x
 };
 
-static const u32 tahiti_golden_registers[] =
-{
+static const u32 tahiti_golden_registers[] = {
0x9a10, 0x0001, 0x00018208,
0x9830, 0x, 0x,
0x9834, 0xf00f, 0x0400,
@@ -429,13 +424,11 @@ static const u32 tahiti_golden_registers[] =
0x15c0, 0x000c0fc0, 0x000c0400
 };
 
-static const u32 tahiti_golden_registers2[] =
-{
+static const u32 tahiti_golden_registers2[] = {
0xc64, 0x0001, 0x0001
 };
 
-static const u32 pitcairn_golden_rlc_registers[] =
-{
+static const u32 pitcairn_golden_rlc_registers[] = {
0xc424, 0x, 0x00601004,
0xc47c, 0x, 0x10102020,
0xc488, 0x, 0x0120,
@@ -443,8 +436,7 @@ static const u32 pitcairn_golden_rlc_registers[] =
0xc30c, 0x, 0x80a4
 };
 
-static const u32 pitcairn_golden_registers[] =
-{
+static const u32 pitcairn_golden_registers[] = {
0x9a10, 0x0001, 0x00018208,
0x9830, 0x, 0x,
0x9834, 0xf00f, 0x0400,
@@ -474,8 +466,7 @@ static const u32 pitcairn_golden_registers[] =
0x15c0, 0x000c0fc0, 0x000c0400
 };
 
-static const u32 verde_golden_rlc_registers[] =
-{
+static const u32 verde_golden_rlc_registers[] = {
0xc424, 0x, 0x033f1005,
0xc47c, 0x, 0x10808020,
0xc488, 0x, 0x0088,
@@ -483,8 +474,7 @@ static const u32 verde_golden_rlc_registers[] =
0xc30c, 0x, 0x80010014
 };
 
-static const u32 verde_golden_registers[] =
-{
+static const u32 verde_golden_registers[] = {
0x9a10, 0x0001, 0x00018208,
0x9830, 0x, 0x,
0x9834, 0xf00f, 0x0400,
@@ -539,8 +529,7 @@ static const u32 verde_golden_registers[] =
0x15c0, 0x000c0fc0, 0x000c0400
 };
 
-static const u32 oland_golden_rlc_registers[] =
-{
+static const u32 oland_golden_rlc_registers[] = {
0xc424, 0x, 0x00601005,
0xc47c, 0x, 0x10104040,
0xc488, 0x, 0x010a,
@@ -548,8 +537,7 @@ static const u32 oland_golden_rlc_registers[] =
0xc30c, 0x, 0x80f4
 };
 
-static const u32 oland_golden_registers[] =
-{
+static const u32 oland_golden_registers[] = {
0x9a10, 0x0001, 0x00018208,
0x9830, 0x, 0x,
0x9834, 0xf00f, 0x0400,
@@ -579,8 +567,7 @@ static const u32 oland_golden_registers[] =
0x15c0, 0x000c0fc0, 0x000c0400
 };
 
-static const u32 hainan_golden_registers[] =
-{
+static const u32 hainan_golden_registers[] = {
0x9a10, 0x0001, 0x00018208,
0x9830, 0x, 0x,
0x9834, 0xf00f, 0x0400,
@@ -608,13 +595,11 @@ static const u32 hainan_golden_registers[] =
0x15c0, 0x000c0fc0, 0x000c0400
 };
 
-static const u32 hainan_golden_registers2[] =
-{
+static const u32 hainan_golden_registers2[] = {
0x98f8, 0x, 0x02010001
 };
 
-static const u32 t

[PATCH] drm/radeon: Clean up errors in radeon.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/radeon.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3d3d2109dfeb..3e5ff17e3caf 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1355,14 +1355,12 @@ struct radeon_dpm_thermal {
bool   high_to_low;
 };
 
-enum radeon_clk_action
-{
+enum radeon_clk_action {
RADEON_SCLK_UP = 1,
RADEON_SCLK_DOWN
 };
 
-struct radeon_blacklist_clocks
-{
+struct radeon_blacklist_clocks {
u32 sclk;
u32 mclk;
enum radeon_clk_action action;
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in ci_dpm.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/ci_dpm.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.h b/drivers/gpu/drm/radeon/ci_dpm.h
index ac12db5f2cf7..74b95c200222 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.h
+++ b/drivers/gpu/drm/radeon/ci_dpm.h
@@ -87,8 +87,7 @@ struct ci_mc_reg_table {
SMU7_Discrete_MCRegisterAddress 
mc_reg_address[SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE];
 };
 
-struct ci_ulv_parm
-{
+struct ci_ulv_parm {
bool supported;
u32 cg_ulv_parameter;
u32 volt_change_delay;
@@ -113,8 +112,7 @@ struct ci_dpm_level_enable_mask {
u32 pcie_dpm_enable_mask;
 };
 
-struct ci_vbios_boot_state
-{
+struct ci_vbios_boot_state {
u16 mvdd_bootup_value;
u16 vddc_bootup_value;
u16 vddci_bootup_value;
-- 
2.17.1

[PATCH] drm/radeon/dpm: Clean up errors in evergreen_smc.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/evergreen_smc.h | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_smc.h 
b/drivers/gpu/drm/radeon/evergreen_smc.h
index 3a03ba37d043..b34d54b567b7 100644
--- a/drivers/gpu/drm/radeon/evergreen_smc.h
+++ b/drivers/gpu/drm/radeon/evergreen_smc.h
@@ -29,8 +29,7 @@
 
 #define SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE 16
 
-struct SMC_Evergreen_MCRegisterAddress
-{
+struct SMC_Evergreen_MCRegisterAddress {
 uint16_t s0;
 uint16_t s1;
 };
@@ -38,15 +37,13 @@ struct SMC_Evergreen_MCRegisterAddress
 typedef struct SMC_Evergreen_MCRegisterAddress SMC_Evergreen_MCRegisterAddress;
 
 
-struct SMC_Evergreen_MCRegisterSet
-{
+struct SMC_Evergreen_MCRegisterSet {
 uint32_t value[SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE];
 };
 
 typedef struct SMC_Evergreen_MCRegisterSet SMC_Evergreen_MCRegisterSet;
 
-struct SMC_Evergreen_MCRegisters
-{
+struct SMC_Evergreen_MCRegisters {
 uint8_t last;
 uint8_t reserved[3];
 SMC_Evergreen_MCRegisterAddress 
address[SMC_EVERGREEN_MC_REGISTER_ARRAY_SIZE];
-- 
2.17.1

Re: [PATCH 1/1] drm/virtio: Implement device_attach

[Christian König]

Am 11.01.24 um 09:52 schrieb Zhang, Julia:


On 2024/1/10 18:21, Daniel Vetter wrote:

On Wed, Jan 10, 2024 at 05:56:28PM +0800, Julia Zhang wrote:

drm_gem_map_attach() requires drm_gem_object_funcs.get_sg_table to be
implemented, or else return ENOSYS. Virtio has no get_sg_table
implemented for vram object. To fix this, add a new device_attach to
call drm_gem_map_attach() for shmem object and return 0 for vram object
instead of calling drm_gem_map_attach for both of these two kinds of
object.

Signed-off-by: Julia Zhang 
---
  drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 44425f20d91a..f0b0ff6f3813 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -71,6 +71,18 @@ static void virtgpu_gem_unmap_dma_buf(struct 
dma_buf_attachment *attach,
drm_gem_unmap_dma_buf(attach, sgt, dir);
  }
  
+static int virtgpu_gem_device_attach(struct dma_buf *dma_buf,

+struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = attach->dmabuf->priv;
+   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
+
+   if (virtio_gpu_is_vram(bo))
+   return 0;

You need to reject attach here because these vram buffer objects cannot be
used by any other driver. In that case dma_buf_attach _must_ fail, not
silently succeed.


Do you mean these vram buffer objects should not be imported by other drivers?


Because if it silently succeeds then the subsequent dma_buf_map_attachment
will blow up because you don't have the ->get_sg_table hook implemented.


I saw only this call stack would call ->get_sg_table:

#0 ->get_sg_table
#1 drm_gem_map_dma_buf
#2 virtgpu_gem_map_dma_buf
#3 __map_dma_buf
#4 dma_buf_dynamic_attach
#5 amdgpu_gem_prime_import

this stack is for shmem object and it requires ->get_sg_table get implemented.


But for vram object, __map_dma_buf will call like this:

#0 sg_alloc_table
#1 virtio_gpu_vram_map_dma_buf
#2 virtgpu_gem_map_dma_buf
#3 __map_dma_buf
#4 dma_buf_dynamic_attach
#5 amdgpu_gem_prime_import

which will not call ->get_sg_table but alloc a sg table instead and fill it 
from the vram object.


Yeah and exactly that won't work for this use case.

The VRAM of amdgpu is exposed through an MMIO BAR the guest can't access.


Before __map_dma_buf, the call stack of virtgpu_gem_device_attach is:

#0 virtgpu_gem_device_attach
#1 virtio_dma_buf_attach
#2 dma_buf_dynamic_attach
#3 amdgpu_gem_prime_import

So my problem is that to realize dGPU prime feature on VM, I actually want 
dma_buf_attach succeed
for vram object so that passthrough dGPU can import these vram objects and blit 
data to it.


That is completely futile effort, the dGPU physically can't access that 
stuff or otherwise we have a major security hole in the VM.



If here return -EBUSY, then amdgpu_gem_prime_import will fail and the whole 
feature will fail.


Yeah and that is completely intentional. Let's discuss that use case AMD 
internally first.


Regards,
Christian.




Per the documentation the error code for this case must be -EBUSY, see the
section for the attach hook here:

https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#c.dma_buf_ops

Since you're looking into this area, please make sure there's not other
similar mistake in virtio code.

Also can you please make a kerneldoc patch for struct virtio_dma_buf_ops
to improve the documentation there? I think it would be good to move those
to the inline style and then at least put a kernel-doc hyperlink to struct
dma_buf_ops.attach and mention that attach must fail for non-shareable
buffers.

In general the virtio_dma_buf kerneldoc seems to be on the "too minimal,
explains nothing" side of things :-/

OK, let me take a look and try to do it.

Regards,
Julia


Cheers, Sima


+
+   return drm_gem_map_attach(dma_buf, attach);
+}
+
  static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops =  {
.ops = {
.cache_sgt_mapping = true,
@@ -83,7 +95,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops =  {
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
},
-   .device_attach = drm_gem_map_attach,
+   .device_attach = virtgpu_gem_device_attach,
.get_uuid = virtgpu_virtio_get_uuid,
  };
  
--

2.34.1

RE: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> -Original Message-
> From: Laurent Pinchart 
> Sent: Wednesday, January 10, 2024 7:39 PM
> Subject: Re: [PATCH v15 3/5] drm: renesas: Add RZ/G2L DU Support
> 
> Hi Biju,
> 
> On Thu, Jan 04, 2024 at 02:17:39PM +, Biju Das wrote:
> > On Friday, December 15, 2023 2:56 PM, Biju Das wrote:
> > > On Friday, December 15, 2023 2:18 PM, Maxime Ripard wrote:
> > > > On Fri, Dec 15, 2023 at 01:52:28PM +, Biju Das wrote:
> > > > > > > > > > > +static int rzg2l_du_crtc_enable_vblank(struct
> drm_crtc *crtc) {
> > > > > > > > > > > + struct rzg2l_du_crtc *rcrtc = to_rzg2l_crtc(crtc);
> > > > > > > > > > > +
> > > > > > > > > > > + rcrtc->vblank_enable = true;
> > > > > > > > > > > +
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +static void rzg2l_du_crtc_disable_vblank(struct
> > > > > > > > > > > +drm_crtc *crtc) {
> > > > > > > > > > > + struct rzg2l_du_crtc *rcrtc = to_rzg2l_crtc(crtc);
> > > > > > > > > > > +
> > > > > > > > > > > + rcrtc->vblank_enable = false; }
> > > > > > > > > >
> > > > > > > > > > You should enable / disable your interrupts here
> > > > > > > > >
> > > > > > > > > We don't have dedicated vblank IRQ for enabling/disabling
> vblank.
> > > > > > > > >
> > > > > > > > > vblank is handled by vspd.
> > > > > > > > >
> > > > > > > > > vspd is directly rendering images to display,
> > > > > > > > > rcar_du_crtc_finish_page_flip() and
> > > > > > > > > drm_crtc_handle_vblank() called in vspd's pageflip
> context.
> > > > > > > > >
> > > > > > > > > See rzg2l_du_vsp_complete()in rzg2l_du_vsp.c
> > > > > > > >
> > > > > > > > Sorry, I couldn't really get how the interrupt flow /
> > > > > > > > vblank reporting is going to work. Could you explain it a
> bit more?
> > > > > > >
> > > > > > > We just need to handle vertical blanking in the VSP frame end
> handler.
> > > > > > > See the code below.
> > > > > > >
> > > > > > > static void rzg2l_du_vsp_complete(void *private, unsigned
> > > > > > > int status,
> > > > > > > u32 crc) {
> > > > > > >   struct rzg2l_du_crtc *crtc = private;
> > > > > > >
> > > > > > >   if (crtc->vblank_enable)
> > > > > > >   drm_crtc_handle_vblank(&crtc->crtc);
> > > > > > >
> > > > > > >   if (status & VSP1_DU_STATUS_COMPLETE)
> > > > > > >   rzg2l_du_crtc_finish_page_flip(crtc);
> > > > > > >
> > > > > > >   drm_crtc_add_crc_entry(&crtc->crtc, false, 0, &crc); }
> > > > > >
> > > > > > Then we're back to the same question :)
> > > > > >
> > > > > > Why can't you mask the frame end interrupt?
> > > > >
> > > > > We are masking interrupts.
> > > > >
> > > > > [   70.639139] ###rzg2l_du_crtc_disable_vblank###
> > > > > [   70.650243] #rzg2l_du_vsp_disable 
> > > > > [   70.652003] ## vsp1_wpf_stop###
> > > > >
> > > > > Unmask is,
> > > > >
> > > > > [ 176.354520] ###rzg2l_du_crtc_enable_vblank###
> > > > > [ 176.354922] #rzg2l_du_vsp_atomic_flush  [
> > > > > 176.355198] ## wpf_configure_stream###
> > > >
> > > > Sorry, my question was why aren't you unmasking and masking them
> > > > in the enable/disable_vblank hooks of the CRTC.
> > >
> > > I have n't tried that. Will try and provide feedback.
> > >
> > > Currently the IRQ source belongs to VSPD in media subsystem.
> > > So I need to export an API though vsp1_drm and test it.
> >
> > + linux-media
> >
> > Laurent, are you ok with the below RZ/G2L specific patch[1] for
> > enabling/disabling frame end interrupt in VSP driver?
> > Note:
> > I need to add a quirk for handling this only for RZ/G2L family as
> > other SoCs have Vblank specific interrupt available in DU.
> 
> The DU driver on Gen3 handles vblank exactly as in your patch. What's the
> problem with that ?

There is no issue. Maxime Ripard is checking whether is it possible to 
mask/unmask
Interrupt associated with vblank reporting during vblank{enable, disable}?

That is the reason I produced the below patch[1] for suggestions.

> 
> > [1]
> >
> > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > index 9b087bd8df7d..39347c16bb27 100644
> > --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > @@ -936,6 +936,14 @@ void vsp1_du_unmap_sg(struct device *dev, struct
> > sg_table *sgt)  }  EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
> >
> > +void vsp1_du_mask_frame_end_interrupt(struct device *dev, bool mask)
> > +{
> > +   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> > +
> > +   vsp1_write(vsp1, VI6_WPF_IRQ_ENB(0), mask ? 0 :
> > + VI6_WPF_IRQ_ENB_DFEE);
> 
> That will break everything. As soon as you turn of vblank reporting, the
> VSP will stop processing frames and the display will freeze.

OK. I am not able to reproduce this issue on RZ/G2L with limited testing 
compared to
R-Car. As per your suggestion, I will drop this change. I ho

[PATCH] drm/radeon: Clean up errors in clearstate_cayman.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/clearstate_cayman.h | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/clearstate_cayman.h 
b/drivers/gpu/drm/radeon/clearstate_cayman.h
index 4774e04c4da6..7693fb6624a3 100644
--- a/drivers/gpu/drm/radeon/clearstate_cayman.h
+++ b/drivers/gpu/drm/radeon/clearstate_cayman.h
@@ -23,8 +23,7 @@
 
 #include "clearstate_defs.h"
 
-static const u32 SECT_CONTEXT_def_1[] =
-{
+static const u32 SECT_CONTEXT_def_1[] = {
 0x, // DB_RENDER_CONTROL
 0x, // DB_COUNT_CONTROL
 0x, // DB_DEPTH_VIEW
@@ -514,8 +513,7 @@ static const u32 SECT_CONTEXT_def_1[] =
 0x, // CB_BLEND6_CONTROL
 0x, // CB_BLEND7_CONTROL
 };
-static const u32 SECT_CONTEXT_def_2[] =
-{
+static const u32 SECT_CONTEXT_def_2[] = {
 0x, // PA_CL_POINT_X_RAD
 0x, // PA_CL_POINT_Y_RAD
 0x, // PA_CL_POINT_SIZE
@@ -523,8 +521,7 @@ static const u32 SECT_CONTEXT_def_2[] =
 0x, // VGT_DMA_BASE_HI
 0x, // VGT_DMA_BASE
 };
-static const u32 SECT_CONTEXT_def_3[] =
-{
+static const u32 SECT_CONTEXT_def_3[] = {
 0x, // DB_DEPTH_CONTROL
 0x, // DB_EQAA
 0x, // CB_COLOR_CONTROL
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in pptable.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line
ERROR: space required after that close brace '}'

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/pptable.h | 204 +--
 1 file changed, 82 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/radeon/pptable.h b/drivers/gpu/drm/radeon/pptable.h
index 94947229888b..594050be1cbd 100644
--- a/drivers/gpu/drm/radeon/pptable.h
+++ b/drivers/gpu/drm/radeon/pptable.h
@@ -90,22 +90,19 @@ typedef struct _ATOM_PPLIB_FANTABLE
 USHORT  usPWMHigh;   // The PWM value at THigh.
 } ATOM_PPLIB_FANTABLE;
 
-typedef struct _ATOM_PPLIB_FANTABLE2
-{
+typedef struct _ATOM_PPLIB_FANTABLE2 {
 ATOM_PPLIB_FANTABLE basicTable;
 USHORT  usTMax;  // The max temperature
 } ATOM_PPLIB_FANTABLE2;
 
-typedef struct _ATOM_PPLIB_FANTABLE3
-{
+typedef struct _ATOM_PPLIB_FANTABLE3 {
ATOM_PPLIB_FANTABLE2 basicTable2;
UCHAR ucFanControlMode;
USHORT usFanPWMMax;
USHORT usFanOutputSensitivity;
 } ATOM_PPLIB_FANTABLE3;
 
-typedef struct _ATOM_PPLIB_EXTENDEDHEADER
-{
+typedef struct _ATOM_PPLIB_EXTENDEDHEADER {
 USHORT  usSize;
 ULONG   ulMaxEngineClock;   // For Overdrive.
 ULONG   ulMaxMemoryClock;   // For Overdrive.
@@ -144,8 +141,7 @@ typedef struct _ATOM_PPLIB_EXTENDEDHEADER
 #define ATOM_PP_PLATFORM_CAP_TEMP_INVERSION   0x0040// Does 
the driver supports Temp Inversion feature.
 #define ATOM_PP_PLATFORM_CAP_EVV0x0080
 
-typedef struct _ATOM_PPLIB_POWERPLAYTABLE
-{
+typedef struct _ATOM_PPLIB_POWERPLAYTABLE {
   ATOM_COMMON_TABLE_HEADER sHeader;
 
   UCHAR ucDataRevision;
@@ -178,23 +174,20 @@ typedef struct _ATOM_PPLIB_POWERPLAYTABLE
 
 } ATOM_PPLIB_POWERPLAYTABLE;
 
-typedef struct _ATOM_PPLIB_POWERPLAYTABLE2
-{
+typedef struct _ATOM_PPLIB_POWERPLAYTABLE2 {
 ATOM_PPLIB_POWERPLAYTABLE basicTable;
 UCHAR   ucNumCustomThermalPolicy;
 USHORT  usCustomThermalPolicyArrayOffset;
-}ATOM_PPLIB_POWERPLAYTABLE2, *LPATOM_PPLIB_POWERPLAYTABLE2;
+} ATOM_PPLIB_POWERPLAYTABLE2, *LPATOM_PPLIB_POWERPLAYTABLE2;
 
-typedef struct _ATOM_PPLIB_POWERPLAYTABLE3
-{
+typedef struct _ATOM_PPLIB_POWERPLAYTABLE3 {
 ATOM_PPLIB_POWERPLAYTABLE2 basicTable2;
 USHORT usFormatID;  // To be used 
ONLY by PPGen.
 USHORT usFanTableOffset;
 USHORT usExtendendedHeaderOffset;
 } ATOM_PPLIB_POWERPLAYTABLE3, *LPATOM_PPLIB_POWERPLAYTABLE3;
 
-typedef struct _ATOM_PPLIB_POWERPLAYTABLE4
-{
+typedef struct _ATOM_PPLIB_POWERPLAYTABLE4 {
 ATOM_PPLIB_POWERPLAYTABLE3 basicTable3;
 ULONG  ulGoldenPPID;// PPGen use 
only 
 ULONG  ulGoldenRevision;// PPGen use 
only
@@ -206,8 +199,7 @@ typedef struct _ATOM_PPLIB_POWERPLAYTABLE4
 USHORT usMvddDependencyOnMCLKOffset;  
 } ATOM_PPLIB_POWERPLAYTABLE4, *LPATOM_PPLIB_POWERPLAYTABLE4;
 
-typedef struct _ATOM_PPLIB_POWERPLAYTABLE5
-{
+typedef struct _ATOM_PPLIB_POWERPLAYTABLE5 {
 ATOM_PPLIB_POWERPLAYTABLE4 basicTable4;
 ULONG  ulTDPLimit;
 ULONG  ulNearTDPLimit;
@@ -283,20 +275,18 @@ typedef struct _ATOM_PPLIB_POWERPLAYTABLE5
 #define ATOM_PPLIB_ENABLE_DRR   0x0008
 
 // remaining 16 bits are reserved
-typedef struct _ATOM_PPLIB_THERMAL_STATE
-{
+typedef struct _ATOM_PPLIB_THERMAL_STATE {
 UCHAR   ucMinTemperature;
 UCHAR   ucMaxTemperature;
 UCHAR   ucThermalAction;
-}ATOM_PPLIB_THERMAL_STATE, *LPATOM_PPLIB_THERMAL_STATE;
+} ATOM_PPLIB_THERMAL_STATE, *LPATOM_PPLIB_THERMAL_STATE;
 
 // Contained in an array starting at the offset
 // in ATOM_PPLIB_POWERPLAYTABLE::usNonClockInfoArrayOffset.
 // referenced from ATOM_PPLIB_STATE_INFO::ucNonClockStateIndex
 #define ATOM_PPLIB_NONCLOCKINFO_VER1  12
 #define ATOM_PPLIB_NONCLOCKINFO_VER2  24
-typedef struct _ATOM_PPLIB_NONCLOCK_INFO
-{
+typedef struct _ATOM_PPLIB_NONCLOCK_INFO {
   USHORT usClassification;
   UCHAR  ucMinTemperature;
   UCHAR  ucMaxTemperature;
@@ -311,8 +301,7 @@ typedef struct _ATOM_PPLIB_NONCLOCK_INFO
 // Contained in an array starting at the offset
 // in ATOM_PPLIB_POWERPLAYTABLE::usClockInfoArrayOffset.
 // referenced from ATOM_PPLIB_STATE::ucClockStateIndices
-typedef struct _ATOM_PPLIB_R600_CLOCK_INFO
-{
+typedef struct _ATOM_PPLIB_R600_CLOCK_INFO {
   USHORT usEngineClockLow;
   UCHAR ucEngineClockHigh;
 
@@ -335,9 +324,7 @@ typedef struct _ATOM_PPLIB_R600_CLOCK_INFO
 #define ATOM_PPLIB_R600_FLAGS_MEMORY_DLL_OFF   16
 #define ATOM_PPLIB_R600_FLAGS_LOWPOWER 32   // On the RV770 use 'low 
power' setting (sequencer S0).
 
-typedef struct _ATOM_PPLIB_RS780_CLOCK_INFO
-
-{
+typedef struct _ATOM_PPLIB_RS780_CLOCK_INFO {
   USHORT usLowEngineClockLow; // Lo

[PATCH] drm/radeon: Clean up errors in clearstate_ci.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: that open brace { should be on the previous line

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/clearstate_ci.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/clearstate_ci.h 
b/drivers/gpu/drm/radeon/clearstate_ci.h
index c1b6c22dbed7..0045d42aa27c 100644
--- a/drivers/gpu/drm/radeon/clearstate_ci.h
+++ b/drivers/gpu/drm/radeon/clearstate_ci.h
@@ -23,8 +23,7 @@
 
 #include "clearstate_defs.h"
 
-static const unsigned int ci_SECT_CONTEXT_def_1[] =
-{
+static const unsigned int ci_SECT_CONTEXT_def_1[] = {
 0x, // DB_RENDER_CONTROL
 0x, // DB_COUNT_CONTROL
 0x, // DB_DEPTH_VIEW
-- 
2.17.1

Re: [PATCH v5 0/8] iio: new DMABUF based API, v5

[Paul Cercueil]

Hi Andrew,

Le lundi 08 janvier 2024 à 15:12 -0600, Andrew Davis a écrit :
> On 12/19/23 11:50 AM, Paul Cercueil wrote:
> > [V4 was: "iio: Add buffer write() support"][1]
> > 
> > Hi Jonathan,
> > 
> > This is a respin of the V3 of my patchset that introduced a new
> > interface based on DMABUF objects [2].
> > 
> > The V4 was a split of the patchset, to attempt to upstream buffer
> > write() support first. But since there is no current user upstream,
> > it
> > was not merged. This V5 is about doing the opposite, and contains
> > the
> > new DMABUF interface, without adding the buffer write() support. It
> > can
> > already be used with the upstream adi-axi-adc driver.
> > 
> > In user-space, Libiio uses it to transfer back and forth blocks of
> > samples between the hardware and the applications, without having
> > to
> > copy the data.
> > 
> > On a ZCU102 with a FMComms3 daughter board, running Libiio from the
> > pcercuei/dev-new-dmabuf-api branch [3], compiled with
> > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
> >    sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
> >    Throughput: 116 MiB/s
> > 
> > Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON):
> >    sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
> >    Throughput: 475 MiB/s
> > 
> > This benchmark only measures the speed at which the data can be
> > fetched
> > to iio_rwdev's internal buffers, and does not actually try to read
> > the
> > data (e.g. to pipe it to stdout). It shows that fetching the data
> > is
> > more than 4x faster using the new interface.
> > 
> > When actually reading the data, the performance difference isn't
> > that
> > impressive (maybe because in case of DMABUF the data is not in
> > cache):
> > 
> > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
> >    sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
> > status=progress
> >    2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s
> > 
> > WITH_LOCAL_DMABUF_API=ON:
> >    sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
> > status=progress
> >    2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s
> > 
> > One interesting thing to note is that fileio is (currently)
> > actually
> > faster than the DMABUF interface if you increase a lot the buffer
> > size.
> > My explanation is that the cache invalidation routine takes more
> > and
> > more time the bigger the DMABUF gets. This is because the DMABUF is
> > backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by
> > up
> > to 16 thousands pages, that have to be invalidated one by one. This
> > can
> > be addressed by using huge pages, but the udmabuf driver does not
> > (yet)
> > support creating DMABUFs backed by huge pages.
> > 
> 
> Have you tried DMABUFs created using the DMABUF System heap exporter?
> (drivers/dma-buf/heaps/system_heap.c) It should be able to handle
> larger allocation better here, and if you don't have any active
> mmaps or vmaps then it can skip CPU-side coherency maintenance
> (useful for device to device transfers).

I didn't know about it!

But udmabuf also allows you to skip CPU-side coherency maintenance,
since DMABUFs have two ioctls to start/finish CPU access anyway.

> Allocating DMABUFs out of user pages has a bunch of other issues you
> might run into also. I'd argue udmabuf is now completely superseded
> by DMABUF system heaps. Try it out :)

I'm curious, what other issues?

The good thing about udmabuf is that the memory is backed by pages, so
we can use MSG_ZEROCOPY on sockets to transfer the mmapped data over
the network (having a DMABUF interface to the network stack would be
better, but I'm not opening that can of worms).

> Andrew

Cheers,
-Paul

> > Anyway, the real benefits happen when the DMABUFs are either shared
> > between IIO devices, or between the IIO subsystem and another
> > filesystem. In that case, the DMABUFs are simply passed around
> > drivers,
> > without the data being copied at any moment.
> > 
> > We use that feature to transfer samples from our transceivers to
> > USB,
> > using a DMABUF interface to FunctionFS [4].
> > 
> > This drastically increases the throughput, to about 274 MiB/s over
> > a
> > USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to
> > the
> > FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load
> > avg.).
> > 
> > Based on linux-next/next-20231219.
> > 
> > Cheers,
> > -Paul
> > 
> > [1]
> > https://lore.kernel.org/all/20230807112113.47157-1-p...@crapouillou.net/
> > [2]
> > https://lore.kernel.org/all/20230403154800.215924-1-p...@crapouillou.net/
> > [3]
> > https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api
> > [4]
> > https://lore.kernel.org/all/20230322092118.9213-1-p...@crapouillou.net/
> > 
> > ---
> > Changelog:
> > - [3/8]: Replace V3's dmaengine_prep_slave_dma_array() with a new
> >    dmaengine_prep_slave_dma_vec(), which uses a new 'dma_vec'
> > struct.
> >    Note that at some point we will need to support

[PATCH] drm/radeon: Clean up errors in atombios.h

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line
ERROR: space required after that close brace '}'

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/atombios.h | 135 --
 1 file changed, 54 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios.h 
b/drivers/gpu/drm/radeon/atombios.h
index 2db40789235c..141dc17ba632 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -197,19 +197,17 @@
   Every table pointed  _ATOM_MASTER_DATA_TABLE has this common header. 
   And the pointer actually points to this header. */
 
-typedef struct _ATOM_COMMON_TABLE_HEADER
-{
+typedef struct _ATOM_COMMON_TABLE_HEADER {
   USHORT usStructureSize;
   UCHAR  ucTableFormatRevision;   /*Change it when the Parser is not backward 
compatible */
   UCHAR  ucTableContentRevision;  /*Change it only when the table needs to 
change but the firmware */
   /*Image can't be updated, while Driver needs 
to carry the new table! */
-}ATOM_COMMON_TABLE_HEADER;
+} ATOM_COMMON_TABLE_HEADER;
 
 // 
 // Structure stores the ROM header.
 // 
-typedef struct _ATOM_ROM_HEADER
-{
+typedef struct _ATOM_ROM_HEADER {
   ATOM_COMMON_TABLE_HEADER sHeader;
   UCHAR uaFirmWareSignature[4];/*Signature to distinguish between 
Atombios and non-atombios, 
   atombios should init it as "ATOM", don't 
change the position */
@@ -228,7 +226,7 @@ typedef struct _ATOM_ROM_HEADER
   USHORT usMasterDataTableOffset;   /*Offset for SW to get all data table 
offsets, Don't change the position */
   UCHAR  ucExtendedFunctionCode;
   UCHAR  ucReserved;
-}ATOM_ROM_HEADER;
+} ATOM_ROM_HEADER;
 
 /*==Command Table 
Portion */
 
@@ -342,17 +340,15 @@ typedef struct _ATOM_MASTER_LIST_OF_COMMAND_TABLES{
 #define LCD1OutputControlHW_Misc_Operation
 #define TV1OutputControl Gfx_Harvesting
 
-typedef struct _ATOM_MASTER_COMMAND_TABLE
-{
+typedef struct _ATOM_MASTER_COMMAND_TABLE {
   ATOM_COMMON_TABLE_HEADER   sHeader;
   ATOM_MASTER_LIST_OF_COMMAND_TABLES ListOfCommandTables;
-}ATOM_MASTER_COMMAND_TABLE;
+} ATOM_MASTER_COMMAND_TABLE;
 
 // 
 // Structures used in every command table
 // 
-typedef struct _ATOM_TABLE_ATTRIBUTE
-{
+typedef struct _ATOM_TABLE_ATTRIBUTE {
 #if ATOM_BIG_ENDIAN
   USHORT  UpdatedByUtility:1; //[15]=Table updated by utility flag
   USHORT  PS_SizeInBytes:7;   //[14:8]=Size of parameter space in 
Bytes (multiple of a dword), 
@@ -362,24 +358,22 @@ typedef struct _ATOM_TABLE_ATTRIBUTE
   USHORT  PS_SizeInBytes:7;   //[14:8]=Size of parameter space in 
Bytes (multiple of a dword), 
   USHORT  UpdatedByUtility:1; //[15]=Table updated by utility flag
 #endif
-}ATOM_TABLE_ATTRIBUTE;
+} ATOM_TABLE_ATTRIBUTE;
 
-typedef union _ATOM_TABLE_ATTRIBUTE_ACCESS
-{
+typedef union _ATOM_TABLE_ATTRIBUTE_ACCESS {
   ATOM_TABLE_ATTRIBUTE sbfAccess;
   USHORT   susAccess;
-}ATOM_TABLE_ATTRIBUTE_ACCESS;
+} ATOM_TABLE_ATTRIBUTE_ACCESS;
 
 // 
 // Common header for all command tables.
 // Every table pointed by _ATOM_MASTER_COMMAND_TABLE has this common header. 
 // And the pointer actually points to this header.
 // 
-typedef struct _ATOM_COMMON_ROM_COMMAND_TABLE_HEADER
-{
+typedef struct _ATOM_COMMON_ROM_COMMAND_TABLE_HEADER {
   ATOM_COMMON_TABLE_HEADER CommonHeader;
   ATOM_TABLE_ATTRIBUTE TableAttribute; 
-}ATOM_COMMON_ROM_COMMAND_TABLE_HEADER;
+} ATOM_COMMON_ROM_COMMAND_TABLE_HEADER;
 
 // 
 // Structures used by ComputeMemoryEnginePLLTable
@@ -391,8 +385,7 @@ typedef struct _ATOM_COMMON_ROM_COMMAND_TABLE_HEADER
 // 
 // Structures used by AdjustMemoryControllerTable
 // 
-typedef struct _ATOM_ADJUST_MEMORY_CLOCK_FREQ
-{
+typedef struct _ATOM_ADJUST_MEMORY_CLOCK_FREQ {
 #if ATOM_BIG_ENDIAN
   ULONG ulPointerReturnFlag:1;  // BYTE_3[7]=1 - Return the pointer to the 
right Data Block; BYTE_3[7]=0 - Program the right Data Block 
   ULONG ulMemoryModuleNumber:7; // BYTE_3[6:0]
@@ -402,25 +395,23 @@ typedef struct _ATOM_ADJUST_MEMORY_CLOCK_FREQ
   ULONG ulMemoryModuleNumber:7; // BYTE_3[6:

[PATCH] drm/radeon/kms: Clean up errors in radeon_pm.c

[XueBing Chen]

Fix the following errors reported by checkpatch:

ERROR: space required before the open parenthesis '('

Signed-off-by: XueBing Chen 
---
 drivers/gpu/drm/radeon/radeon_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index b73fd9ab0252..4482c8c5f5ce 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -587,7 +587,7 @@ static ssize_t radeon_hwmon_set_pwm1_enable(struct device 
*dev,
int err;
int value;
 
-   if(!rdev->asic->dpm.fan_ctrl_set_mode)
+   if (!rdev->asic->dpm.fan_ctrl_set_mode)
return -EINVAL;
 
err = kstrtoint(buf, 10, &value);
@@ -789,7 +789,7 @@ static umode_t hwmon_attributes_visible(struct kobject 
*kobj,
return 0;
 
/* Skip vddc attribute if get_current_vddc is not implemented */
-   if(attr == &sensor_dev_attr_in0_input.dev_attr.attr &&
+   if (attr == &sensor_dev_attr_in0_input.dev_attr.attr &&
!rdev->asic->dpm.get_current_vddc)
return 0;
 
-- 
2.17.1

[PATCH] drm/radeon/kms: Clean up errors in smu7.h

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/smu7.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/smu7.h b/drivers/gpu/drm/radeon/smu7.h
index 75a380a15292..985d720dbc0d 100644
--- a/drivers/gpu/drm/radeon/smu7.h
+++ b/drivers/gpu/drm/radeon/smu7.h
@@ -82,8 +82,7 @@
 #define SCRATCH_B_CURR_SAMU_INDEX_MASK  (0x7<

[PATCH] drm/radeon/kms: Clean up errors in smu7_fusion.h

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line
ERROR: space prohibited before open square bracket '['

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/smu7_fusion.h | 42 +++-
 1 file changed, 16 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/smu7_fusion.h 
b/drivers/gpu/drm/radeon/smu7_fusion.h
index 78ada9ffd508..e130f52fe8d6 100644
--- a/drivers/gpu/drm/radeon/smu7_fusion.h
+++ b/drivers/gpu/drm/radeon/smu7_fusion.h
@@ -36,8 +36,7 @@
 #define SMU7_NUM_NON_TES 2
 
 // All 'soft registers' should be uint32_t.
-struct SMU7_SoftRegisters
-{
+struct SMU7_SoftRegisters {
 uint32_tRefClockFrequency;
 uint32_tPmTimerP;
 uint32_tFeatureEnables;
@@ -80,8 +79,7 @@ struct SMU7_SoftRegisters
 
 typedef struct SMU7_SoftRegisters SMU7_SoftRegisters;
 
-struct SMU7_Fusion_GraphicsLevel
-{
+struct SMU7_Fusion_GraphicsLevel {
 uint32_tMinVddNb;
 
 uint32_tSclkFrequency;
@@ -111,8 +109,7 @@ struct SMU7_Fusion_GraphicsLevel
 
 typedef struct SMU7_Fusion_GraphicsLevel SMU7_Fusion_GraphicsLevel;
 
-struct SMU7_Fusion_GIOLevel
-{
+struct SMU7_Fusion_GIOLevel {
 uint8_t EnabledForActivity;
 uint8_t LclkDid;
 uint8_t Vid;
@@ -137,8 +134,7 @@ struct SMU7_Fusion_GIOLevel
 typedef struct SMU7_Fusion_GIOLevel SMU7_Fusion_GIOLevel;
 
 // UVD VCLK/DCLK state (level) definition.
-struct SMU7_Fusion_UvdLevel
-{
+struct SMU7_Fusion_UvdLevel {
 uint32_t VclkFrequency;
 uint32_t DclkFrequency;
 uint16_t MinVddNb;
@@ -155,8 +151,7 @@ struct SMU7_Fusion_UvdLevel
 typedef struct SMU7_Fusion_UvdLevel SMU7_Fusion_UvdLevel;
 
 // Clocks for other external blocks (VCE, ACP, SAMU).
-struct SMU7_Fusion_ExtClkLevel
-{
+struct SMU7_Fusion_ExtClkLevel {
 uint32_t Frequency;
 uint16_t MinVoltage;
 uint8_t  Divider;
@@ -166,8 +161,7 @@ struct SMU7_Fusion_ExtClkLevel
 };
 typedef struct SMU7_Fusion_ExtClkLevel SMU7_Fusion_ExtClkLevel;
 
-struct SMU7_Fusion_ACPILevel
-{
+struct SMU7_Fusion_ACPILevel {
 uint32_tFlags;
 uint32_tMinVddNb;
 uint32_tSclkFrequency;
@@ -181,8 +175,7 @@ struct SMU7_Fusion_ACPILevel
 
 typedef struct SMU7_Fusion_ACPILevel SMU7_Fusion_ACPILevel;
 
-struct SMU7_Fusion_NbDpm
-{
+struct SMU7_Fusion_NbDpm {
 uint8_t DpmXNbPsHi;
 uint8_t DpmXNbPsLo;
 uint8_t Dpm0PgNbPsHi;
@@ -197,8 +190,7 @@ struct SMU7_Fusion_NbDpm
 
 typedef struct SMU7_Fusion_NbDpm SMU7_Fusion_NbDpm;
 
-struct SMU7_Fusion_StateInfo
-{
+struct SMU7_Fusion_StateInfo {
 uint32_t SclkFrequency;
 uint32_t LclkFrequency;
 uint32_t VclkFrequency;
@@ -214,8 +206,7 @@ struct SMU7_Fusion_StateInfo
 
 typedef struct SMU7_Fusion_StateInfo SMU7_Fusion_StateInfo;
 
-struct SMU7_Fusion_DpmTable
-{
+struct SMU7_Fusion_DpmTable {
 uint32_tSystemFlags;
 
 SMU7_PIDController  GraphicsPIDController;
@@ -230,12 +221,12 @@ struct SMU7_Fusion_DpmTable
 uint8_tSamuLevelCount;
 uint16_t   FpsHighT;
 
-SMU7_Fusion_GraphicsLevel GraphicsLevel   
[SMU__NUM_SCLK_DPM_STATE];
+SMU7_Fusion_GraphicsLevel GraphicsLevel[SMU__NUM_SCLK_DPM_STATE];
 SMU7_Fusion_ACPILevel ACPILevel;
-SMU7_Fusion_UvdLevel  UvdLevel
[SMU7_MAX_LEVELS_UVD];
-SMU7_Fusion_ExtClkLevel   VceLevel
[SMU7_MAX_LEVELS_VCE];
-SMU7_Fusion_ExtClkLevel   AcpLevel
[SMU7_MAX_LEVELS_ACP];
-SMU7_Fusion_ExtClkLevel   SamuLevel   
[SMU7_MAX_LEVELS_SAMU];
+SMU7_Fusion_UvdLevel  UvdLevel[SMU7_MAX_LEVELS_UVD];
+SMU7_Fusion_ExtClkLevel   VceLevel[SMU7_MAX_LEVELS_VCE];
+SMU7_Fusion_ExtClkLevel   AcpLevel[SMU7_MAX_LEVELS_ACP];
+SMU7_Fusion_ExtClkLevel   SamuLevel[SMU7_MAX_LEVELS_SAMU];
 
 uint8_t   UvdBootLevel;
 uint8_t   VceBootLevel;
@@ -266,10 +257,9 @@ struct SMU7_Fusion_DpmTable
 
 };
 
-struct SMU7_Fusion_GIODpmTable
-{
+struct SMU7_Fusion_GIODpmTable {
 
-SMU7_Fusion_GIOLevel  GIOLevel
[SMU7_MAX_LEVELS_GIO];
+SMU7_Fusion_GIOLevel  GIOLevel[SMU7_MAX_LEVELS_GIO];
 
 SMU7_PIDControllerGioPIDController;
 
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in r600_dpm.c

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: that open brace { should be on the previous line

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/r600_dpm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_dpm.c 
b/drivers/gpu/drm/radeon/r600_dpm.c
index 9d2bcb9551e6..64980a61d38a 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -28,8 +28,7 @@
 #include "r600_dpm.h"
 #include "atom.h"
 
-const u32 r600_utc[R600_PM_NUMBER_OF_TC] =
-{
+const u32 r600_utc[R600_PM_NUMBER_OF_TC] = {
R600_UTC_DFLT_00,
R600_UTC_DFLT_01,
R600_UTC_DFLT_02,
@@ -47,8 +46,7 @@ const u32 r600_utc[R600_PM_NUMBER_OF_TC] =
R600_UTC_DFLT_14,
 };
 
-const u32 r600_dtc[R600_PM_NUMBER_OF_TC] =
-{
+const u32 r600_dtc[R600_PM_NUMBER_OF_TC] = {
R600_DTC_DFLT_00,
R600_DTC_DFLT_01,
R600_DTC_DFLT_02,
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in rv515.c

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: that open brace { should be on the previous line

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/rv515.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
index 76260fdfbaa7..79709d26d983 100644
--- a/drivers/gpu/drm/radeon/rv515.c
+++ b/drivers/gpu/drm/radeon/rv515.c
@@ -42,8 +42,7 @@
 static void rv515_gpu_init(struct radeon_device *rdev);
 int rv515_mc_wait_for_idle(struct radeon_device *rdev);
 
-static const u32 crtc_offsets[2] =
-{
+static const u32 crtc_offsets[2] = {
0,
AVIVO_D2CRTC_H_TOTAL - AVIVO_D1CRTC_H_TOTAL
 };
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in radeon_mode.h

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following struct go on the same line

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/radeon_mode.h | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 59c4db13d90a..546381a5c918 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -603,8 +603,7 @@ struct atom_memory_info {
 
 #define MAX_AC_TIMING_ENTRIES 16
 
-struct atom_memory_clock_range_table
-{
+struct atom_memory_clock_range_table {
u8 num_entries;
u8 rsv[3];
u32 mclk[MAX_AC_TIMING_ENTRIES];
@@ -632,14 +631,12 @@ struct atom_mc_reg_table {
 
 #define MAX_VOLTAGE_ENTRIES 32
 
-struct atom_voltage_table_entry
-{
+struct atom_voltage_table_entry {
u16 value;
u32 smio_low;
 };
 
-struct atom_voltage_table
-{
+struct atom_voltage_table {
u32 count;
u32 mask_low;
u32 phase_delay;
-- 
2.17.1

[PATCH] drm/radeon: Clean up errors in evergreen_reg.h

[GuoHua Chen]

Fix the following errors reported by checkpatch:

ERROR: space prohibited before that close parenthesis ')'
ERROR: need consistent spacing around '<<' (ctx:WxV)
ERROR: need consistent spacing around '-' (ctx:WxV)

Signed-off-by: GuoHua Chen 
---
 drivers/gpu/drm/radeon/evergreen_reg.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h 
b/drivers/gpu/drm/radeon/evergreen_reg.h
index b436badf9efa..3ff9fda54aa3 100644
--- a/drivers/gpu/drm/radeon/evergreen_reg.h
+++ b/drivers/gpu/drm/radeon/evergreen_reg.h
@@ -265,8 +265,8 @@
 
 
 #define NI_DIG_BE_CNTL0x7140
-#   define NI_DIG_BE_CNTL_FE_SOURCE_SELECT(x) (((x) >> 8 ) & 0x3F)
-#   define NI_DIG_FE_CNTL_MODE(x) (((x) >> 16) & 0x7 )
+#   define NI_DIG_BE_CNTL_FE_SOURCE_SELECT(x) (((x) >> 8) & 0x3F)
+#   define NI_DIG_FE_CNTL_MODE(x) (((x) >> 16) & 0x7)
 
 #define NI_DIG_BE_EN_CNTL  0x7144
 #   define NI_DIG_BE_EN_CNTL_ENABLE   (1 << 0)
@@ -284,7 +284,7 @@
 
 #define EVERGREEN_DP_VID_STREAM_CNTL0x730C
 #   define EVERGREEN_DP_VID_STREAM_CNTL_ENABLE (1 << 0)
-#   define EVERGREEN_DP_VID_STREAM_STATUS  (1 <<16)
+#   define EVERGREEN_DP_VID_STREAM_STATUS  (1 << 16)
 #define EVERGREEN_DP_STEER_FIFO 0x7310
 #   define EVERGREEN_DP_STEER_FIFO_RESET   (1 << 0)
 #define EVERGREEN_DP_SEC_CNTL   0x7280
@@ -302,8 +302,8 @@
 #   define EVERGREEN_DP_SEC_SS_EN   (1 << 28)
 
 /*DCIO_UNIPHY block*/
-#define NI_DCIO_UNIPHY0_UNIPHY_TX_CONTROL1(0x6600  -0x6600)
-#define NI_DCIO_UNIPHY1_UNIPHY_TX_CONTROL1(0x6640  -0x6600)
+#define NI_DCIO_UNIPHY0_UNIPHY_TX_CONTROL1(0x6600 - 0x6600)
+#define NI_DCIO_UNIPHY1_UNIPHY_TX_CONTROL1(0x6640 - 0x6600)
 #define NI_DCIO_UNIPHY2_UNIPHY_TX_CONTROL1(0x6680 - 0x6600)
 #define NI_DCIO_UNIPHY3_UNIPHY_TX_CONTROL1(0x66C0 - 0x6600)
 #define NI_DCIO_UNIPHY4_UNIPHY_TX_CONTROL1(0x6700 - 0x6600)
-- 
2.17.1