Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: [SNIP] While we can't control user application accesses to the mapped buffers explicitly and hence we use page fault rerouting I am thinking that in this case we may be able to sprinkle drm_dev_enter/exit in any such sensitive place were we might CPU access a DMA buffer from the kernel ? Yes, I fear we are going to need that. Things like CPU page table updates, ring buffer accesses and FW memcpy ? Is there other places ? Puh, good question. I have no idea. Another point is that at this point the driver shouldn't access any such buffers as we are at the process finishing the device. AFAIK there is no page fault mechanism for kernel mappings so I don't think there is anything else to do ? Well there is a page fault handler for kernel mappings, but that one just prints the stack trace into the system log and calls BUG(); :) Long story short we need to avoid any access to released pages after unplug. No matter if it's from the kernel or userspace. I was just about to start guarding with drm_dev_enter/exit CPU accesses from kernel to GTT ot VRAM buffers but then i looked more in the code and seems like ttm_tt_unpopulate just deletes DMA mappings (for the sake of device to main memory access). Kernel page table is not touched until last bo refcount is dropped and the bo is released (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This is both for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped by ioremap. So as i see it, nothing will bad will happen after we unpopulate a BO while we still try to use a kernel mapping for it, system memory pages backing GTT BOs are still mapped and not freed and for VRAM BOs same is for the IO physical ranges mapped into the kernel page table since iounmap wasn't called yet. The problem is the system pages would be freed and if we kernel driver still happily write to them we are pretty much busted because we write to freed up memory. Christian. I loaded the driver with vm_update_mode=3 meaning all VM updates done using CPU and hasn't seen any OOPs after removing the device. I guess i can test it more by allocating GTT and VRAM BOs and trying to read/write to them after device is removed. Andrey Regards, Christian. Andrey ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Alex,
We have ignored the amd-20.xx branches:
https://github.com/intel/lkp-tests/commit/acb8d1f213ec6841900e0d7e9737f8ea0960e4d3
Best Regards,
Rong Chen
On 12/15/20 10:24 PM, Deucher, Alexander wrote:
[AMD Public Use]
The test robot should probably not be testing the amd-20.xx branches
in the first place. They are just mirrors of our packaged drivers so
they contain a bunch of stuff that will never go upstream like kernel
compatibility layers and dkms support.
Alex
*From:* Qinglang Miao
*Sent:* Tuesday, December 15, 2020 3:21 AM
*To:* kernel test robot ; Deucher, Alexander
*Cc:* kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ;
Xiong, Yang (Felix)
*Subject:* Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39:
sparse: sparse: incorrect type in argument 1 (different base types)
Hi Alex,
I think it's not a valid report from kernel test robot, for __le16 ought
to be the right type for cpu_to_le16. The sparse warnings seems not
right so I did't try effort to reproduce it.
otherwise, when I take a carful look at this patch, an unconditional
braces exists and I'm not sure about its benefit.
if (bp_params->flags.INTERLACE) {
params.susModeMiscInfo.usAccess =
cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
ATOM_INTERLACE);
{
le16_add_cpu(¶ms.usV_SyncOffset, 1);
}
}
patch link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2F&data=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010744629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1TmtjBXJLf60sxq%2BH%2BVmMhnRV%2FuyIKQD2BYDVWMxmUA%3D&reserved=0
How do you think?
在 2020/12/15 14:44, kernel test robot 写道:
> tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427]
drm/amd/display: convert to use le16_add_cpu()
> config: arc-randconfig-s031-20201214 (attached as .config)
> compiler: arc-elf-gcc (GCC) 9.3.0
> reproduce:
> wget
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010754583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DCHDVGjiXhPDoCTofTf0pxHspdydDs1JXneGoSGPgFQ%3D&reserved=0
-O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.3-184-g1b896707-dirty
> git remote add radeon-alex
git://people.freedesktop.org/~agd5f/linux.git
> git fetch --no-tags radeon-alex amd-20.45
> git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> "sparse warnings: (new ones prefixed by >>)"
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: sparse: incorrect type in assignment (different base types)
@@ expected unsigned int [addressable] [assigned] [usertype]
ulSymClock @@ got restricted __le16 [usertype] @@
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: expected unsigned int [addressable] [assigned] [usertype]
ulSymClock
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: got restricted __le16 [usertype]
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: sparse: incorrect type in assignment (different base types)
@@ expected unsigned short [addressable] [assigned] [usertype]
usRefDiv @@ got restricted __le16 [usertype] @@
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: expected unsigned short [addressable] [assigned]
[usertype] usRefDiv
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: got restricted __le16 [usertype]
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
sparse: sparse: incorrect type in assignment (different base types)
@@ expected unsigned short [addressable] [assigned] [usertype]
usFbDiv @@ got restricted __le16 [usertype] @@
>
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
sparse: expected unsigned shor
[PATCH drm/hisilicon 0/2] Add the new api to enable msi
patch #1 add the new api to enable pci mis. patch #2 is hibmc driver uses the newly added api to enable msi. Tian Tao (2): drm/irq: Add the new api to enable pci msi drm/hisilicon: Use the new api devm_drm_msi_install drivers/gpu/drm/drm_irq.c | 33 + drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +-- include/drm/drm_irq.h | 1 + 3 files changed, 35 insertions(+), 2 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with the crypto tree
On Tue, Dec 15, 2020 at 10:58:52AM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 14, 2020 at 2:44 PM Stephen Rothwell
> wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > MAINTAINERS
> >
> > between commit:
> >
> > 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
> >
> > from the crypto tree and commit:
> >
> > ed794057b052 ("drm/kmb: Build files for KeemBay Display driver")
> >
> > from the drm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc MAINTAINERS
> > index 3b358262de8f,eb18459c1d16..
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
>
> > @@@ -8985,16 -8962,13 +8993,23 @@@ M: Deepak Saxena > S:Maintained
> > F:drivers/char/hw_random/ixp4xx-rng.c
> >
> > + INTEL KEEMBAY DRM DRIVER
>
> Is it KEEMBAY?
>
> > + M:Anitha Chrisanthus
> > + M:Edmund Dea
> > + S:Maintained
> > + F:Documentation/devicetree/bindings/display/intel,kmb_display.yaml
>
> I was just going to comment about "intel,kmb_*" vs. "intel,keembay-*", until
> I noticed intel,kmb_display.yaml does not exist, but is called
> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> in next-20201214.
>
> > + F:drivers/gpu/drm/kmb/
> > +
> > +INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
>
> or KEEM BAY?
>
> Or Keem Bay? Keembay? KeemBay?
It should be Keem Bay. I googled sandybridge, ivybridge, baytrail,
cherrytrail, medfield and merrifiled and for the *bridge and *trail products
the words are split up and capitalized. For the *fields they are one-word.
We'll update the KEEMBAY,KeemBay, KEEM BAY instances to Keem Bay to mimic SDB,
IVB, BYT and CHT since those are the majority. I'm not sure I'm going to rename
the file names however but, within the files wherever we talk about Keem Bay we
will use "Keem Bay" consistently.
Sorry for the variances,
--mark
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 5/9] drm/vc4: hdmi: Create a custom connector state
Hi Dave, On Tue, Dec 15, 2020 at 04:25:46PM +, Dave Stevenson wrote: > Hi Maxime > > On Tue, 15 Dec 2020 at 15:42, Maxime Ripard wrote: > > > > When run with a higher bpc than 8, the clock of the HDMI controller needs > > to be adjusted. Let's create a connector state that will be used at > > atomic_check and atomic_enable to compute and store the clock rate > > associated to the state. > > > > Acked-by: Thomas Zimmermann > > Signed-off-by: Maxime Ripard > > I'm happy again > Reviewed-by: Dave Stevenson Thanks! Does that apply to patch 9 as well? Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Alex,
I think it's not a valid report from kernel test robot, for __le16 ought
to be the right type for cpu_to_le16. The sparse warnings seems not
right so I did't try effort to reproduce it.
otherwise, when I take a carful look at this patch, an unconditional
braces exists and I'm not sure about its benefit.
if (bp_params->flags.INTERLACE) {
params.susModeMiscInfo.usAccess =
cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
ATOM_INTERLACE);
{
le16_add_cpu(¶ms.usV_SyncOffset, 1);
}
}
patch link:
https://lore.kernel.org/lkml/cadnq5_punha1vhhj7vtehg6o2z_z1ws325y_r9xo+gsv_jc...@mail.gmail.com/
How do you think?
在 2020/12/15 14:44, kernel test robot 写道:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: a3950d94b046fb206e58fd3ec717f071c0203ba3
commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427] drm/amd/display:
convert to use le16_add_cpu()
config: arc-randconfig-s031-20201214 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
git remote add radeon-alex
git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-20.45
git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned int [addressable] [assigned] [usertype] ulSymClock @@ got
restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: expected unsigned int [addressable] [assigned] [usertype] ulSymClock
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
sparse: got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned short [addressable] [assigned] [usertype] usRefDiv @@ got
restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: expected unsigned short [addressable] [assigned] [usertype] usRefDiv
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
sparse: got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned short [addressable] [assigned] [usertype] usFbDiv @@ got
restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
sparse: expected unsigned short [addressable] [assigned] [usertype] usFbDiv
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
sparse: got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:966:44:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned short [addressable] [assigned] [usertype] usPixelClock @@
got restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:966:44:
sparse: expected unsigned short [addressable] [assigned] [usertype]
usPixelClock
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:966:44:
sparse: got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1029:40:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned short [addressable] [assigned] [usertype] usFbDiv @@ got
restricted __le16 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1029:40:
sparse: expected unsigned short [addressable] [assigned] [usertype] usFbDiv
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1029:40:
sparse: got restricted __le16 [usertype]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1031:47:
sparse: sparse: incorrect type in assignment (different base types) @@
expected unsigned int [addressable] [assigned] [usertype] ulFbDivDecFrac @@
got restricted __le32 [usertype] @@
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1031:47:
sparse: expected unsigned int [addressable] [assigned] [usertype]
ulFbDivDecFrac
driver
[PATCH v7 6/9] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index d22a0dbd0ce2..a6422d7af019 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -198,6 +198,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -618,9 +619,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -632,7 +653,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -804,6 +825,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -834,6 +856,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Fix rmmod hibmc_drm failed
在 2020/12/15 20:01, Daniel Vetter 写道:
On Tue, Dec 15, 2020 at 12:59:53PM +0100, Daniel Vetter wrote:
On Tue, Dec 15, 2020 at 11:01:39AM +0800, Tian Tao wrote:
drm_irq_uninstall should be called before pci_disable_msi, if use
devm_drm_irq_install to register the interrupt, the system will
call pci_disable_msi first and then call drm_irq_uninstall, which
will result in the following callstack.
kernel BUG at drivers/pci/msi.c:376!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 93 PID: 173814 Comm: rmmod Tainted:
pstate: a049 (NzCv daif +PAN -UAO -TCO BTYPE=--)
pc : free_msi_irqs+0x17c/0x1a0
lr : free_msi_irqs+0x16c/0x1a0
sp : 2028157f7bd0
x29: 2028157f7bd0 x28: 202849edab00
x27: x26:
x25: x24:
x23: 0020851da000 x22: 0020851da2d8
x21: 0020cc829000 x20:
x19: 0020d6714800 x18: 0010
x17: x16:
x15: x14: 2028957f77df
x13: 2028157f77ed x12:
x11: 0040 x10: 800011b2f8e0
x9 : 800011b2f8d8 x8 : 2020203fc458
x7 : x6 :
x5 : 2020203fc430 x4 : 2020203fc4a0
x3 : x2 :
x1 : 02c9 x0 : 0020d6719500
Call trace:
free_msi_irqs+0x17c/0x1a0
pci_disable_msi+0xe4/0x118
hibmc_unload+0x44/0x80 [hibmc_drm]
hibmc_pci_remove+0x2c/0x38 [hibmc_drm]
pci_device_remove+0x48/0x108
device_release_driver_internal+0x118/0x1f0
driver_detach+0x6c/0xe0
bus_remove_driver+0x74/0x100
driver_unregister+0x34/0x60
pci_unregister_driver+0x24/0xd8
hibmc_pci_driver_exit+0x14/0xe768 [hibmc_drm]
__arm64_sys_delete_module+0x1fc/0x2d0
el0_svc_common.constprop.3+0xa8/0x188
do_el0_svc+0x80/0xa0
el0_sync_handler+0x8c/0xb0
el0_sync+0x15c/0x180
Code: f940b400 b400 a903e7b8 f90013b5 (d421)
---[ end trace 310d94ee8abef44f ]---
Kernel panic - not syncing: Oops - BUG: Fatal exception
You should mention here which patch you're reverting. With that:
Acked-by: Daniel Vetter
Since the proper fix will probably take a while longer. Also why was this
not noticed when merging the original patch? hisilicon is the only user of
devm_drm_irq_install we have in-tree right now.
I also just noticed that you didn't add devm_drm_irq_install to the list
of functions in Documentation/driver-api/driver-model/devres.rst. Can you
please submit a patch to fix this?
sure
Thanks, Daniel
-Daniel
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index e3ab765b..02f3bd1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,6 +251,10 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
+
+ if (dev->irq_enabled)
+ drm_irq_uninstall(dev);
+
pci_disable_msi(dev->pdev);
return 0;
@@ -286,7 +290,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = devm_drm_irq_install(dev, dev->pdev->irq);
+ ret = drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
--
2.7.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi: Use PTR_ERR_OR_ZERO() to simplify code
Hi, On Tue, Dec 15, 2020 at 10:16:11AM +0800, Tian Tao wrote: > Fixes coccicheck warning: > drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:281:1-3: WARNING: PTR_ERR_OR_ZERO > can be used > > Signed-off-by: Tian Tao That script shouldn't be there anymore, see: https://lore.kernel.org/cocci/alpine.DEB.2.21.2001071106420.3004@hadrien/#t Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: suspicious RCU usage in modeset_lock
Hello,
syzbot found the following issue on:
HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130558c550
kernel config: https://syzkaller.appspot.com/x/.config?x=ee8a1012a5314210
dashboard link: https://syzkaller.appspot.com/bug?extid=972b924c988834e868b2
compiler: gcc (GCC) 10.1.0-syz 20200507
userspace arch: i386
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+972b924c988834e86...@syzkaller.appspotmail.com
=
WARNING: suspicious RCU usage
5.10.0-rc7-syzkaller #0 Not tainted
-
kernel/sched/core.c:7270 Illegal context switch in RCU-sched read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
7 locks held by syz-executor.1/9232:
#0: 8b328c60 (console_lock){+.+.}-{0:0}, at: do_fb_ioctl+0x2e4/0x690
drivers/video/fbdev/core/fbmem.c:1106
#1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: lock_fb_info
include/linux/fb.h:636 [inline]
#1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: do_fb_ioctl+0x2ee/0x690
drivers/video/fbdev/core/fbmem.c:1107
#2: 888041adca78 (&helper->lock){+.+.}-{3:3}, at:
drm_fb_helper_pan_display+0xce/0x970 drivers/gpu/drm/drm_fb_helper.c:1448
#3: 8880159f01b8 (&dev->master_mutex){+.+.}-{3:3}, at:
drm_master_internal_acquire+0x1d/0x70 drivers/gpu/drm/drm_auth.c:407
#4: 888041adc898 (&client->modeset_mutex){+.+.}-{3:3}, at:
drm_client_modeset_commit_locked+0x44/0x580
drivers/gpu/drm/drm_client_modeset.c:1143
#5: c90001c07730 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_client_modeset_commit_atomic+0xb7/0x7c0
drivers/gpu/drm/drm_client_modeset.c:981
#6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_lock_slow
include/linux/ww_mutex.h:287 [inline]
#6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
modeset_lock+0x31c/0x650 drivers/gpu/drm/drm_modeset_lock.c:260
stack backtrace:
CPU: 1 PID: 9232 Comm: syz-executor.1 Not tainted 5.10.0-rc7-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:118
___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
__mutex_lock_common kernel/locking/mutex.c:935 [inline]
__ww_mutex_lock.constprop.0+0xa9/0x2cc0 kernel/locking/mutex.c:
ww_mutex_lock+0x3d/0x170 kernel/locking/mutex.c:1190
modeset_lock+0x392/0x650 drivers/gpu/drm/drm_modeset_lock.c:263
drm_modeset_lock drivers/gpu/drm/drm_modeset_lock.c:342 [inline]
drm_modeset_lock+0x50/0x90 drivers/gpu/drm/drm_modeset_lock.c:338
drm_atomic_get_plane_state+0x19d/0x510 drivers/gpu/drm/drm_atomic.c:481
drm_client_modeset_commit_atomic+0x225/0x7c0
drivers/gpu/drm/drm_client_modeset.c:994
drm_client_modeset_commit_locked+0x145/0x580
drivers/gpu/drm/drm_client_modeset.c:1145
pan_display_atomic drivers/gpu/drm/drm_fb_helper.c:1395 [inline]
drm_fb_helper_pan_display+0x28b/0x970 drivers/gpu/drm/drm_fb_helper.c:1455
fb_pan_display+0x2f7/0x6c0 drivers/video/fbdev/core/fbmem.c:925
fb_set_var+0x57f/0xda0 drivers/video/fbdev/core/fbmem.c:1043
do_fb_ioctl+0x2f9/0x690 drivers/video/fbdev/core/fbmem.c:1108
fb_compat_ioctl+0x17c/0xaf0 drivers/video/fbdev/core/fbmem.c:1315
__do_compat_sys_ioctl+0x1d3/0x230 fs/ioctl.c:842
do_syscall_32_irqs_on arch/x86/entry/common.c:78 [inline]
__do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:137
do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:160
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7fd8549
Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08
03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90
eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:f55d20bc EFLAGS: 0296 ORIG_RAX: 0036
RAX: ffda RBX: 0003 RCX: 4601
RDX: 2240 RSI: RDI:
RBP: R08: R09:
R10: R11: R12:
R13: R14: R15:
detected fb_set_par error, error code: -16
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/9] drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
drivers/gpu/drm/vc4/vc4_drv.h | 9 -
drivers/gpu/drm/vc4/vc4_hvs.c | 18 ++
drivers/gpu/drm/vc4/vc4_txp.c | 10 +++---
4 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index ee4f657a5ce0..95b2dd9d7a38 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
*/
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
@@ -593,7 +591,7 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_connector_state *conn_state;
int ret, i;
- ret = vc4_hvs_atomic_check(crtc, crtc_state);
+ ret = vc4_hvs_atomic_check(crtc, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 6db4c944ecba..5a115bc62cc8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -913,11 +913,10 @@ void vc4_irq_reset(struct drm_device *dev);
extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
-int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
-void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
- struct drm_atomic_state *state);
+int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_atomic_state
*state);
void vc4_hvs_dump_state(struct drm_device *dev);
void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
void vc4_hvs_mask_underrun(struct drm_device *dev, int channel);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index cccd341e5d67..2b3a597fa65f 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -326,10 +326,10 @@ void vc4_hvs_stop_channel(struct drm_device *dev,
unsigned int chan)
SCALER_DISPSTATX_EMPTY);
}
-int vc4_hvs_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
+int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_atomic_state *state)
{
- struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
+ struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc_state);
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_plane *plane;
@@ -341,10 +341,10 @@ int vc4_hvs_atomic_check(struct drm_crtc *crtc,
/* The pixelvalve can only feed one encoder (and encoders are
* 1:1 with connectors.)
*/
- if (hweight32(state->connector_mask) > 1)
+ if (hweight32(crtc_state->connector_mask) > 1)
return -EINVAL;
- drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
+ drm_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state)
dlist_count += vc4_plane_dlist_size(plane_state);
dlist_count++; /* Account for SCALER_CTL0_END. */
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
}
void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
struct vc4_dev
[PATCH v7 2/9] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 95b2dd9d7a38..0fef45b93ba1 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 5a115bc62cc8..051ad4e31e52 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -441,12 +441,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9f8d74e32355..8ce5dd65f6e4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -360,7 +360,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *e
Re: [PATCH v7 2/5] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation
On Sat, Nov 21, 2020 at 11:49:59PM +, John Stultz wrote: > Since the heap-helpers logic ended up not being as generic as > hoped, move the heap-helpers dma_buf_ops implementations into > the cma_heap directly. > > This will allow us to remove the heap_helpers code in a following > patch. > mips:allmodconfig: drivers/dma-buf/heaps/cma_heap.c: In function 'cma_heap_do_vmap': drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of function 'vmap' Bisect log attached. Guenter --- # bad: [9317f948b0b188b8d2fded75957e6d42c460df1b] Add linux-next specific files for 20201215 # good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10 git bisect start 'HEAD' 'v5.10' # good: [8357e709304f1791b390c34f63cd00cb434a9ea9] Merge remote-tracking branch 'pm/linux-next' git bisect good 8357e709304f1791b390c34f63cd00cb434a9ea9 # bad: [e43c4376b37c58a05fe2f512aebfc7362306] Merge remote-tracking branch 'tomoyo/master' git bisect bad e43c4376b37c58a05fe2f512aebfc7362306 # good: [6f2d5cf9756dab190e79edd4ec098c81dca6743c] net: stmmac: simplify the return dwmac5_rxp_disable() git bisect good 6f2d5cf9756dab190e79edd4ec098c81dca6743c # bad: [fef5fe5f601c5826083b81837800b8b99570bfb0] Merge remote-tracking branch 'drm-misc/for-linux-next' git bisect bad fef5fe5f601c5826083b81837800b8b99570bfb0 # good: [5bb0c4b5eb61d939fed0b27d11fb91fb85769c9a] ice, xsk: Move Rx allocation out of while-loop git bisect good 5bb0c4b5eb61d939fed0b27d11fb91fb85769c9a # good: [b54139eb968d982bfd5f451a8d143f3f6cdd82cf] Merge remote-tracking branch 'mtd/mtd/next' git bisect good b54139eb968d982bfd5f451a8d143f3f6cdd82cf # good: [f42a3d780d2ff7a122b089460f4bfbe402b4e27e] Merge remote-tracking branch 'amdgpu/drm-next' git bisect good f42a3d780d2ff7a122b089460f4bfbe402b4e27e # good: [3a9ec563a4ff770ae647f6ee539810f1866866c9] drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout git bisect good 3a9ec563a4ff770ae647f6ee539810f1866866c9 # bad: [2c3a1e49696fd05b52ec5eeb7c006ac32724c915] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang git bisect bad 2c3a1e49696fd05b52ec5eeb7c006ac32724c915 # good: [2ac5ef3b23629e974948c48f4141bacb5abb] drm: document drm_mode_get_connector git bisect good 2ac5ef3b23629e974948c48f4141bacb5abb # good: [2b6cb81b95d1e8abfb6d32cf194a5bd2992c315c] drm/meson: dw-hdmi: Enable the iahb clock early enough git bisect good 2b6cb81b95d1e8abfb6d32cf194a5bd2992c315c # bad: [4c68e499bb9d6d9ec3e18fcb2f68641abb22464a] dma-buf: heaps: Skip sync if not mapped git bisect bad 4c68e499bb9d6d9ec3e18fcb2f68641abb22464a # bad: [a5d2d29e24be8967ef78a1b1fb2292413e3b3df9] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation git bisect bad a5d2d29e24be8967ef78a1b1fb2292413e3b3df9 # good: [3812957587923ca325308ed9c4a5be5ca935e903] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists git bisect good 3812957587923ca325308ed9c4a5be5ca935e903 # first bad commit: [a5d2d29e24be8967ef78a1b1fb2292413e3b3df9] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/9] drm/vc4: hdmi: Support the 10/12 bit output
Hi, Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI controller. Let me know what you think, Maxime Changes from v6: - Addressed the issues pointed out by Dave - Rebased on current drm-misc-next Changes from v5: - Fixed the connector->state access in the connector state reset - Added the tags from Thomas and Dave Changes from v4: - Added the tags from Thomas - Fixed an issue with the clock doubling - Changed a comment to match the code being introduced Changes from v3: - Don't dereference the connector->state pointer if kzalloc failed Changes from v2: - Rebased on current drm-misc-next - Fixed a bug that was dropping the refresh rate when the bpc count was increased Changes from v1: - Added the coccinelle script to the first patch - Fixed the pixel_rate ramp up Maxime Ripard (9): drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Use the connector state pixel rate for the PHY drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/vc4/vc4_crtc.c | 24 ++--- drivers/gpu/drm/vc4/vc4_drv.h | 19 ++-- drivers/gpu/drm/vc4/vc4_hdmi.c | 155 +--- drivers/gpu/drm/vc4/vc4_hdmi.h | 23 +++-- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 ++ drivers/gpu/drm/vc4/vc4_hvs.c | 18 ++-- drivers/gpu/drm/vc4/vc4_txp.c | 10 +- 8 files changed, 208 insertions(+), 58 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/9] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 11 +--
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a6422d7af019..dbe516d89726 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -721,7 +721,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi->variant->reset(vc4_hdmi);
if (vc4_hdmi->variant->phy_init)
- vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
+ vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
HDMI_READ(HDMI_SCHEDULER_CONTROL) |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index bca6943de884..60c53d7c9bad 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_hdmi_encoder, base.base);
}
-struct drm_display_mode;
-
struct vc4_hdmi;
struct vc4_hdmi_register;
+struct vc4_hdmi_connector_state;
enum vc4_hdmi_phy_channel {
PHY_LANE_0 = 0,
@@ -80,9 +79,9 @@ struct vc4_hdmi_variant {
void (*set_timings)(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
- /* Callback to initialize the PHY according to the mode */
+ /* Callback to initialize the PHY according to the connector state */
void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-struct drm_display_mode *mode);
+struct vc4_hdmi_connector_state *vc4_conn_state);
/* Callback to disable the PHY */
void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
drm_connector_state *conn_state)
}
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 057796b54c51..36535480f8e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -127,7 +127,8 @@
#define OSCILLATOR_FREQUENCY 5400
-void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
/* PHY should be in reset, like
* vc4_hdmi_encoder_disable() does.
@@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
}
-void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
const struct phy_lane_settings *chan0_settings, *chan1_settings,
*chan2_settings, *clock_settings;
const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
- unsigned long long pixel_freq = mode->clock * 1000;
+ unsigned long long pixel_freq = conn_state->pixel_rate;
unsigned long long vco_freq;
unsigned char word_sel;
u8 vco_sel, vco_div;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon 2/2] drm/hisilicon: Use the new api devm_drm_msi_install
Use devm_drm_msi_install to enable pci msi so that
pci_disable_msi is not called when hibmc is removed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7e91ef1..21f8225 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,7 +251,6 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
- pci_disable_msi(dev->pdev);
return 0;
}
@@ -282,7 +281,7 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
- ret = pci_enable_msi(dev->pdev);
+ ret = devm_drm_msi_install(dev);
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 07-12-20, 11:46, Viresh Kumar wrote:
> On 19-11-20, 11:35, Viresh Kumar wrote:
> > On 18-11-20, 08:53, Rob Clark wrote:
> > > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > > wrote:
> > > >
> > > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > > With that on top of the previous patch,
> > > >
> > > > Don't you still have this ? Which fixed the lockdep in the remove path.
> > > >
> > > > https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
> > > >
> > > > To make it clear you need these patches to fix the OPP stuff:
> > > >
> > > > //From 5.10-rc3 (the one from the above link).
> > > > commit e0df59de670b ("opp: Reduce the size of critical section in
> > > > _opp_table_kref_release()")
> >
> > This fixes debugfs stuff while the OPP table is removed.
> >
> > > > //Below two from linux-next
> > > > commit ef43f01ac069 ("opp: Always add entries in dev_list with
> > > > opp_table->lock held")
> > > > commit 27c09484dd3d ("opp: Allocate the OPP table outside of
> > > > opp_table_lock")
> >
> > This fixes debugfs stuff while the OPP table is added.
> >
> > > > This matches the diff I gave you earlier.
> > > >
> > >
> > > no, I did not have all three, only "opp: Allocate the OPP table
> > > outside of opp_table_lock" plus the fixup. But with all three:
> >
> > And looking at the lockdep you gave now, it looks like we have a
> > problem with OPP table's internal lock (opp_table->lock) as well apart
> > from the global opp_table_lock.
> >
> > I wish there was a way for me to reproduce the lockdep :(
> >
> > I know this is exhausting for both of us and I really want to be over
> > with it as soon as possible, this really should be the last patch
> > here, please try this along with other two. This fixes the debugfs
> > thing while the OPPs in the OPP table are removed (they are already
> > added without a lock around debugfs stuff).
> >
> > AFAIU, there is no further debugfs stuff that happens from within the
> > locks and so this really should be the last patch unless I missed
> > something.
>
> Rob, were you able to test this patch ?
FWIW, this patch and everything else I had is merged into Linus's
master. You can test 5.11-rc1 to see if you still see a lockdep or
not.
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 5/9] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 33 ++---
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 920895deb2e7..d22a0dbd0ce2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,10 +170,37 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *old_state =
+ conn_state_to_vc4_hdmi_conn_state(connector->state);
+ struct vc4_hdmi_connector_state *new_state =
+ kzalloc(sizeof(*new_state), GFP_KERNEL);
if (connector->state)
- drm_atomic_helper_connector_tv_reset(connector);
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(old_state);
+ __drm_atomic_helper_connector_reset(connector, &new_state->base);
+
+ if (!new_state)
+ return;
+
+ drm_atomic_helper_connector_tv_reset(connector);
+}
+
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
@@ -181,7 +208,7 @@ static const struct drm_connector_funcs
vc4_hdmi_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 8/9] drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index dbe516d89726..41897b8e9d51 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -82,6 +82,8 @@
#define CEC_CLOCK_FREQ 4
#define VC4_HSM_MID_CLOCK 149985000
+#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
+
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -1918,7 +1920,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI0,
.debugfs_name = "hdmi0_regs",
.card_name = "vc4-hdmi-0",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi0_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
.phy_lane_mapping = {
@@ -1944,7 +1946,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi1_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI1,
.debugfs_name = "hdmi1_regs",
.card_name = "vc4-hdmi-1",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi1_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi1_fields),
.phy_lane_mapping = {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] vc4: Convert to drm_atomic_helper_commit
On Fri, Dec 04, 2020 at 04:11:31PM +0100, Maxime Ripard wrote: > Hi, > > Here's a conversion of vc4 to remove the hand-rolled atomic_commit helper from > vc4 in favour of the generic one. > > This requires some rework of vc4, but also a new hook and some documentation > for corner-cases in the DRM core that have been reported and explained by > Daniel recently. > > Let me know what you think, > Maxime Applied, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon 1/2] drm/irq: Add the new api to enable pci msi
Add new api devm_drm_msi_install() to register interrupts,
no need to call pci_disable_msi() when the drm module is removed.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_irq.c | 33 +
include/drm/drm_irq.h | 1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 803af4b..da58b2c 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -246,6 +246,39 @@ int devm_drm_irq_install(struct drm_device *dev, int irq)
}
EXPORT_SYMBOL(devm_drm_irq_install);
+static void devm_drm_msi_uninstall(void *data)
+{
+ struct drm_device *dev = (struct drm_device *)data;
+
+ pci_disable_msi(dev->pdev);
+}
+
+/**
+ * devm_drm_msi_install - install IRQ handler
+ * @dev: DRM device
+ *
+ * devm_drm_msi_install is a help function of pci_enable_msi.
+ *
+ * if the driver uses devm_drm_msi_install, there is no need
+ * to call pci_disable_msi when the drm module get unloaded,
+ * as this will done automagically.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int devm_drm_msi_install(struct drm_device *dev)
+{
+ int ret;
+
+ ret = pci_enable_msi(dev->pdev);
+ if (ret)
+ return ret;
+
+ return devm_add_action_or_reset(dev->dev,
+ devm_drm_msi_uninstall, dev);
+}
+EXPORT_SYMBOL(devm_drm_msi_install);
+
#if IS_ENABLED(CONFIG_DRM_LEGACY)
int drm_legacy_irq_control(struct drm_device *dev, void *data,
struct drm_file *file_priv)
diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
index 631b22f..c8dff45 100644
--- a/include/drm/drm_irq.h
+++ b/include/drm/drm_irq.h
@@ -29,4 +29,5 @@ struct drm_device;
int drm_irq_install(struct drm_device *dev, int irq);
int drm_irq_uninstall(struct drm_device *dev);
int devm_drm_irq_install(struct drm_device *dev, int irq);
+int devm_drm_msi_install(struct drm_device *dev);
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/9] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Suggested-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 3dac839b0fa5..920895deb2e7 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- drm_atomic_helper_connector_tv_reset(connector);
+
+ if (connector->state)
+ drm_atomic_helper_connector_tv_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: vc4: Remove unnecessary drm_plane_cleanup() wrapper
On Tue, Dec 15, 2020 at 09:37:54PM +0200, Laurent Pinchart wrote: > Use the drm_plane_cleanup() function directly as the drm_plane_funcs > .destroy() handler without creating an unnecessary wrapper around it. > > Signed-off-by: Laurent Pinchart Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/9] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
Commit 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within
limits") was intended to compute the pixel rate to make sure we remain
within the boundaries of what the hardware can provide.
However, unlike what mode_valid was checking for, we forgot to take
into account the clock doubling flag that can be set for modes. Let's
honor that flag if it's there.
Acked-by: Thomas Zimmermann
Reported-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 8ce5dd65f6e4..3dac839b0fa5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -799,6 +799,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
pixel_rate = mode->clock * 1000;
}
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate = pixel_rate * 2;
+
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/[amdgpu|radeon]: fix memset on io mem
When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon: [ 11.240414] pc : __memset+0x4c/0x188 [ 11.244101] lr : radeon_uvd_get_create_msg+0x114/0x1d0 [radeon] [ 11.249995] sp : 0d7eb700 [ 11.253295] x29: 0d7eb700 x28: 8001f632a868 [ 11.258585] x27: 0004 x26: 0de0 [ 11.263875] x25: 0125 x24: 0001 [ 11.269168] x23: x22: 0005 [ 11.274459] x21: 0df24000 x20: 8001f74b4000 [ 11.279753] x19: 00124000 x18: 0020 [ 11.285043] x17: x16: [ 11.290336] x15: 09309000 x14: [ 11.290340] x13: 094b6f88 x12: 094b6bd2 [ 11.290343] x11: 0d7eb700 x10: 0d7eb700 [ 11.306246] x9 : 0d7eb700 x8 : 0df2402c [ 11.306254] x7 : x6 : 094b626a [ 11.306257] x5 : x4 : 0004 [ 11.306262] x3 : x2 : 0fd4 [ 11.306265] x1 : x0 : 0df2402c [ 11.306272] Call trace: [ 11.306316] __memset+0x4c/0x188 [ 11.306638] uvd_v1_0_ib_test+0x70/0x1c0 [radeon] [ 11.306758] radeon_ib_ring_tests+0x54/0xe0 [radeon] [ 11.309961] IPv6: ADDRCONF(NETDEV_UP): enp5s0f0: link is not ready [ 11.354628] radeon_device_init+0x53c/0xbdc [radeon] [ 11.354693] radeon_driver_load_kms+0x6c/0x1b0 [radeon] [ 11.364788] drm_dev_register+0x130/0x1c0 [ 11.364794] drm_get_pci_dev+0x8c/0x14c [ 11.372704] radeon_pci_probe+0xb0/0x110 [radeon] [ 11.372715] local_pci_probe+0x3c/0xb0 [ 11.381129] pci_device_probe+0x114/0x1b0 [ 11.385121] really_probe+0x23c/0x400 [ 11.388757] driver_probe_device+0xdc/0x130 [ 11.392921] __driver_attach+0x128/0x150 [ 11.396826] bus_for_each_dev+0x70/0xbc [ 11.400643] driver_attach+0x20/0x2c [ 11.404201] bus_add_driver+0x160/0x260 [ 11.408019] driver_register+0x74/0x120 [ 11.411837] __pci_register_driver+0x40/0x50 [ 11.416149] radeon_init+0x78/0x1000 [radeon] [ 11.420489] do_one_initcall+0x54/0x154 [ 11.424310] do_init_module+0x54/0x260 [ 11.428041] load_module+0x1ccc/0x20b0 [ 11.431773] __se_sys_finit_module+0xac/0x10c [ 11.436109] __arm64_sys_finit_module+0x18/0x20 [ 11.440622] el0_svc_common+0x70/0x164 [ 11.444353] el0_svc_handler+0x2c/0x80 [ 11.448084] el0_svc+0x8/0xc [ 11.450954] Code: d65f03c0 cb0803e4 f2400c84 5480 (a9001d07) Obviously, the __memset call is generated by gcc(8.3.1). It optimizes this for loop into memset. But this may break, because dest here is cpu_addr mapped to io mem. So, just invoke `memset_io` directly, which do solve the problem here. Signed-off-by: chenli --- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 ++ drivers/gpu/drm/radeon/radeon_uvd.c | 6 ++ 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c index 7c5b60e53482..4dccde7a9e83 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c @@ -1187,8 +1187,7 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring, uint32_t handle, msg[8] = cpu_to_le32(0x0440); msg[9] = cpu_to_le32(0x); msg[10] = cpu_to_le32(0x01b37000); - for (i = 11; i < 1024; ++i) - msg[i] = cpu_to_le32(0x0); + memset_io(&msg[i], 0x0, 1013 * sizeof(uint32_t)); return amdgpu_uvd_send_msg(ring, bo, true, fence); } @@ -1212,8 +1211,7 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring, uint32_t handle, msg[1] = cpu_to_le32(0x0002); msg[2] = cpu_to_le32(handle); msg[3] = cpu_to_le32(0x); - for (i = 4; i < 1024; ++i) - msg[i] = cpu_to_le32(0x0); + memset_io(&msg[i], 0x0, 1020 * sizeof(uint32_t)); return amdgpu_uvd_send_msg(ring, bo, direct, fence); } diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c index 57fb3eb3a4b4..2e2e737c4706 100644 --- a/drivers/gpu/drm/radeon/radeon_uvd.c +++ b/drivers/gpu/drm/radeon/radeon_uvd.c @@ -802,8 +802,7 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, int ring, msg[8] = cpu_to_le32(0x0440); msg[9] = cpu_to_le32(0x); msg[10] = cpu_to_le32(0x01b37000); - for (i = 11; i < 1024; ++i) - msg[i] = cpu_to_le32(0x0); + memset_io(&msg[i], 0x0, 1013 * sizeof(uint32_t)); r = radeon_uvd_send_msg(rdev, ring, addr, fence); radeon_bo_unreserve(rdev->uvd.vcpu_bo); @@ -831,8 +830,7 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, int ring, msg[1] = cpu_to_le32(0x0002); msg[2] = cpu_to_le32(handle); msg[3] = cpu_to_le32(0x); - for (i = 4; i < 1024; ++i) - msg[i] = cpu_to_le32(0x0); + memset_io(&msg[i], 0x0, 1020 * sizeof(uint
[PATCH v2] drm/hisilicon: Fix rmmod hibmc_drm failed
drm_irq_uninstall should be called before pci_disable_msi, if use
devm_drm_irq_install to register the interrupt, the system will
call pci_disable_msi first and then call drm_irq_uninstall, which
will result in the following callstack.
This reverts commit e4401247070a37c2fce62b2773a4eb7757983938.
kernel BUG at drivers/pci/msi.c:376!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 93 PID: 173814 Comm: rmmod Tainted:
pstate: a049 (NzCv daif +PAN -UAO -TCO BTYPE=--)
pc : free_msi_irqs+0x17c/0x1a0
lr : free_msi_irqs+0x16c/0x1a0
sp : 2028157f7bd0
x29: 2028157f7bd0 x28: 202849edab00
x27: x26:
x25: x24:
x23: 0020851da000 x22: 0020851da2d8
x21: 0020cc829000 x20:
x19: 0020d6714800 x18: 0010
x17: x16:
x15: x14: 2028957f77df
x13: 2028157f77ed x12:
x11: 0040 x10: 800011b2f8e0
x9 : 800011b2f8d8 x8 : 2020203fc458
x7 : x6 :
x5 : 2020203fc430 x4 : 2020203fc4a0
x3 : x2 :
x1 : 02c9 x0 : 0020d6719500
Call trace:
free_msi_irqs+0x17c/0x1a0
pci_disable_msi+0xe4/0x118
hibmc_unload+0x44/0x80 [hibmc_drm]
hibmc_pci_remove+0x2c/0x38 [hibmc_drm]
pci_device_remove+0x48/0x108
device_release_driver_internal+0x118/0x1f0
driver_detach+0x6c/0xe0
bus_remove_driver+0x74/0x100
driver_unregister+0x34/0x60
pci_unregister_driver+0x24/0xd8
hibmc_pci_driver_exit+0x14/0xe768 [hibmc_drm]
__arm64_sys_delete_module+0x1fc/0x2d0
el0_svc_common.constprop.3+0xa8/0x188
do_el0_svc+0x80/0xa0
el0_sync_handler+0x8c/0xb0
el0_sync+0x15c/0x180
Code: f940b400 b400 a903e7b8 f90013b5 (d421)
---[ end trace 310d94ee8abef44f ]---
Kernel panic - not syncing: Oops - BUG: Fatal exception
v2:
update the commit log to indicate the patch that needs to be revert.
Signed-off-by: Tian Tao
Acked-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7e91ef1..9b5f15c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,6 +251,10 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
+
+ if (dev->irq_enabled)
+ drm_irq_uninstall(dev);
+
pci_disable_msi(dev->pdev);
return 0;
@@ -286,7 +290,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = devm_drm_irq_install(dev, dev->pdev->irq);
+ ret = drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 9/9] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 70 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 41897b8e9d51..2e5449b25ce4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -186,6 +197,8 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
if (!new_state)
return;
+ new_state->base.max_bpc = 8;
+ new_state->base.max_requested_bpc = 8;
drm_atomic_helper_connector_tv_reset(connector);
}
@@ -232,12 +245,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -506,6 +527,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -549,7 +571,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -569,6 +593,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -594,6 +621,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+ HDMI_WRITE(HDMI_GCP_CONFIG, reg);
+
HDMI_WRITE(HDMI_C
Re: [PATCH 14/65] drm/rcar-du: Annotate dma-fence critical section in commit path
On Wed, Dec 16, 2020 at 2:29 AM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote: > > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > > nothing fancy going on here. > > > > Signed-off-by: Daniel Vetter > > Cc: Laurent Pinchart > > Cc: Kieran Bingham > > Cc: linux-renesas-...@vger.kernel.org > > I'm lacking context here, there's only one instance of a call to > dma_fence_begin_signalling() in the subsystem, and no cover letter in > the series to explain what's going on. Some information would help > reviewing the patch :-) > > Also, could you mention in the cover letter for the next version if you > will merge the whole series, or expect individual maintainers to pick up > the relevant patches ? This series was a misfire of git send-email. I figured that following up to 65 patches with "I'm sorry" doesn't help the spam problem, so I only did it once. This patch was part of a proper series half a year ago, with cover letter and everything, and a few patches from that series have landed. I've planed to resubmit this all this week again. -Daniel > > > --- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > index 72dda446355f..8d91140151cc 100644 > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > @@ -441,6 +441,7 @@ static void rcar_du_atomic_commit_tail(struct > > drm_atomic_state *old_state) > > struct drm_crtc_state *crtc_state; > > struct drm_crtc *crtc; > > unsigned int i; > > + bool fence_cookie = dma_fence_begin_signalling(); > > > > /* > >* Store RGB routing to DPAD0 and DPAD1, the hardware will be > > configured > > @@ -467,6 +468,7 @@ static void rcar_du_atomic_commit_tail(struct > > drm_atomic_state *old_state) > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > > > drm_atomic_helper_commit_hw_done(old_state); > > + dma_fence_end_signalling(fence_cookie); > > drm_atomic_helper_wait_for_flip_done(dev, old_state); > > > > drm_atomic_helper_cleanup_planes(dev, old_state); > > -- > Regards, > > Laurent Pinchart -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: suspicious RCU usage in modeset_lock
On Wed, Dec 16, 2020 at 2:14 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130558c550
> kernel config: https://syzkaller.appspot.com/x/.config?x=ee8a1012a5314210
> dashboard link: https://syzkaller.appspot.com/bug?extid=972b924c988834e868b2
> compiler: gcc (GCC) 10.1.0-syz 20200507
> userspace arch: i386
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+972b924c988834e86...@syzkaller.appspotmail.com
>
> =
> WARNING: suspicious RCU usage
> 5.10.0-rc7-syzkaller #0 Not tainted
> -
> kernel/sched/core.c:7270 Illegal context switch in RCU-sched read-side
> critical section!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 0
> 7 locks held by syz-executor.1/9232:
> #0: 8b328c60 (console_lock){+.+.}-{0:0}, at: do_fb_ioctl+0x2e4/0x690
> drivers/video/fbdev/core/fbmem.c:1106
> #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: lock_fb_info
> include/linux/fb.h:636 [inline]
> #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at:
> do_fb_ioctl+0x2ee/0x690 drivers/video/fbdev/core/fbmem.c:1107
> #2: 888041adca78 (&helper->lock){+.+.}-{3:3}, at:
> drm_fb_helper_pan_display+0xce/0x970 drivers/gpu/drm/drm_fb_helper.c:1448
> #3: 8880159f01b8 (&dev->master_mutex){+.+.}-{3:3}, at:
> drm_master_internal_acquire+0x1d/0x70 drivers/gpu/drm/drm_auth.c:407
> #4: 888041adc898 (&client->modeset_mutex){+.+.}-{3:3}, at:
> drm_client_modeset_commit_locked+0x44/0x580
> drivers/gpu/drm/drm_client_modeset.c:1143
> #5: c90001c07730 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
> drm_client_modeset_commit_atomic+0xb7/0x7c0
> drivers/gpu/drm/drm_client_modeset.c:981
> #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
> ww_mutex_lock_slow include/linux/ww_mutex.h:287 [inline]
> #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
> modeset_lock+0x31c/0x650 drivers/gpu/drm/drm_modeset_lock.c:260
Given that we managed to take all these locks without upsetting anyone
the rcu section is very deep down. And looking at the backtrace below
I just couldn't find anything.
Best I can think of is that an interrupt of some sort leaked an rcu
section, and we got shot here. But I'd assume the rcu debugging would
catch this? Backtrace of the start of that rcu read side section would
be really useful here, but I'm not seeing that in the logs. There's
more stuff there, but it's just the usual "everything falls apart"
stuff of little value to understanding how we got there.
Adding some rcu people for more insights on what could have gone wrong here.
-Daniel
> stack backtrace:
> CPU: 1 PID: 9232 Comm: syz-executor.1 Not tainted 5.10.0-rc7-syzkaller #0
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:118
> ___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
> __mutex_lock_common kernel/locking/mutex.c:935 [inline]
> __ww_mutex_lock.constprop.0+0xa9/0x2cc0 kernel/locking/mutex.c:
> ww_mutex_lock+0x3d/0x170 kernel/locking/mutex.c:1190
> modeset_lock+0x392/0x650 drivers/gpu/drm/drm_modeset_lock.c:263
> drm_modeset_lock drivers/gpu/drm/drm_modeset_lock.c:342 [inline]
> drm_modeset_lock+0x50/0x90 drivers/gpu/drm/drm_modeset_lock.c:338
> drm_atomic_get_plane_state+0x19d/0x510 drivers/gpu/drm/drm_atomic.c:481
> drm_client_modeset_commit_atomic+0x225/0x7c0
> drivers/gpu/drm/drm_client_modeset.c:994
> drm_client_modeset_commit_locked+0x145/0x580
> drivers/gpu/drm/drm_client_modeset.c:1145
> pan_display_atomic drivers/gpu/drm/drm_fb_helper.c:1395 [inline]
> drm_fb_helper_pan_display+0x28b/0x970 drivers/gpu/drm/drm_fb_helper.c:1455
> fb_pan_display+0x2f7/0x6c0 drivers/video/fbdev/core/fbmem.c:925
> fb_set_var+0x57f/0xda0 drivers/video/fbdev/core/fbmem.c:1043
> do_fb_ioctl+0x2f9/0x690 drivers/video/fbdev/core/fbmem.c:1108
> fb_compat_ioctl+0x17c/0xaf0 drivers/video/fbdev/core/fbmem.c:1315
> __do_compat_sys_ioctl+0x1d3/0x230 fs/ioctl.c:842
> do_syscall_32_irqs_on arch/x86/entry/common.c:78 [inline]
> __do_fast_syscall_32+0x56/0x80 arch/x86/entry/common.c:137
> do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:160
> entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
> RIP: 0023:0xf7fd8549
> Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08
> 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90
> 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> RSP: 002b:f55d20bc EFLAGS: 0296 ORIG_RAX: 0036
> RAX: ffda RBX: 00
Re: [PATCH 1/4] dma-buf: Remove kmap kerneldoc vestiges
On Tue, Dec 15, 2020 at 03:18:49PM +0100, Christian König wrote: > Am 14.12.20 um 17:01 schrieb Daniel Vetter: > > On Mon, Dec 14, 2020 at 11:33:10AM +0100, Christian König wrote: > > > Am 11.12.20 um 16:58 schrieb Daniel Vetter: > > > > Also try to clarify a bit when dma_buf_begin/end_cpu_access should > > > > be called. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Thomas Zimmermann > > > > Cc: Sumit Semwal > > > > Cc: "Christian König" > > > > Cc: linux-me...@vger.kernel.org > > > > Cc: linaro-mm-...@lists.linaro.org > > > > --- > > > >drivers/dma-buf/dma-buf.c | 20 ++-- > > > >include/linux/dma-buf.h | 25 + > > > >2 files changed, 23 insertions(+), 22 deletions(-) > > > > > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > > > index e63684d4cd90..a12fdffa130f 100644 > > > > --- a/drivers/dma-buf/dma-buf.c > > > > +++ b/drivers/dma-buf/dma-buf.c > > > > @@ -1001,15 +1001,15 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify); > > > > * vmalloc space might be limited and result in vmap calls failing. > > > > * > > > > * Interfaces:: > > > > + * > > > > * void \*dma_buf_vmap(struct dma_buf \*dmabuf) > > > > * void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr) > > > > * > > > > * The vmap call can fail if there is no vmap support in the > > > > exporter, or if > > > > - * it runs out of vmalloc space. Fallback to kmap should be > > > > implemented. Note > > > > - * that the dma-buf layer keeps a reference count for all vmap > > > > access and > > > > - * calls down into the exporter's vmap function only when no > > > > vmapping exists, > > > > - * and only unmaps it once. Protection against concurrent > > > > vmap/vunmap calls is > > > > - * provided by taking the dma_buf->lock mutex. > > > > + * it runs out of vmalloc space. Note that the dma-buf layer keeps a > > > > reference > > > > + * count for all vmap access and calls down into the exporter's vmap > > > > function > > > > + * only when no vmapping exists, and only unmaps it once. Protection > > > > against > > > > + * concurrent vmap/vunmap calls is provided by taking the > > > > &dma_buf.lock mutex. > > > Who is talking the lock? The caller of the dma_buf_vmap/vunmap() > > > functions, > > > the functions itself or the callback inside the exporter? > > That's the part I didn't change at all here, just re-laid out the line > > breaking. I only removed the outdated kmap section here. > > I just wanted to point out that this still isn't described here very very. > > > > Should I do another patch and remove this one sentence here (it's kinda > > pointless and generally we don't muse about implementation details that > > callers don't care about)? > > Na, works like this for me. > > > I did try and do a cursory review of the dma-buf docs, but this is kinda > > not meant as an all-out revamp. Just a few things I've noticed while > > reviewing Thomas' vmap_local stuff. > > > Fell free to add an Acked-by: Christian König to > the series. Thanks for taking a look, and yeah I actually want to do a review of all the dma-buf docs but just haven't found the quiet time for that yet. Patches pushed to drm-misc-next. -Daniel > > Christian. > > > -Daniel > > > > > Christian. > > > > > > > * > > > > * - For full compatibility on the importer side with existing > > > > userspace > > > > * interfaces, which might already support mmap'ing buffers. This > > > > is needed in > > > > @@ -1098,6 +1098,11 @@ static int __dma_buf_begin_cpu_access(struct > > > > dma_buf *dmabuf, > > > > * dma_buf_end_cpu_access(). Only when cpu access is braketed by > > > > both calls is > > > > * it guaranteed to be coherent with other DMA access. > > > > * > > > > + * This function will also wait for any DMA transactions tracked > > > > through > > > > + * implicit synchronization in &dma_buf.resv. For DMA transactions > > > > with explicit > > > > + * synchronization this function will only ensure cache coherency, > > > > callers must > > > > + * ensure synchronization with such DMA transactions on their own. > > > > + * > > > > * Can return negative error values, returns 0 on success. > > > > */ > > > >int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > > > > @@ -1199,7 +1204,10 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap); > > > > * This call may fail due to lack of virtual mapping address space. > > > > * These calls are optional in drivers. The intended use for them > > > > * is for mapping objects linear in kernel space for high use > > > > objects. > > > > - * Please attempt to use kmap/kunmap before thinking about these > > > > interfaces. > > > > + * > > > > + * To ensure coherency users must call dma_buf_begin_cpu_access() and > > > > + * dma_buf_end_cpu_access() around any cpu access performed through > > > > this > > > > + * mapping. > > > >
[PATCH v6 15/15] drm/i915/display: Let PCON convert from RGB to YUV if it can
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.
v2: As suggested by Uma Shankar, considered case for colorspace
BT709 and BT2020, and default to BT609. Also appended dir
'display' in commit message.
v3: Fixed typo in condition for printing one of the error msg.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 68 +++
drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
4 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index fbc07a93504b..17eaa56c5a99 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
+ intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
/*
* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
@@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_ddi_init_dp_buf_reg(encoder, crtc_state);
if (!is_mst)
intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
- intel_dp_configure_protocol_converter(intel_dp);
+ intel_dp_configure_protocol_converter(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 4c01c7c23dfd..2009ae9e9678 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,7 @@ struct intel_dp {
int pcon_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+ bool rgb_to_ycbcr;
} dfp;
/* Display stream compression testing */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index abc9b772d1c8..366b2e4e7f4a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector *connector,
!drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
+ if (intel_dp->dfp.rgb_to_ycbcr &&
+ intel_dp->dfp.ycbcr_444_to_420)
+ return INTEL_OUTPUT_FORMAT_RGB;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
@@ -4311,7 +4315,8 @@ static void intel_dp_enable_port(struct intel_dp
*intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
-void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
+void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 tmp;
@@ -4338,14 +4343,34 @@ void intel_dp_configure_protocol_converter(struct
intel_dp *intel_dp)
drm_dbg_kms(&i915->drm,
"Failed to set protocol converter YCbCr 4:2:0
conversion mode to %s\n",
enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
-
- tmp = 0;
-
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
+ if (intel_dp->dfp.rgb_to_ycbcr) {
+ bool bt2020, bt709;
+
+ bt2020 =
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+
intel_dp->downstream_ports,
+
DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
+ bt709 =
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+
intel_dp->downstream_ports,
+
DP_DS_HDMI_BT709_RGB_YCBCR_CONV);
+ switch (crtc_state->infoframes.vsc.colorimetry) {
+ case DP_COLORIMETRY_BT2020_RGB:
+ case DP_COLORIMETRY_BT2020_YCC:
+ tmp = bt2020 ? DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE :
0;
+ break;
+ case DP_COLORIMETRY_BT709_YCC:
+ case DP_COLORIMETRY_XVYCC_709:
+ tmp = bt709 ? DP_CONVERSION_BT709_RGB_YC
[PATCH] drm/etnaviv: provide more ID values via GET_PARAM ioctl.
Make it possible for the user space to access these ID values.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
include/uapi/drm/etnaviv_drm.h| 3 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index c6404b8d067f..ec16991ba8b6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -156,6 +156,18 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
param, u64 *value)
*value = ~0ULL;
break;
+ case ETNAVIV_PARAM_GPU_PRODUCT_ID:
+ *value = gpu->identity.product_id;
+ break;
+
+ case ETNAVIV_PARAM_GPU_CUSTOMER_ID:
+ *value = gpu->identity.customer_id;
+ break;
+
+ case ETNAVIV_PARAM_GPU_ECO_ID:
+ *value = gpu->identity.eco_id;
+ break;
+
default:
DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
return -EINVAL;
diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index 09d0df8b71c5..af024d90453d 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -74,6 +74,9 @@ struct drm_etnaviv_timespec {
#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
#define ETNAVIV_PARAM_GPU_NUM_VARYINGS 0x1a
#define ETNAVIV_PARAM_SOFTPIN_START_ADDR0x1b
+#define ETNAVIV_PARAM_GPU_PRODUCT_ID0x1c
+#define ETNAVIV_PARAM_GPU_CUSTOMER_ID 0x1d
+#define ETNAVIV_PARAM_GPU_ECO_ID0x1e
#define ETNA_MAX_PIPES 4
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information
On 15/12/2020 16.26, Rob Herring wrote: > On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote: >> My employment with TI is coming to an end and I will not have access to >> the board where this bridge is connected to. >> >> It is better to remove a soon bouncing email address. >> >> Signed-off-by: Peter Ujfalusi >> --- >> .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 --- >> 1 file changed, 3 deletions(-) >> > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > 'maintainers' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml: > ignoring, error in schema: > warning: no schema found in file: > ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml Right, so it is not that easy to not been able to maintain this... :o Who should be documented as maintainer? Andrzej, Neil, David or Daniel? I will have no access to the EVM (I no longer have) and the documentation is going to be wiped along with the disk as well... > See https://patchwork.ozlabs.org/patch/1416419 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm: rcar-du: Use drm_bridge_connector_init() helper
Hi Laurent,
On Wed, Dec 16, 2020 at 02:50:21AM +0200, Laurent Pinchart wrote:
> Use the drm_bridge_connector_init() helper to create a drm_connector for
> each output, instead of relying on the bridge drivers doing so. Attach
> the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
> them not to create a connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 25 ++-
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index ba8c6038cd63..10a66091391a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -11,6 +11,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -61,6 +62,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>struct device_node *enc_node)
> {
> struct rcar_du_encoder *renc;
> + struct drm_connector *connector;
> struct drm_bridge *bridge;
> int ret;
>
> @@ -122,9 +124,22 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> if (ret)
> return ret;
>
> - /*
> - * Attach the bridge to the encoder. The bridge will create the
> - * connector.
> - */
> - return drm_bridge_attach(&renc->base, bridge, NULL, 0);
> + /* Attach the bridge to the encoder. */
> + ret = drm_bridge_attach(&renc->base, bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> + if (ret) {
> + dev_err(rcdu->dev, "failed to attach bridge for output %u\n",
> + output);
> + return ret;
> + }
> +
> + /* Create the connector for the chain of bridges. */
> + connector = drm_bridge_connector_init(&rcdu->ddev, &renc->base);
> + if (IS_ERR(connector)) {
> + dev_err(rcdu->dev,
> + "failed to created connector for output %u\n", output);
> + return PTR_ERR(connector);
> + }
> +
> + return drm_connector_attach_encoder(connector, &renc->base);
Looks good
Reviewed-by: Jacopo Mondi
I'm trying to figure out how deferred probe of a panel directly
connected to the lvds encoder work. I assume there's no risk of
creating the connector before the panel is probed, or this is not an
issue.
> }
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Update addresses for TI display drivers
Update the maintainer email addresses for TI display drivers. Signed-off-by: Tomi Valkeinen --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 281de213ef47..c21471497a18 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5932,8 +5932,8 @@ F: Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml F: drivers/gpu/drm/stm DRM DRIVERS FOR TI KEYSTONE -M: Jyri Sarha -M: Tomi Valkeinen +M: Jyri Sarha +M: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc @@ -5943,15 +5943,15 @@ F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml F: drivers/gpu/drm/tidss/ DRM DRIVERS FOR TI LCDC -M: Jyri Sarha -R: Tomi Valkeinen +M: Jyri Sarha +R: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained F: Documentation/devicetree/bindings/display/tilcdc/ F: drivers/gpu/drm/tilcdc/ DRM DRIVERS FOR TI OMAP -M: Tomi Valkeinen +M: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained F: Documentation/devicetree/bindings/display/ti/ -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[kbuild] Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem
Hi Chen,
url:
https://github.com/0day-ci/linux/commits/Chen-Li/drm-amdgpu-radeon-fix-memset-on-io-mem/20201216-165835
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
d01e7f10dae29eba0f9ada82b65d24e035d5b2f9
config: x86_64-randconfig-m001-20201216 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/radeon/radeon_uvd.c:805 radeon_uvd_get_create_msg() error:
uninitialized symbol 'i'.
drivers/gpu/drm/radeon/radeon_uvd.c:833 radeon_uvd_get_destroy_msg() error:
uninitialized symbol 'i'.
Old smatch warnings:
drivers/gpu/drm/radeon/radeon_uvd.c:568 radeon_uvd_cs_msg() warn: ignoring
unreachable code.
vim +/i +805 drivers/gpu/drm/radeon/radeon_uvd.c
f2ba57b5eab8817 Christian König 2013-04-08 777 int
radeon_uvd_get_create_msg(struct radeon_device *rdev, int ring,
f2ba57b5eab8817 Christian König 2013-04-08 778
uint32_t handle, struct radeon_fence **fence)
f2ba57b5eab8817 Christian König 2013-04-08 779 {
feba9b0bcf492ba Christian König 2014-08-22 780 /* we use the last page
of the vcpu bo for the UVD message */
feba9b0bcf492ba Christian König 2014-08-22 781 uint64_t offs =
radeon_bo_size(rdev->uvd.vcpu_bo) -
feba9b0bcf492ba Christian König 2014-08-22 782
RADEON_GPU_PAGE_SIZE;
f2ba57b5eab8817 Christian König 2013-04-08 783
feba9b0bcf492ba Christian König 2014-08-22 784 uint32_t *msg =
rdev->uvd.cpu_addr + offs;
feba9b0bcf492ba Christian König 2014-08-22 785 uint64_t addr =
rdev->uvd.gpu_addr + offs;
f2ba57b5eab8817 Christian König 2013-04-08 786
feba9b0bcf492ba Christian König 2014-08-22 787 int r, i;
f2ba57b5eab8817 Christian König 2013-04-08 788
feba9b0bcf492ba Christian König 2014-08-22 789 r =
radeon_bo_reserve(rdev->uvd.vcpu_bo, true);
feba9b0bcf492ba Christian König 2014-08-22 790 if (r)
f2ba57b5eab8817 Christian König 2013-04-08 791 return r;
f2ba57b5eab8817 Christian König 2013-04-08 792
f2ba57b5eab8817 Christian König 2013-04-08 793 /* stitch together an
UVD create msg */
9b1be4dc02bb6b9 Alex Deucher2013-06-07 794 msg[0] =
cpu_to_le32(0x0de4);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 795 msg[1] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 796 msg[2] =
cpu_to_le32(handle);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 797 msg[3] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 798 msg[4] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 799 msg[5] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 800 msg[6] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 801 msg[7] =
cpu_to_le32(0x0780);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 802 msg[8] =
cpu_to_le32(0x0440);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 803 msg[9] =
cpu_to_le32(0x);
9b1be4dc02bb6b9 Alex Deucher2013-06-07 804 msg[10] =
cpu_to_le32(0x01b37000);
201257d71c519be Chen Li 2020-12-16 @805 memset_io(&msg[i], 0x0,
1013 * sizeof(uint32_t));
^^^
The "i" variable is never initialized anywhere.
f2ba57b5eab8817 Christian König 2013-04-08 806
feba9b0bcf492ba Christian König 2014-08-22 807 r =
radeon_uvd_send_msg(rdev, ring, addr, fence);
feba9b0bcf492ba Christian König 2014-08-22 808
radeon_bo_unreserve(rdev->uvd.vcpu_bo);
feba9b0bcf492ba Christian König 2014-08-22 809 return r;
f2ba57b5eab8817 Christian König 2013-04-08 810 }
f2ba57b5eab8817 Christian König 2013-04-08 811
f2ba57b5eab8817 Christian König 2013-04-08 812 int
radeon_uvd_get_destroy_msg(struct radeon_device *rdev, int ring,
f2ba57b5eab8817 Christian König 2013-04-08 813
uint32_t handle, struct radeon_fence **fence)
f2ba57b5eab8817 Christian König 2013-04-08 814 {
feba9b0bcf492ba Christian König 2014-08-22 815 /* we use the last page
of the vcpu bo for the UVD message */
feba9b0bcf492ba Christian König 2014-08-22 816 uint64_t offs =
radeon_bo_size(rdev->uvd.vcpu_bo) -
feba9b0bcf492ba Christian König 2014-08-22 817
RADEON_GPU_PAGE_SIZE;
f2ba57b5eab8817 Christian König 2013-04-08 818
feba9b0bcf492ba Christian König 2014-08-22 819 uint32_t *msg =
rdev->uvd.cpu_addr + offs;
feba9b0bcf492ba Christian König 2014-08-22 820 uint64_t addr =
rdev->uvd.gpu_addr + offs;
f2ba57b5eab8817 Christian König 2013-04-08 821
feba9b0bcf492ba Christian König 2014-08-22 822 int r, i;
f2ba57b5eab8817 Christian König 20
Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem
Hi Chen, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.10 next-20201215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Chen-Li/drm-amdgpu-radeon-fix-memset-on-io-mem/20201216-165835 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git d01e7f10dae29eba0f9ada82b65d24e035d5b2f9 config: x86_64-randconfig-a002-20201216 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 71601d2ac9954cb59c443cb3ae442cb106df35d4) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://github.com/0day-ci/linux/commit/201257d71c519bef0966e555d95bf820512f5a34 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Chen-Li/drm-amdgpu-radeon-fix-memset-on-io-mem/20201216-165835 git checkout 201257d71c519bef0966e555d95bf820512f5a34 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/gpu/drm/radeon/radeon_uvd.c:159:6: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] version_major, version_minor, family_id); ^ include/drm/drm_print.h:484:29: note: expanded from macro 'DRM_INFO' _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__) ~~~^~~ include/drm/drm_print.h:481:53: note: expanded from macro '_DRM_PRINTK' printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__) ~~~^~~ drivers/gpu/drm/radeon/radeon_uvd.c:159:21: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] version_major, version_minor, family_id); ^ include/drm/drm_print.h:484:29: note: expanded from macro 'DRM_INFO' _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__) ~~~^~~ include/drm/drm_print.h:481:53: note: expanded from macro '_DRM_PRINTK' printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__) ~~~^~~ drivers/gpu/drm/radeon/radeon_uvd.c:159:36: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] version_major, version_minor, family_id); ^ include/drm/drm_print.h:484:29: note: expanded from macro 'DRM_INFO' _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__) ~~~^~~ include/drm/drm_print.h:481:53: note: expanded from macro '_DRM_PRINTK' printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__) ~~~^~~ >> drivers/gpu/drm/radeon/radeon_uvd.c:805:17: warning: variable 'i' is >> uninitialized when used here [-Wuninitialized] memset_io(&msg[i], 0x0, 1013 * sizeof(uint32_t)); ^ drivers/gpu/drm/radeon/radeon_uvd.c:787:10: note: initialize the variable 'i' to silence this warning int r, i; ^ = 0 drivers/gpu/drm/radeon/radeon_uvd.c:833:17: warning: variable 'i' is uninitialized when used here [-Wuninitialized] memset_io(&msg[i], 0x0, 1020 * sizeof(uint32_t)); ^ drivers/gpu/drm/radeon/radeon_uvd.c:822:10: note: initialize the variable 'i' to silence this warning int r, i; ^ = 0 5 warnings generated. vim +/i +805 drivers/gpu/drm/radeon/radeon_uvd.c 771 772 /* 773 * multiple fence commands without any stream commands in between can 774 * crash the vcpu so just try to emmit a dummy create/destroy msg to 775 * avoid this
Re: [PATCH v2 1/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Wed, Dec 16, 2020 at 02:50:18AM +0200, Laurent Pinchart wrote:
> Replace the manual panel handling with usage of the DRM panel bridge
> helper. This simplifies the driver, and brings support for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 120 +++-
> 1 file changed, 12 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 70dbbe44bb23..1b360e06658c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -63,7 +63,6 @@ struct rcar_lvds {
> struct drm_bridge bridge;
>
> struct drm_bridge *next_bridge;
> - struct drm_connector connector;
> struct drm_panel *panel;
>
> void __iomem *mmio;
> @@ -80,73 +79,11 @@ struct rcar_lvds {
> #define bridge_to_rcar_lvds(b) \
> container_of(b, struct rcar_lvds, bridge)
>
> -#define connector_to_rcar_lvds(c) \
> - container_of(c, struct rcar_lvds, connector)
> -
> static void rcar_lvds_write(struct rcar_lvds *lvds, u32 reg, u32 data)
> {
> iowrite32(data, lvds->mmio + reg);
> }
>
> -/*
> -
> - * Connector & Panel
> - */
> -
> -static int rcar_lvds_connector_get_modes(struct drm_connector *connector)
> -{
> - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> -
> - return drm_panel_get_modes(lvds->panel, connector);
> -}
> -
> -static int rcar_lvds_connector_atomic_check(struct drm_connector *connector,
> - struct drm_atomic_state *state)
> -{
> - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> - const struct drm_display_mode *panel_mode;
> - struct drm_connector_state *conn_state;
> - struct drm_crtc_state *crtc_state;
> -
> - conn_state = drm_atomic_get_new_connector_state(state, connector);
> - if (!conn_state->crtc)
> - return 0;
> -
> - if (list_empty(&connector->modes)) {
> - dev_dbg(lvds->dev, "connector: empty modes list\n");
> - return -EINVAL;
> - }
> -
> - panel_mode = list_first_entry(&connector->modes,
> - struct drm_display_mode, head);
> -
> - /* We're not allowed to modify the resolution. */
> - crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> - if (IS_ERR(crtc_state))
> - return PTR_ERR(crtc_state);
> -
> - if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> - crtc_state->mode.vdisplay != panel_mode->vdisplay)
> - return -EINVAL;
> -
> - /* The flat panel mode is fixed, just copy it to the adjusted mode. */
> - drm_mode_copy(&crtc_state->adjusted_mode, panel_mode);
> -
> - return 0;
> -}
> -
> -static const struct drm_connector_helper_funcs rcar_lvds_conn_helper_funcs =
> {
> - .get_modes = rcar_lvds_connector_get_modes,
> - .atomic_check = rcar_lvds_connector_atomic_check,
> -};
> -
> -static const struct drm_connector_funcs rcar_lvds_conn_funcs = {
> - .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .destroy = drm_connector_cleanup,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> -};
> -
> /*
> -
> * PLL Setup
> */
> @@ -583,11 +520,6 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
> *bridge,
> /* Turn the output on. */
> lvdcr0 |= LVDCR0_LVRES;
> rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> -
> - if (lvds->panel) {
> - drm_panel_prepare(lvds->panel);
> - drm_panel_enable(lvds->panel);
> - }
> }
>
> static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> @@ -609,11 +541,6 @@ static void rcar_lvds_atomic_disable(struct drm_bridge
> *bridge,
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
>
> - if (lvds->panel) {
> - drm_panel_disable(lvds->panel);
> - drm_panel_unprepare(lvds->panel);
> - }
> -
> rcar_lvds_write(lvds, LVDCR0, 0);
> rcar_lvds_write(lvds, LVDCR1, 0);
> rcar_lvds_write(lvds, LVDPLLCR, 0);
> @@ -648,45 +575,13 @@ static int rcar_lvds_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> - struct drm_connector *connector = &lvds->connector;
> - struct drm_encoder *encoder = bridge->encoder;
> - int ret;
>
> - /* If we have a next bridge just attach it. */
> - if (lvds->next_bridge)
> - return drm_bridge_attach(bridge->encoder, lvds->next_bridge,
> -
Re: [PATCH v2 1/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Jacopo,
On Wed, Dec 16, 2020 at 02:16:56PM +0100, Jacopo Mondi wrote:
> On Wed, Dec 16, 2020 at 02:50:18AM +0200, Laurent Pinchart wrote:
> > Replace the manual panel handling with usage of the DRM panel bridge
> > helper. This simplifies the driver, and brings support for
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 120 +++-
> > 1 file changed, 12 insertions(+), 108 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 70dbbe44bb23..1b360e06658c 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -63,7 +63,6 @@ struct rcar_lvds {
> > struct drm_bridge bridge;
> >
> > struct drm_bridge *next_bridge;
> > - struct drm_connector connector;
> > struct drm_panel *panel;
> >
> > void __iomem *mmio;
> > @@ -80,73 +79,11 @@ struct rcar_lvds {
> > #define bridge_to_rcar_lvds(b) \
> > container_of(b, struct rcar_lvds, bridge)
> >
> > -#define connector_to_rcar_lvds(c) \
> > - container_of(c, struct rcar_lvds, connector)
> > -
> > static void rcar_lvds_write(struct rcar_lvds *lvds, u32 reg, u32 data)
> > {
> > iowrite32(data, lvds->mmio + reg);
> > }
> >
> > -/*
> > -
> > - * Connector & Panel
> > - */
> > -
> > -static int rcar_lvds_connector_get_modes(struct drm_connector *connector)
> > -{
> > - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> > -
> > - return drm_panel_get_modes(lvds->panel, connector);
> > -}
> > -
> > -static int rcar_lvds_connector_atomic_check(struct drm_connector
> > *connector,
> > - struct drm_atomic_state *state)
> > -{
> > - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> > - const struct drm_display_mode *panel_mode;
> > - struct drm_connector_state *conn_state;
> > - struct drm_crtc_state *crtc_state;
> > -
> > - conn_state = drm_atomic_get_new_connector_state(state, connector);
> > - if (!conn_state->crtc)
> > - return 0;
> > -
> > - if (list_empty(&connector->modes)) {
> > - dev_dbg(lvds->dev, "connector: empty modes list\n");
> > - return -EINVAL;
> > - }
> > -
> > - panel_mode = list_first_entry(&connector->modes,
> > - struct drm_display_mode, head);
> > -
> > - /* We're not allowed to modify the resolution. */
> > - crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> > - if (IS_ERR(crtc_state))
> > - return PTR_ERR(crtc_state);
> > -
> > - if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> > - crtc_state->mode.vdisplay != panel_mode->vdisplay)
> > - return -EINVAL;
> > -
> > - /* The flat panel mode is fixed, just copy it to the adjusted mode. */
> > - drm_mode_copy(&crtc_state->adjusted_mode, panel_mode);
> > -
> > - return 0;
> > -}
> > -
> > -static const struct drm_connector_helper_funcs rcar_lvds_conn_helper_funcs
> > = {
> > - .get_modes = rcar_lvds_connector_get_modes,
> > - .atomic_check = rcar_lvds_connector_atomic_check,
> > -};
> > -
> > -static const struct drm_connector_funcs rcar_lvds_conn_funcs = {
> > - .reset = drm_atomic_helper_connector_reset,
> > - .fill_modes = drm_helper_probe_single_connector_modes,
> > - .destroy = drm_connector_cleanup,
> > - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > -};
> > -
> > /*
> > -
> > * PLL Setup
> > */
> > @@ -583,11 +520,6 @@ static void __rcar_lvds_atomic_enable(struct
> > drm_bridge *bridge,
> > /* Turn the output on. */
> > lvdcr0 |= LVDCR0_LVRES;
> > rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> > -
> > - if (lvds->panel) {
> > - drm_panel_prepare(lvds->panel);
> > - drm_panel_enable(lvds->panel);
> > - }
> > }
> >
> > static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> > @@ -609,11 +541,6 @@ static void rcar_lvds_atomic_disable(struct drm_bridge
> > *bridge,
> > {
> > struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> >
> > - if (lvds->panel) {
> > - drm_panel_disable(lvds->panel);
> > - drm_panel_unprepare(lvds->panel);
> > - }
> > -
> > rcar_lvds_write(lvds, LVDCR0, 0);
> > rcar_lvds_write(lvds, LVDCR1, 0);
> > rcar_lvds_write(lvds, LVDPLLCR, 0);
> > @@ -648,45 +575,13 @@ static int rcar_lvds_attach(struct drm_bridge *bridge,
> > enum drm_bridge_attach_flags flags)
> > {
> > struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> > - struct drm_connector *connector = &lvds->connector;
> > - struct drm_encoder *encoder = bridge->encod
Re: [PATCH] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent,
I wonder if 'leaked' is correct in subject. It probably is,
un-balanced ref-counting will prevent the device from being released.
It should however happen only at system tear-down, doesn't it ?
On Wed, Dec 16, 2020 at 03:22:18AM +0200, Laurent Pinchart wrote:
> The device references acquired by of_find_device_by_node() are not
> released by the driver. Fix this by registering a cleanup action.
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 92dfa3d4c011..7070f3c9b529 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -721,6 +722,8 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>
> of_node_put(cmm);
>
> + rcdu->cmms[i] = pdev;
> +
In the unfortunate event that the cmm intialization fails here below,
rcdu->cmms[i] will stay assigned, causing the rcar_du_crtc_create()
function which is called just after rcar_du_cmm_init() to access a
non-valid cmm instance.
I would either reset the rcdu->cmms[i] field to NULL in the below error
paths, or maintain the cmms[i] = pdev assignement at the end of the
function and put_device(pdev->dev) in the error paths.
Thanks
j
> /*
>* -ENODEV is used to report that the CMM config option is
>* disabled: return 0 and let the DU continue probing.
> @@ -739,13 +742,22 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> "Failed to create device link to CMM%u\n", i);
> return -EINVAL;
> }
> -
> - rcdu->cmms[i] = pdev;
> }
>
> return 0;
> }
>
> +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i) {
> + if (rcdu->cmms[i])
> + put_device(&rcdu->cmms[i]->dev);
> + }
> +}
> +
> int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> {
> static const unsigned int mmio_offsets[] = {
> @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> if (ret)
> return ret;
>
> + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> + if (ret)
> + return ret;
> +
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.normalize_zpos = true;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: bridge: renesas, lvds: RZ/G2E needs renesas,companion too
Hi Laurent, Fabrizio On Wed, Dec 16, 2020 at 12:59:27AM +0200, Laurent Pinchart wrote: > From: Fabrizio Castro > > Document RZ/G2E support for property renesas,companion. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Laurent Pinchart > Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Thanks j > --- > Changes since v1: > > - Slight reword of SoC list in description > --- > .../devicetree/bindings/display/bridge/renesas,lvds.yaml| 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > index e5b163951b91..7eddcdb666dc 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > @@ -83,9 +83,9 @@ properties: > $ref: /schemas/types.yaml#/definitions/phandle > description: >phandle to the companion LVDS encoder. This property is mandatory > - for the first LVDS encoder on D3 and E3 SoCs, and shall point to > - the second encoder to be used as a companion in dual-link mode. It > - shall not be set for any other LVDS encoder. > + for the first LVDS encoder on R-Car D3 and E3, and RZ/G2E SoCs, and > shall > + point to the second encoder to be used as a companion in dual-link > mode. > + It shall not be set for any other LVDS encoder. > > required: >- compatible > -- > Regards, > > Laurent Pinchart > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm: rcar-du: Use drm_bridge_connector_init() helper
Hi Jacopo,
On Wed, Dec 16, 2020 at 12:53:19PM +0100, Jacopo Mondi wrote:
> On Wed, Dec 16, 2020 at 02:50:21AM +0200, Laurent Pinchart wrote:
> > Use the drm_bridge_connector_init() helper to create a drm_connector for
> > each output, instead of relying on the bridge drivers doing so. Attach
> > the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
> > them not to create a connector.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 25 ++-
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > index ba8c6038cd63..10a66091391a 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> > @@ -11,6 +11,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -61,6 +62,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > struct device_node *enc_node)
> > {
> > struct rcar_du_encoder *renc;
> > + struct drm_connector *connector;
> > struct drm_bridge *bridge;
> > int ret;
> >
> > @@ -122,9 +124,22 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> > if (ret)
> > return ret;
> >
> > - /*
> > -* Attach the bridge to the encoder. The bridge will create the
> > -* connector.
> > -*/
> > - return drm_bridge_attach(&renc->base, bridge, NULL, 0);
> > + /* Attach the bridge to the encoder. */
> > + ret = drm_bridge_attach(&renc->base, bridge, NULL,
> > + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > + if (ret) {
> > + dev_err(rcdu->dev, "failed to attach bridge for output %u\n",
> > + output);
> > + return ret;
> > + }
> > +
> > + /* Create the connector for the chain of bridges. */
> > + connector = drm_bridge_connector_init(&rcdu->ddev, &renc->base);
> > + if (IS_ERR(connector)) {
> > + dev_err(rcdu->dev,
> > + "failed to created connector for output %u\n", output);
> > + return PTR_ERR(connector);
> > + }
> > +
> > + return drm_connector_attach_encoder(connector, &renc->base);
>
> Looks good
> Reviewed-by: Jacopo Mondi
>
> I'm trying to figure out how deferred probe of a panel directly
> connected to the lvds encoder work. I assume there's no risk of
> creating the connector before the panel is probed, or this is not an
> issue.
If the panel isn't probed yet, the call to drm_of_find_panel_or_bridge()
in rcar_lvds_parse_dt() will defer probing of the LVDS encoder, which in
turn will defer probind of the DU as the LVDS bridge won't be
registered.
> > }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Fix leak of CMM platform device reference
Hi Jacopo,
On Wed, Dec 16, 2020 at 02:51:34PM +0100, Jacopo Mondi wrote:
> Hi Laurent,
>
> I wonder if 'leaked' is correct in subject. It probably is,
> un-balanced ref-counting will prevent the device from being released.
> It should however happen only at system tear-down, doesn't it ?
As the CMM shouldn't be hotplugged, yes. It's not really the device that
is leaked here, but the reference.
> On Wed, Dec 16, 2020 at 03:22:18AM +0200, Laurent Pinchart wrote:
> > The device references acquired by of_find_device_by_node() are not
> > released by the driver. Fix this by registering a cleanup action.
> >
> > Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 92dfa3d4c011..7070f3c9b529 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -721,6 +722,8 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> >
> > of_node_put(cmm);
> >
> > + rcdu->cmms[i] = pdev;
> > +
>
> In the unfortunate event that the cmm intialization fails here below,
> rcdu->cmms[i] will stay assigned, causing the rcar_du_crtc_create()
> function which is called just after rcar_du_cmm_init() to access a
> non-valid cmm instance.
>
> I would either reset the rcdu->cmms[i] field to NULL in the below error
> paths, or maintain the cmms[i] = pdev assignement at the end of the
> function and put_device(pdev->dev) in the error paths.
You're right. I'll fix that.
> > /*
> > * -ENODEV is used to report that the CMM config option is
> > * disabled: return 0 and let the DU continue probing.
> > @@ -739,13 +742,22 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > *rcdu)
> > "Failed to create device link to CMM%u\n", i);
> > return -EINVAL;
> > }
> > -
> > - rcdu->cmms[i] = pdev;
> > }
> >
> > return 0;
> > }
> >
> > +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> > +{
> > + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i) {
> > + if (rcdu->cmms[i])
> > + put_device(&rcdu->cmms[i]->dev);
> > + }
> > +}
> > +
> > int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > {
> > static const unsigned int mmio_offsets[] = {
> > @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > if (ret)
> > return ret;
> >
> > + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> > + if (ret)
> > + return ret;
> > +
> > dev->mode_config.min_width = 0;
> > dev->mode_config.min_height = 0;
> > dev->mode_config.normalize_zpos = true;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: rework ttm_tt page limit v2
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during swapout while trying to handle the memory shortage.
This is only partially a good idea. First of all it is perfectly
valid for an application to use all of system memory, limiting it to
50% is not really acceptable.
What we need to take care of is that the application is held
accountable for the memory it allocated. This is what control
mechanisms like memcg and the normal Linux page accounting already do.
Making sure that we don't run into an OOM situation while trying to
cope with a memory shortage is still a good idea, but this is also
not very well implemented since it means another opportunity of
recursion from the driver back into TTM.
So start to rework all of this by implementing a shrinker callback which
allows for TT object to be swapped out if necessary.
v2: Switch from limit to shrinker callback.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 +-
drivers/gpu/drm/ttm/ttm_memory.c| 7 ++-
drivers/gpu/drm/ttm/ttm_tt.c| 82 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 2 +-
include/drm/ttm/ttm_tt.h| 6 ++-
6 files changed, 91 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31e8b3da5563..f1f3fd085465 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1412,7 +1412,7 @@ EXPORT_SYMBOL(ttm_bo_wait);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
+int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_bo_global *glob = &ttm_bo_glob;
struct ttm_buffer_object *bo;
@@ -1495,7 +1495,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->bdev->driver->swap_notify)
bo->bdev->driver->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm);
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
/**
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index a3bfbd9cea68..3d2479d0ce2c 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "ttm_module.h"
@@ -276,9 +277,9 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(&glob->lock);
- ret = ttm_bo_swapout(ctx);
+ ret = ttm_bo_swapout(ctx, 0);
spin_lock(&glob->lock);
- if (unlikely(ret != 0))
+ if (unlikely(ret < 0))
break;
}
@@ -453,6 +454,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
zone->name, (unsigned long long)zone->max_mem >> 10);
}
ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
+ ttm_tt_mgr_init();
return 0;
out_no_zone:
ttm_mem_global_release(glob);
@@ -466,6 +468,7 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
/* let the page allocator first stop the shrink work. */
ttm_pool_mgr_fini();
+ ttm_tt_mgr_fini();
flush_workqueue(glob->swap_queue);
destroy_workqueue(glob->swap_queue);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 7f75a13163f0..d454c428c56a 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,8 @@
#include
#include
+static struct shrinker mm_shrinker;
+
/*
* Allocates a ttm structure for the given BO.
*/
@@ -223,13 +225,23 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
return ret;
}
-int ttm_tt_swapout(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
+/**
+ * ttm_tt_swapout - swap out tt object
+ *
+ * @bdev: TTM device structure.
+ * @ttm: The struct ttm_tt.
+ * @gfp_flags: Flags to use for memory allocation.
+ *
+ * Swapout a TT object to a shmem_file, return number of pages swapped out or
+ * negative error code.
+ */
+int ttm_tt_swapout(struct ttm_bo_device *bdev, struct ttm_tt *ttm,
+ gfp_t gfp_flags)
{
struct address_space *swap_space;
struct file *swap_storage;
struct page *from_page;
struct page *to_page;
- gfp_t gfp_mask;
int i, ret;
swap_storage = shmem_file_setup("ttm swap",
@@ -241,14 +253,14 @@ int ttm_tt_swapout(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
}
swap_space = swap_storage->f_mapping;
- gfp_mask = mappi
[PATCH 2/2] drm/ttm: move memory accounting into vmwgfx
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 16 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 8 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 6 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 +--
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_object.c | 4 +-
drivers/gpu/drm/radeon/radeon_object.c| 8 +--
drivers/gpu/drm/ttm/Makefile | 6 +--
drivers/gpu/drm/ttm/ttm_bo.c | 52 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_pool.c| 13 +
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c | 19 +++
.../gpu/drm/vmwgfx}/ttm_memory.h | 5 +-
drivers/gpu/drm/vmwgfx/ttm_object.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 22 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 28 +-
include/drm/ttm/ttm_bo_api.h | 13 +
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_tt.h | 1 +
21 files changed, 107 insertions(+), 114 deletions(-)
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c (97%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_memory.h (97%)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index a9647e7f98a8..5ed1c88b8748 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -118,6 +118,16 @@ void amdgpu_amdkfd_gpuvm_init_mem_limits(void)
*/
#define ESTIMATE_PT_SIZE(mem_size) ((mem_size) >> 14)
+static size_t amdgpu_amdkfd_acc_size(uint64_t size)
+{
+ size >>= PAGE_SHIFT;
+ size *= sizeof(dma_addr_t) + sizeof(void *);
+
+ return __roundup_pow_of_two(sizeof(struct amdgpu_bo)) +
+ __rountup_pow_of_two(sizeof(struct ttm_tt)) +
+ PAGE_ALIGN(size);
+}
+
static int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 domain, bool sg)
{
@@ -126,8 +136,7 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
size_t acc_size, system_mem_needed, ttm_mem_needed, vram_needed;
int ret = 0;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
vram_needed = 0;
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
@@ -174,8 +183,7 @@ static void unreserve_mem_limit(struct amdgpu_device *adev,
{
size_t acc_size;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
spin_lock(&kfd_mem_limit.mem_limit_lock);
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 6cc9919b12cc..599c9a132eb6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -523,7 +523,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
- size_t acc_size;
int r;
/* Note that GDS/GWS/OA allocates 1 page per byte/resource. */
@@ -546,9 +545,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
*bo_ptr = NULL;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
-
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
@@ -577,8 +573,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.priority = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
-&bo->placement, page_align, &ctx, acc_size,
-NULL, bp->resv, &amdgpu_bo_destroy);
+&bo->placement, page_align, &ctx, NULL,
+bp->resv, &amdgpu_bo_destroy);
if (unlikely(r != 0))
return r;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 02ca22e90290..5cf7797048e1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -189,7 +189,6 @@ struct drm_gem_vram_object *drm_gem_vram_c
[PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
The device references acquired by of_find_device_by_node() are not
released by the driver. Fix this by registering a cleanup action.
Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Only set rcdu->cmms[] if the CMM config option is enabled
- Use platform_device_put()
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 92dfa3d4c011..fdb8a0d127ad 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
* disabled: return 0 and let the DU continue probing.
*/
ret = rcar_cmm_init(pdev);
- if (ret)
+ if (ret) {
+ platform_device_put(pdev);
return ret == -ENODEV ? 0 : ret;
+ }
+
+ rcdu->cmms[i] = pdev;
/*
* Enforce suspend/resume ordering by making the CMM a provider
@@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
"Failed to create device link to CMM%u\n", i);
return -EINVAL;
}
-
- rcdu->cmms[i] = pdev;
}
return 0;
}
+static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
+{
+ struct rcar_du_device *rcdu = to_rcar_du_device(dev);
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
+ platform_device_put(rcdu->cmms[i]);
+}
+
int rcar_du_modeset_init(struct rcar_du_device *rcdu)
{
static const unsigned int mmio_offsets[] = {
@@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
if (ret)
return ret;
+ ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
+ if (ret)
+ return ret;
+
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
dev->mode_config.normalize_zpos = true;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: use devm_add_action_or_reset() to handle failed condition
Hi Tian,
Thank you for the patch.
On Wed, Dec 16, 2020 at 08:22:32PM +0800, Tian Tao wrote:
> switch to using devm_add_action_or_reset() instead of devm_add_action to
> avoid call the cec_delete_adapter,when devm_add_action_or_reset return
> failed.
>
> Signed-off-by: Tian Tao
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> index 70ab4fb..c8f44bc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> @@ -265,11 +265,9 @@ static int dw_hdmi_cec_probe(struct platform_device
> *pdev)
> /* override the module pointer */
> cec->adap->owner = THIS_MODULE;
>
> - ret = devm_add_action(&pdev->dev, dw_hdmi_cec_del, cec);
> - if (ret) {
> - cec_delete_adapter(cec->adap);
> + ret = devm_add_action_or_reset(&pdev->dev, dw_hdmi_cec_del, cec);
> + if (ret)
> return ret;
> - }
>
> ret = devm_request_threaded_irq(&pdev->dev, cec->irq,
> dw_hdmi_cec_hardirq,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent,
On Wed, Dec 16, 2020 at 04:08:36PM +0200, Laurent Pinchart wrote:
> The device references acquired by of_find_device_by_node() are not
> released by the driver. Fix this by registering a cleanup action.
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Only set rcdu->cmms[] if the CMM config option is enabled
> - Use platform_device_put()
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 92dfa3d4c011..fdb8a0d127ad 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>* disabled: return 0 and let the DU continue probing.
>*/
> ret = rcar_cmm_init(pdev);
> - if (ret)
> + if (ret) {
> + platform_device_put(pdev);
> return ret == -ENODEV ? 0 : ret;
> + }
> +
> + rcdu->cmms[i] = pdev;
>
> /*
>* Enforce suspend/resume ordering by making the CMM a provider
Sorry but don't we have an error path here below too, and if it fails
-EINVAL is returned and the whole modeset_init() bails out without
having put the platform device.
> @@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> "Failed to create device link to CMM%u\n", i);
> return -EINVAL;
> }
> -
> - rcdu->cmms[i] = pdev;
> }
>
> return 0;
> }
>
> +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
> + platform_device_put(rcdu->cmms[i]);
> +}
> +
> int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> {
> static const unsigned int mmio_offsets[] = {
> @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> if (ret)
> return ret;
>
> + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> + if (ret)
> + return ret;
> +
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.normalize_zpos = true;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem
Am 16.12.20 um 14:48 schrieb Chen Li: On Wed, 16 Dec 2020 15:59:37 +0800, Christian König wrote: Am 16.12.20 um 06:41 schrieb Chen Li: When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon: [SNIP] Obviously, the __memset call is generated by gcc(8.3.1). It optimizes this for loop into memset. But this may break, because dest here is cpu_addr mapped to io mem. So, just invoke `memset_io` directly, which do solve the problem here. Well interesting problem you stumbled over here, but the solution is quite a hack. Hi, Christian. I'm not sure why this change is a hack here. I cannot see the problem and wll be grateful if you give more explainations. __memset is supposed to work on those addresses, otherwise you can't use the e8860 on your arm64 system. Replacing the the direct write in the kernel with calls to writel() or memset_io() will fix that temporary, but you have a more general problem here. For amdgpu I suggest that we allocate the UVD message in GTT instead of VRAM since we don't have the hardware restriction for that on the new generations. Thanks, I will try to dig into deeper. But what's the "hardware restriction" meaning here? I'm not familiar with video driver stack and amd gpu, sorry. On older hardware (AGP days) the buffer had to be in VRAM (MMIO) memory, but on modern system GTT (system memory) works as well. For radeon I think the better approach would be to convert the direct memory writes into calls to writel(). Ok, so you mean the more proper way is to use writel instead of memset_io? Well, it is a start. But I'm not sure if you will ever get that hardware working with this CPU. BTW: How does userspace work on arm64 then? The driver stack usually only works if mmio can be mapped directly. I also post two usespace issue on mesa, and you may be interested with them: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3954&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RDESyzYBB3ql2GgBigsYf%2Fx2g6zwCq%2Fy8HQ0AAMtX90%3D&reserved=0 https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3951&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y5f9Ki%2FQ8G4zn3MjLVG7yiLLCxbhTyNelZj36hAuXQY%3D&reserved=0 I paste some virtual memory map in userspace there. (and the two problems do bother me quite a long time.) I don't really see a solution for those problems. See it is perfectly valid for an application to memset/memcpy on mmaped MMIO space which comes from OpenGL or Vulkan. So your CPU simply won't work with the hardware. We could work around that with a couple of hacks, but this is a pretty much general problem. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On Wed, Dec 16, 2020 at 9:04 AM Christian König wrote: > > Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: > > [SNIP] > >>> > >>> While we can't control user application accesses to the mapped > >>> buffers explicitly and hence we use page fault rerouting > >>> I am thinking that in this case we may be able to sprinkle > >>> drm_dev_enter/exit in any such sensitive place were we might > >>> CPU access a DMA buffer from the kernel ? > >> > >> Yes, I fear we are going to need that. > >> > >>> Things like CPU page table updates, ring buffer accesses and FW > >>> memcpy ? Is there other places ? > >> > >> Puh, good question. I have no idea. > >> > >>> Another point is that at this point the driver shouldn't access any > >>> such buffers as we are at the process finishing the device. > >>> AFAIK there is no page fault mechanism for kernel mappings so I > >>> don't think there is anything else to do ? > >> > >> Well there is a page fault handler for kernel mappings, but that one > >> just prints the stack trace into the system log and calls BUG(); :) > >> > >> Long story short we need to avoid any access to released pages after > >> unplug. No matter if it's from the kernel or userspace. > > > > > > I was just about to start guarding with drm_dev_enter/exit CPU > > accesses from kernel to GTT ot VRAM buffers but then i looked more in > > the code > > and seems like ttm_tt_unpopulate just deletes DMA mappings (for the > > sake of device to main memory access). Kernel page table is not touched > > until last bo refcount is dropped and the bo is released > > (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This > > is both > > for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped > > by ioremap. So as i see it, nothing will bad will happen after we > > unpopulate a BO while we still try to use a kernel mapping for it, > > system memory pages backing GTT BOs are still mapped and not freed and > > for > > VRAM BOs same is for the IO physical ranges mapped into the kernel > > page table since iounmap wasn't called yet. > > The problem is the system pages would be freed and if we kernel driver > still happily write to them we are pretty much busted because we write > to freed up memory. Similar for vram, if this is actual hotunplug and then replug, there's going to be a different device behind the same mmio bar range most likely (the higher bridges all this have the same windows assigned), and that's bad news if we keep using it for current drivers. So we really have to point all these cpu ptes to some other place. -Daniel > > Christian. > > > I loaded the driver with vm_update_mode=3 > > meaning all VM updates done using CPU and hasn't seen any OOPs after > > removing the device. I guess i can test it more by allocating GTT and > > VRAM BOs > > and trying to read/write to them after device is removed. > > > > Andrey > > > > > >> > >> Regards, > >> Christian. > >> > >>> > >>> Andrey > >> > >> > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: zte: Remove unnecessary drm_plane_cleanup() wrapper
On Tue, Dec 15, 2020 at 09:37:55PM +0200, Laurent Pinchart wrote:
> Use the drm_plane_cleanup() function directly as the drm_plane_funcs
> .destroy() handler without creating an unnecessary wrapper around it.
>
> Signed-off-by: Laurent Pinchart
On the series:
Acked-by: Daniel Vetter
I'm assuming you'll apply this somewhere.
-Daniel
> ---
> drivers/gpu/drm/zte/zx_plane.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
> index c8f7b21fa09e..78d787afe594 100644
> --- a/drivers/gpu/drm/zte/zx_plane.c
> +++ b/drivers/gpu/drm/zte/zx_plane.c
> @@ -438,15 +438,10 @@ static const struct drm_plane_helper_funcs
> zx_gl_plane_helper_funcs = {
> .atomic_disable = zx_plane_atomic_disable,
> };
>
> -static void zx_plane_destroy(struct drm_plane *plane)
> -{
> - drm_plane_cleanup(plane);
> -}
> -
> static const struct drm_plane_funcs zx_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> - .destroy = zx_plane_destroy,
> + .destroy = drm_plane_cleanup,
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Don't export the drm_gem_dumb_destroy() function
On Tue, Dec 15, 2020 at 09:51:47PM +0200, Laurent Pinchart wrote:
> The drm_gem_dumb_destroy() isn't used in drivers, don't export it.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
Again I'm assuming you'll apply this somewhere.
-Daniel
> ---
> Changes since v1:
>
> - Move function prototype from drm_gem.h to drm_internal.h
> - Drop function documentation
> - Replace uint32_t with u32
> ---
> drivers/gpu/drm/drm_dumb_buffers.c | 8 +---
> drivers/gpu/drm/drm_gem.c | 12 +---
> drivers/gpu/drm/drm_internal.h | 3 +++
> include/drm/drm_gem.h | 3 ---
> 4 files changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index d18a740fe0f1..ad17fa21cebb 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -29,6 +29,7 @@
> #include
>
> #include "drm_crtc_internal.h"
> +#include "drm_internal.h"
>
> /**
> * DOC: overview
> @@ -46,9 +47,10 @@
> * KMS frame buffers.
> *
> * To support dumb objects drivers must implement the &drm_driver.dumb_create
> - * operation. &drm_driver.dumb_destroy defaults to drm_gem_dumb_destroy() if
> - * not set and &drm_driver.dumb_map_offset defaults to
> - * drm_gem_dumb_map_offset(). See the callbacks for further details.
> + * and &drm_driver.dumb_map_offset operations (the latter defaults to
> + * drm_gem_dumb_map_offset() if not set). Drivers that don't use GEM handles
> + * additionally need to implement the &drm_driver.dumb_destroy operation. See
> + * the callbacks for further details.
> *
> * Note that dumb objects may not be used for gpu acceleration, as has been
> * attempted on some ARM embedded platforms. Such drivers really must have
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 92f89cee213e..34b2f111c01c 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -335,22 +335,12 @@ int drm_gem_dumb_map_offset(struct drm_file *file,
> struct drm_device *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_dumb_map_offset);
>
> -/**
> - * drm_gem_dumb_destroy - dumb fb callback helper for gem based drivers
> - * @file: drm file-private structure to remove the dumb handle from
> - * @dev: corresponding drm_device
> - * @handle: the dumb handle to remove
> - *
> - * This implements the &drm_driver.dumb_destroy kms driver callback for
> drivers
> - * which use gem to manage their backing storage.
> - */
> int drm_gem_dumb_destroy(struct drm_file *file,
>struct drm_device *dev,
> - uint32_t handle)
> + u32 handle)
> {
> return drm_gem_handle_delete(file, handle);
> }
> -EXPORT_SYMBOL(drm_gem_dumb_destroy);
>
> /**
> * drm_gem_handle_create_tail - internal functions to create a handle
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 81d386b5b92a..fad2249ee67b 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -191,6 +191,9 @@ void drm_gem_unpin(struct drm_gem_object *obj);
> int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
> void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
>
> +int drm_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev,
> + u32 handle);
> +
> /* drm_debugfs.c drm_debugfs_crc.c */
> #if defined(CONFIG_DEBUG_FS)
> int drm_debugfs_init(struct drm_minor *minor, int minor_id,
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 5e6daa1c982f..240049566592 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -416,8 +416,5 @@ int drm_gem_fence_array_add_implicit(struct xarray
> *fence_array,
>bool write);
> int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
> u32 handle, u64 *offset);
> -int drm_gem_dumb_destroy(struct drm_file *file,
> - struct drm_device *dev,
> - uint32_t handle);
>
> #endif /* __DRM_GEM_H__ */
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
Hi Jacopo,
On Wed, Dec 16, 2020 at 03:16:28PM +0100, Jacopo Mondi wrote:
> On Wed, Dec 16, 2020 at 04:08:36PM +0200, Laurent Pinchart wrote:
> > The device references acquired by of_find_device_by_node() are not
> > released by the driver. Fix this by registering a cleanup action.
> >
> > Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Only set rcdu->cmms[] if the CMM config option is enabled
> > - Use platform_device_put()
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
> > 1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 92dfa3d4c011..fdb8a0d127ad 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > *rcdu)
> > * disabled: return 0 and let the DU continue probing.
> > */
> > ret = rcar_cmm_init(pdev);
> > - if (ret)
> > + if (ret) {
> > + platform_device_put(pdev);
> > return ret == -ENODEV ? 0 : ret;
> > + }
> > +
> > + rcdu->cmms[i] = pdev;
> >
> > /*
> > * Enforce suspend/resume ordering by making the CMM a provider
>
> Sorry but don't we have an error path here below too, and if it fails
> -EINVAL is returned and the whole modeset_init() bails out without
> having put the platform device.
There's an error path below, but in that case rcdu->cmms[i] will be set
and the cleanup action will take care of it.
> > @@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > *rcdu)
> > "Failed to create device link to CMM%u\n", i);
> > return -EINVAL;
> > }
> > -
> > - rcdu->cmms[i] = pdev;
> > }
> >
> > return 0;
> > }
> >
> > +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> > +{
> > + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
> > + platform_device_put(rcdu->cmms[i]);
> > +}
> > +
> > int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > {
> > static const unsigned int mmio_offsets[] = {
> > @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > if (ret)
> > return ret;
> >
> > + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> > + if (ret)
> > + return ret;
> > +
> > dev->mode_config.min_width = 0;
> > dev->mode_config.min_height = 0;
> > dev->mode_config.normalize_zpos = true;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: zte: Remove unnecessary drm_plane_cleanup() wrapper
Hi Daniel,
On Wed, Dec 16, 2020 at 03:22:59PM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2020 at 09:37:55PM +0200, Laurent Pinchart wrote:
> > Use the drm_plane_cleanup() function directly as the drm_plane_funcs
> > .destroy() handler without creating an unnecessary wrapper around it.
> >
> > Signed-off-by: Laurent Pinchart
>
> On the series:
>
> Acked-by: Daniel Vetter
>
> I'm assuming you'll apply this somewhere.
Yes, with the rest of my pending patches for v5.12 (I'm currently going
through my stale branches, cleaning up the bitrot and resubmitting as
appropriate), but if you want to push to drm-misc early, I won't mind
:-)
> > ---
> > drivers/gpu/drm/zte/zx_plane.c | 7 +--
> > 1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
> > index c8f7b21fa09e..78d787afe594 100644
> > --- a/drivers/gpu/drm/zte/zx_plane.c
> > +++ b/drivers/gpu/drm/zte/zx_plane.c
> > @@ -438,15 +438,10 @@ static const struct drm_plane_helper_funcs
> > zx_gl_plane_helper_funcs = {
> > .atomic_disable = zx_plane_atomic_disable,
> > };
> >
> > -static void zx_plane_destroy(struct drm_plane *plane)
> > -{
> > - drm_plane_cleanup(plane);
> > -}
> > -
> > static const struct drm_plane_funcs zx_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > - .destroy = zx_plane_destroy,
> > + .destroy = drm_plane_cleanup,
> > .reset = drm_atomic_helper_plane_reset,
> > .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Move legacy device list out of drm_driver
On Tue, Dec 15, 2020 at 10:31:24PM +0200, Laurent Pinchart wrote:
> The drm_driver structure contains a single field (legacy_dev_list) that
> is modified by the DRM core, used to store a linked list of legacy DRM
> devices associated with the driver. In order to make the structure
> const, move the field out to a global variable. This requires locking
> access to the global where the local field didn't require serialization,
> but this only affects legacy drivers, and isn't in any hot path.
>
> While at it, compile-out the legacy_dev_list field when DRM_LEGACY isn't
> defined.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Daniel Vetter
Hah, I didn't notice my review here, read it again, still looks good :-)
-Daniel
> Reviewed-by: Emil Velikov
> ---
> Changes since v1:
>
> - Move the legacy_dev_list to the end of struct drm_device, in the
> existing DRM_LEGACY section
> - Drop the kerneldoc comment for legacy_dev_list
> ---
> drivers/gpu/drm/drm_pci.c | 25 +
> include/drm/drm_device.h | 10 +++---
> include/drm/drm_drv.h | 2 --
> 3 files changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 6dba4b8ce4fe..dfb138aaccba 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -24,6 +24,8 @@
>
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -36,6 +38,9 @@
> #include "drm_legacy.h"
>
> #ifdef CONFIG_DRM_LEGACY
> +/* List of devices hanging off drivers with stealth attach. */
> +static LIST_HEAD(legacy_dev_list);
> +static DEFINE_MUTEX(legacy_dev_list_lock);
>
> /**
> * drm_pci_alloc - Allocate a PCI consistent memory block, for DMA.
> @@ -225,10 +230,11 @@ static int drm_get_pci_dev(struct pci_dev *pdev,
> if (ret)
> goto err_agp;
>
> - /* No locking needed since shadow-attach is single-threaded since it may
> - * only be called from the per-driver module init hook. */
> - if (drm_core_check_feature(dev, DRIVER_LEGACY))
> - list_add_tail(&dev->legacy_dev_list, &driver->legacy_dev_list);
> + if (drm_core_check_feature(dev, DRIVER_LEGACY)) {
> + mutex_lock(&legacy_dev_list_lock);
> + list_add_tail(&dev->legacy_dev_list, &legacy_dev_list);
> + mutex_unlock(&legacy_dev_list_lock);
> + }
>
> return 0;
>
> @@ -261,7 +267,6 @@ int drm_legacy_pci_init(struct drm_driver *driver, struct
> pci_driver *pdriver)
> return -EINVAL;
>
> /* If not using KMS, fall back to stealth mode manual scanning. */
> - INIT_LIST_HEAD(&driver->legacy_dev_list);
> for (i = 0; pdriver->id_table[i].vendor != 0; i++) {
> pid = &pdriver->id_table[i];
>
> @@ -304,11 +309,15 @@ void drm_legacy_pci_exit(struct drm_driver *driver,
> struct pci_driver *pdriver)
> if (!(driver->driver_features & DRIVER_LEGACY)) {
> WARN_ON(1);
> } else {
> - list_for_each_entry_safe(dev, tmp, &driver->legacy_dev_list,
> + mutex_lock(&legacy_dev_list_lock);
> + list_for_each_entry_safe(dev, tmp, &legacy_dev_list,
>legacy_dev_list) {
> - list_del(&dev->legacy_dev_list);
> - drm_put_dev(dev);
> + if (dev->driver == driver) {
> + list_del(&dev->legacy_dev_list);
> + drm_put_dev(dev);
> + }
> }
> + mutex_unlock(&legacy_dev_list_lock);
> }
> DRM_INFO("Module unloaded\n");
> }
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 283a93ce4617..bd5abe7cd48f 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -51,13 +51,6 @@ enum switch_power_state {
> * may contain multiple heads.
> */
> struct drm_device {
> - /**
> - * @legacy_dev_list:
> - *
> - * List of devices per driver for stealth attach cleanup
> - */
> - struct list_head legacy_dev_list;
> -
> /** @if_version: Highest interface version set */
> int if_version;
>
> @@ -336,6 +329,9 @@ struct drm_device {
> /* Everything below here is for legacy driver, never use! */
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> + /* List of devices per driver for stealth attach cleanup */
> + struct list_head legacy_dev_list;
> +
> /* Context handle management - linked list of context handles */
> struct list_head ctxlist;
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 02787319246a..827838e0a97e 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -499,8 +499,6 @@ struct drm_driver {
> /* Everything below here is for legacy driver, never use! */
> /* private: */
>
> - /* List of devices hanging off this driver with stealth attach
Re: [PATCH v2 2/3] drm: Use a const drm_driver for legacy PCI devices
On Tue, Dec 15, 2020 at 10:31:25PM +0200, Laurent Pinchart wrote:
> Now that the legacy PCI support code doesn't need to write to the
> drm_driver structure, it can be treated as const through the whole DRM
> core, unconditionally. This allows declaring the structure as const in
> all drivers, removing one possible attack vector.
>
> Signed-off-by: Laurent Pinchart
I didn't inquire the compiler whether you got all the combos right, but
looks complete.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 4
> drivers/gpu/drm/drm_pci.c | 8 +---
> include/drm/drm_device.h | 4
> include/drm/drm_legacy.h | 10 ++
> 4 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 734303802bc3..3f57e880685e 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -589,11 +589,7 @@ static int drm_dev_init(struct drm_device *dev,
>
> kref_init(&dev->ref);
> dev->dev = get_device(parent);
> -#ifdef CONFIG_DRM_LEGACY
> - dev->driver = (struct drm_driver *)driver;
> -#else
> dev->driver = driver;
> -#endif
>
> INIT_LIST_HEAD(&dev->managed.resources);
> spin_lock_init(&dev->managed.lock);
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index dfb138aaccba..5370e6b492fd 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -201,7 +201,7 @@ static void drm_pci_agp_init(struct drm_device *dev)
>
> static int drm_get_pci_dev(struct pci_dev *pdev,
> const struct pci_device_id *ent,
> -struct drm_driver *driver)
> +const struct drm_driver *driver)
> {
> struct drm_device *dev;
> int ret;
> @@ -255,7 +255,8 @@ static int drm_get_pci_dev(struct pci_dev *pdev,
> *
> * Return: 0 on success or a negative error code on failure.
> */
> -int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver
> *pdriver)
> +int drm_legacy_pci_init(const struct drm_driver *driver,
> + struct pci_driver *pdriver)
> {
> struct pci_dev *pdev = NULL;
> const struct pci_device_id *pid;
> @@ -300,7 +301,8 @@ EXPORT_SYMBOL(drm_legacy_pci_init);
> * Unregister a DRM driver shadow-attached through drm_legacy_pci_init().
> This
> * is deprecated and only used by dri1 drivers.
> */
> -void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver
> *pdriver)
> +void drm_legacy_pci_exit(const struct drm_driver *driver,
> + struct pci_driver *pdriver)
> {
> struct drm_device *dev, *tmp;
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index bd5abe7cd48f..939904ae88fc 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -76,11 +76,7 @@ struct drm_device {
> } managed;
>
> /** @driver: DRM driver managing the device */
> -#ifdef CONFIG_DRM_LEGACY
> - struct drm_driver *driver;
> -#else
> const struct drm_driver *driver;
> -#endif
>
> /**
>* @dev_private:
> diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> index 852d7451eeb1..8ed04e9be997 100644
> --- a/include/drm/drm_legacy.h
> +++ b/include/drm/drm_legacy.h
> @@ -198,8 +198,10 @@ struct drm_dma_handle *drm_pci_alloc(struct drm_device
> *dev, size_t size,
>size_t align);
> void drm_pci_free(struct drm_device *dev, struct drm_dma_handle *dmah);
>
> -int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver
> *pdriver);
> -void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver
> *pdriver);
> +int drm_legacy_pci_init(const struct drm_driver *driver,
> + struct pci_driver *pdriver);
> +void drm_legacy_pci_exit(const struct drm_driver *driver,
> + struct pci_driver *pdriver);
>
> #else
>
> @@ -214,13 +216,13 @@ static inline void drm_pci_free(struct drm_device *dev,
> {
> }
>
> -static inline int drm_legacy_pci_init(struct drm_driver *driver,
> +static inline int drm_legacy_pci_init(const struct drm_driver *driver,
> struct pci_driver *pdriver)
> {
> return -EINVAL;
> }
>
> -static inline void drm_legacy_pci_exit(struct drm_driver *driver,
> +static inline void drm_legacy_pci_exit(const struct drm_driver *driver,
> struct pci_driver *pdriver)
> {
> }
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm: Use a const drm_driver for legacy PCI devices
On Wed, Dec 16, 2020 at 03:29:00PM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2020 at 10:31:25PM +0200, Laurent Pinchart wrote:
> > Now that the legacy PCI support code doesn't need to write to the
> > drm_driver structure, it can be treated as const through the whole DRM
> > core, unconditionally. This allows declaring the structure as const in
> > all drivers, removing one possible attack vector.
> >
> > Signed-off-by: Laurent Pinchart
>
> I didn't inquire the compiler whether you got all the combos right, but
> looks complete.
I've compile-tested with CONFIG_DRM_LEGACY enabled and disabled, and
CONFIG_PCI enabled, so we should be good.
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/drm_drv.c | 4
> > drivers/gpu/drm/drm_pci.c | 8 +---
> > include/drm/drm_device.h | 4
> > include/drm/drm_legacy.h | 10 ++
> > 4 files changed, 11 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 734303802bc3..3f57e880685e 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -589,11 +589,7 @@ static int drm_dev_init(struct drm_device *dev,
> >
> > kref_init(&dev->ref);
> > dev->dev = get_device(parent);
> > -#ifdef CONFIG_DRM_LEGACY
> > - dev->driver = (struct drm_driver *)driver;
> > -#else
> > dev->driver = driver;
> > -#endif
> >
> > INIT_LIST_HEAD(&dev->managed.resources);
> > spin_lock_init(&dev->managed.lock);
> > diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> > index dfb138aaccba..5370e6b492fd 100644
> > --- a/drivers/gpu/drm/drm_pci.c
> > +++ b/drivers/gpu/drm/drm_pci.c
> > @@ -201,7 +201,7 @@ static void drm_pci_agp_init(struct drm_device *dev)
> >
> > static int drm_get_pci_dev(struct pci_dev *pdev,
> >const struct pci_device_id *ent,
> > - struct drm_driver *driver)
> > + const struct drm_driver *driver)
> > {
> > struct drm_device *dev;
> > int ret;
> > @@ -255,7 +255,8 @@ static int drm_get_pci_dev(struct pci_dev *pdev,
> > *
> > * Return: 0 on success or a negative error code on failure.
> > */
> > -int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver
> > *pdriver)
> > +int drm_legacy_pci_init(const struct drm_driver *driver,
> > + struct pci_driver *pdriver)
> > {
> > struct pci_dev *pdev = NULL;
> > const struct pci_device_id *pid;
> > @@ -300,7 +301,8 @@ EXPORT_SYMBOL(drm_legacy_pci_init);
> > * Unregister a DRM driver shadow-attached through drm_legacy_pci_init().
> > This
> > * is deprecated and only used by dri1 drivers.
> > */
> > -void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver
> > *pdriver)
> > +void drm_legacy_pci_exit(const struct drm_driver *driver,
> > +struct pci_driver *pdriver)
> > {
> > struct drm_device *dev, *tmp;
> >
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index bd5abe7cd48f..939904ae88fc 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -76,11 +76,7 @@ struct drm_device {
> > } managed;
> >
> > /** @driver: DRM driver managing the device */
> > -#ifdef CONFIG_DRM_LEGACY
> > - struct drm_driver *driver;
> > -#else
> > const struct drm_driver *driver;
> > -#endif
> >
> > /**
> > * @dev_private:
> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> > index 852d7451eeb1..8ed04e9be997 100644
> > --- a/include/drm/drm_legacy.h
> > +++ b/include/drm/drm_legacy.h
> > @@ -198,8 +198,10 @@ struct drm_dma_handle *drm_pci_alloc(struct drm_device
> > *dev, size_t size,
> > size_t align);
> > void drm_pci_free(struct drm_device *dev, struct drm_dma_handle *dmah);
> >
> > -int drm_legacy_pci_init(struct drm_driver *driver, struct pci_driver
> > *pdriver);
> > -void drm_legacy_pci_exit(struct drm_driver *driver, struct pci_driver
> > *pdriver);
> > +int drm_legacy_pci_init(const struct drm_driver *driver,
> > + struct pci_driver *pdriver);
> > +void drm_legacy_pci_exit(const struct drm_driver *driver,
> > +struct pci_driver *pdriver);
> >
> > #else
> >
> > @@ -214,13 +216,13 @@ static inline void drm_pci_free(struct drm_device
> > *dev,
> > {
> > }
> >
> > -static inline int drm_legacy_pci_init(struct drm_driver *driver,
> > +static inline int drm_legacy_pci_init(const struct drm_driver *driver,
> > struct pci_driver *pdriver)
> > {
> > return -EINVAL;
> > }
> >
> > -static inline void drm_legacy_pci_exit(struct drm_driver *driver,
> > +static inline void drm_legacy_pci_exit(const struct drm_driver *driver,
> >struct pci_driver *pdriver)
> > {
> > }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri
Re: [PATCH v2 3/3] drm: Constify drm_driver in drivers that don't modify it
On Tue, Dec 15, 2020 at 10:31:26PM +0200, Laurent Pinchart wrote:
> A non-const structure containing function pointers is a possible attack
> vector. The drm_driver structure is already const in most drivers, but
> there are a few exceptions. Constify the structure in the drivers that
> don't need to modify at, as a low-hanging fruit. The rest of the drivers
> will need a more complex fix.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
> drivers/gpu/drm/kmb/kmb_drv.c| 2 +-
> drivers/gpu/drm/tdfx/tdfx_drv.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index f164818ec477..077d006b1fbf 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -145,7 +145,7 @@ static void arcpgu_debugfs_init(struct drm_minor *minor)
> }
> #endif
>
> -static struct drm_driver arcpgu_drm_driver = {
> +static const struct drm_driver arcpgu_drm_driver = {
> .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
> .name = "arcpgu",
> .desc = "ARC PGU Controller",
> diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
> index a31a840ce634..3c49668ec946 100644
> --- a/drivers/gpu/drm/kmb/kmb_drv.c
> +++ b/drivers/gpu/drm/kmb/kmb_drv.c
> @@ -400,7 +400,7 @@ static void kmb_irq_reset(struct drm_device *drm)
>
> DEFINE_DRM_GEM_CMA_FOPS(fops);
>
> -static struct drm_driver kmb_driver = {
> +static const struct drm_driver kmb_driver = {
> .driver_features = DRIVER_GEM |
> DRIVER_MODESET | DRIVER_ATOMIC,
> .irq_handler = kmb_isr,
> diff --git a/drivers/gpu/drm/tdfx/tdfx_drv.c b/drivers/gpu/drm/tdfx/tdfx_drv.c
> index ab699bf0ac5c..58c185c299f4 100644
> --- a/drivers/gpu/drm/tdfx/tdfx_drv.c
> +++ b/drivers/gpu/drm/tdfx/tdfx_drv.c
> @@ -56,7 +56,7 @@ static const struct file_operations tdfx_driver_fops = {
> .llseek = noop_llseek,
> };
>
> -static struct drm_driver driver = {
> +static const struct drm_driver driver = {
> .driver_features = DRIVER_LEGACY,
> .fops = &tdfx_driver_fops,
> .name = DRIVER_NAME,
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent
On Wed, Dec 16, 2020 at 04:24:11PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Dec 16, 2020 at 03:16:28PM +0100, Jacopo Mondi wrote:
> > On Wed, Dec 16, 2020 at 04:08:36PM +0200, Laurent Pinchart wrote:
> > > The device references acquired by of_find_device_by_node() are not
> > > released by the driver. Fix this by registering a cleanup action.
> > >
> > > Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > Changes since v1:
> > >
> > > - Only set rcdu->cmms[] if the CMM config option is enabled
> > > - Use platform_device_put()
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
> > > 1 file changed, 19 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 92dfa3d4c011..fdb8a0d127ad 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -14,6 +14,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > > *rcdu)
> > >* disabled: return 0 and let the DU continue probing.
> > >*/
> > > ret = rcar_cmm_init(pdev);
> > > - if (ret)
> > > + if (ret) {
> > > + platform_device_put(pdev);
> > > return ret == -ENODEV ? 0 : ret;
> > > + }
> > > +
> > > + rcdu->cmms[i] = pdev;
> > >
> > > /*
> > >* Enforce suspend/resume ordering by making the CMM a provider
> >
> > Sorry but don't we have an error path here below too, and if it fails
> > -EINVAL is returned and the whole modeset_init() bails out without
> > having put the platform device.
>
> There's an error path below, but in that case rcdu->cmms[i] will be set
> and the cleanup action will take care of it.
>
Right, the helper is registered before the init() function eventually
bails out. Sorry for being unnecessarily picky.
Reviewed-by: Jacopo Mondi
Thanks
j
> > > @@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > > *rcdu)
> > > "Failed to create device link to CMM%u\n", i);
> > > return -EINVAL;
> > > }
> > > -
> > > - rcdu->cmms[i] = pdev;
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> > > +{
> > > + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
> > > + platform_device_put(rcdu->cmms[i]);
> > > +}
> > > +
> > > int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > > {
> > > static const unsigned int mmio_offsets[] = {
> > > @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > > if (ret)
> > > return ret;
> > >
> > > + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > dev->mode_config.min_width = 0;
> > > dev->mode_config.min_height = 0;
> > > dev->mode_config.normalize_zpos = true;
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/10] drm: uapi: Use SPDX in DRM core uAPI headers
On Wed, Dec 16, 2020 at 04:43:50AM +0200, Laurent Pinchart wrote: > The DRM core uAPI headers are licensed under the MIT license, and carry > copies of the license with slight variations. Replace them with SPDX > headers. > > Following a discussion with Daniel Vetter on this topic, add a > clarification in the drm-uapi.rst file that independent closed-source > userspace implementations of software using the DRM uAPI are accepted, > as allowed by the MIT license. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Thomas Gleixner > Reviewed-by: Daniel Vetter Maybe get and ack from Alex and Dave on this too, just to make sure everyone's happy. -Daniel > --- > Documentation/gpu/drm-uapi.rst | 4 > include/uapi/drm/drm.h | 20 +--- > include/uapi/drm/drm_fourcc.h | 20 +--- > include/uapi/drm/drm_mode.h| 19 +-- > include/uapi/drm/drm_sarea.h | 20 +--- > 5 files changed, 8 insertions(+), 75 deletions(-) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 7dce175f6d75..96ea55200f04 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -109,6 +109,10 @@ is already rather painful for the DRM subsystem, with > multiple different uAPIs > for the same thing co-existing. If we add a few more complete mistakes into > the > mix every year it would be entirely unmanageable. > > +The DRM subsystem has however no concern with independent closed-source > +userspace implementations. To officialize that position, the DRM uAPI headers > +are covered by the MIT license. > + > .. _drm_render_node: > > Render nodes > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > index 808b48a93330..14d57361e580 100644 > --- a/include/uapi/drm/drm.h > +++ b/include/uapi/drm/drm.h > @@ -1,3 +1,4 @@ > +/* SPDX-License-Identifier: MIT */ > /** > * \file drm.h > * Header for the Direct Rendering Manager > @@ -12,25 +13,6 @@ > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > * All rights reserved. > - * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the "Software"), > - * to deal in the Software without restriction, including without limitation > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > - * and/or sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following conditions: > - * > - * The above copyright notice and this permission notice (including the next > - * paragraph) shall be included in all copies or substantial portions of the > - * Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > */ > > #ifndef _DRM_H_ > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 723c8e23ca87..51e2c8a825a3 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -1,24 +1,6 @@ > +/* SPDX-License-Identifier: MIT */ > /* > * Copyright 2011 Intel Corporation > - * > - * Permission is hereby granted, free of charge, to any person obtaining a > - * copy of this software and associated documentation files (the "Software"), > - * to deal in the Software without restriction, including without limitation > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > - * and/or sell copies of the Software, and to permit persons to whom the > - * Software is furnished to do so, subject to the following conditions: > - * > - * The above copyright notice and this permission notice (including the next > - * paragraph) shall be included in all copies or substantial portions of the > - * Software. > - * > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > - * OTHER DEALINGS IN THE SOFTWARE. > */ > > #ifndef DRM_FOURCC_H > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index b49fbf2
Re: [PATCH] MAINTAINERS: Update addresses for TI display drivers
On Wed, Dec 16, 2020 at 09:59:17AM +0200, Tomi Valkeinen wrote: > Update the maintainer email addresses for TI display drivers. > > Signed-off-by: Tomi Valkeinen Acked-by: Daniel Vetter > --- > MAINTAINERS | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 281de213ef47..c21471497a18 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5932,8 +5932,8 @@ F: > Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml > F: drivers/gpu/drm/stm > > DRM DRIVERS FOR TI KEYSTONE > -M: Jyri Sarha > -M: Tomi Valkeinen > +M: Jyri Sarha > +M: Tomi Valkeinen > L: dri-devel@lists.freedesktop.org > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > @@ -5943,15 +5943,15 @@ F: > Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml > F: drivers/gpu/drm/tidss/ > > DRM DRIVERS FOR TI LCDC > -M: Jyri Sarha > -R: Tomi Valkeinen > +M: Jyri Sarha > +R: Tomi Valkeinen > L: dri-devel@lists.freedesktop.org > S: Maintained > F: Documentation/devicetree/bindings/display/tilcdc/ > F: drivers/gpu/drm/tilcdc/ > > DRM DRIVERS FOR TI OMAP > -M: Tomi Valkeinen > +M: Tomi Valkeinen > L: dri-devel@lists.freedesktop.org > S: Maintained > F: Documentation/devicetree/bindings/display/ti/ > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] backlight: sky81452-backlight: convert comma to semicolon
On Mon, 14 Dec 2020, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun > --- > drivers/video/backlight/sky81452-backlight.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Wed, Dec 16, 2020 at 03:49:24PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> > > + if (lvds->panel) {
> > > + lvds->next_bridge = devm_drm_panel_bridge_add(lvds->dev,
> > > + lvds->panel);
> >
> > Reading the devm_drm_panel_bridge_add() function documentation:
> >
> > * devm_drm_panel_bridge_add - Creates a managed &drm_bridge and
> > &drm_connector
> >
> > Doesn't this conflict with the drm_bridge_connector_init() called by
> > the encoder in [4/4] ?
>
> It would, if the documentation was right :-) The function only creates a
> bridge. A connector will only be created when the bridge is attached
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Well, reading it again, it is kind of implied that if NO_CONNECTOR is
given to the bridge, no connector will be registered at all.
>
> Would you like to send a patch to fix the documentation ?
>
> > > + if (IS_ERR_OR_NULL(lvds->next_bridge)) {
> > > + ret = -EINVAL;
> > > + goto done;
> > > + }
> > > + }
> > > +
> > > if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
> > > ret = rcar_lvds_parse_dt_companion(lvds);
> > >
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
[AMD Public Use] > -Original Message- > From: Laurent Pinchart > Sent: Tuesday, December 15, 2020 9:15 PM > To: Koenig, Christian > Cc: Daniel Vetter ; Laurent Pinchart > ; dri- > de...@lists.freedesktop.org; Dave Airlie ; Greg Kroah- > Hartman ; Thomas Gleixner > ; Deucher, Alexander ; > Rob Clark ; Sean Paul ; Ben > Skeggs ; Gerd Hoffmann ; > Thierry Reding ; Eric Anholt ; > VMware Graphics ; Thomas > Hellstrom > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > Hi Christian, > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > Most of the DRM drivers uAPI headers are licensed under the MIT > > license, and carry copies of the license with slight variations. > > Replace them with SPDX headers. > > >>> My personal opinion is that this is a really good idea, but my > > >>> professional is that we need the acknowledgment from our legal > department for this. > > >> I think official ack from amd on first patch, especially the .rst > > >> snippet, would be really good indeed. > > > Any update on this one ? > > > > Sorry totally forgot to forward this because I was waiting for split > > up patches. > > > > Going to do so right now. > > Has there been any update ? :-) AMD legal requires the full license. Alex > > > >>> Please separate that change into one for each > driver/company/maintainer. > > >>> Amdgpu, radeon, r128 can be one for example. > > > > > > I'll do so. > > > > > >> You can leave all the other legacy drivers in one patch (mga, > > >> savage, sis, via), since there's likely no one around anymore and > > >> will just boil down to drm maintainer ack from Dave&me. > > >> > > Signed-off-by: Laurent Pinchart > > > > --- > > include/uapi/drm/amdgpu_drm.h | 19 +-- > > include/uapi/drm/i915_drm.h| 22 +- > > include/uapi/drm/mga_drm.h | 20 +--- > > include/uapi/drm/msm_drm.h | 20 +--- > > include/uapi/drm/nouveau_drm.h | 20 +--- > > include/uapi/drm/qxl_drm.h | 20 +--- > > include/uapi/drm/r128_drm.h| 20 +--- > > include/uapi/drm/radeon_drm.h | 20 +--- > > include/uapi/drm/savage_drm.h | 20 +--- > > include/uapi/drm/sis_drm.h | 21 + > > include/uapi/drm/tegra_drm.h | 19 +-- > > include/uapi/drm/v3d_drm.h | 20 +--- > > include/uapi/drm/vc4_drm.h | 20 +--- > > include/uapi/drm/vgem_drm.h| 22 +- > > include/uapi/drm/via_drm.h | 20 +--- > > include/uapi/drm/virtgpu_drm.h | 20 +--- > > include/uapi/drm/vmwgfx_drm.h | 21 + > > 17 files changed, 17 insertions(+), 327 deletions(-) > > > > diff --git a/include/uapi/drm/amdgpu_drm.h > > b/include/uapi/drm/amdgpu_drm.h index > 4e873dcbe68f..c6adda72bec7 > > 100644 > > --- a/include/uapi/drm/amdgpu_drm.h > > +++ b/include/uapi/drm/amdgpu_drm.h > > @@ -1,3 +1,4 @@ > > +/* SPDX-License-Identifier: MIT */ > > /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c > -*- > > * > > * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > > @@ -5,24 +6,6 @@ > > * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > > * Copyright 2014 Advanced Micro Devices, Inc. > > * > > - * Permission is hereby granted, free of charge, to any person > > obtaining a > > - * copy of this software and associated documentation files (the > > "Software"), > > - * to deal in the Software without restriction, including > > without limitation > > - * the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > - * and/or sell copies of the Software, and to permit persons to > > whom the > > - * Software is furnished to do so, subject to the following > > conditions: > > - * > > - * The above copyright notice and this permission notice shall > > be included in > > - * all copies or substantial portions of the Software. > > - * > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF > ANY > > KIND, EXPRESS OR > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > MERCHANTABILITY, > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. > IN NO > > EVENT SHALL > > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LI
Re: [PATCH v2 01/10] drm: uapi: Use SPDX in DRM core uAPI headers
Hi Daniel, On Wed, Dec 16, 2020 at 03:34:35PM +0100, Daniel Vetter wrote: > On Wed, Dec 16, 2020 at 04:43:50AM +0200, Laurent Pinchart wrote: > > The DRM core uAPI headers are licensed under the MIT license, and carry > > copies of the license with slight variations. Replace them with SPDX > > headers. > > > > Following a discussion with Daniel Vetter on this topic, add a > > clarification in the drm-uapi.rst file that independent closed-source > > userspace implementations of software using the DRM uAPI are accepted, > > as allowed by the MIT license. > > > > Signed-off-by: Laurent Pinchart > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Thomas Gleixner > > Reviewed-by: Daniel Vetter > > Maybe get and ack from Alex and Dave on this too, just to make sure > everyone's happy. CC'ing Dave. Which Alex are you talking about ? > > --- > > Documentation/gpu/drm-uapi.rst | 4 > > include/uapi/drm/drm.h | 20 +--- > > include/uapi/drm/drm_fourcc.h | 20 +--- > > include/uapi/drm/drm_mode.h| 19 +-- > > include/uapi/drm/drm_sarea.h | 20 +--- > > 5 files changed, 8 insertions(+), 75 deletions(-) > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > > index 7dce175f6d75..96ea55200f04 100644 > > --- a/Documentation/gpu/drm-uapi.rst > > +++ b/Documentation/gpu/drm-uapi.rst > > @@ -109,6 +109,10 @@ is already rather painful for the DRM subsystem, with > > multiple different uAPIs > > for the same thing co-existing. If we add a few more complete mistakes > > into the > > mix every year it would be entirely unmanageable. > > > > +The DRM subsystem has however no concern with independent closed-source > > +userspace implementations. To officialize that position, the DRM uAPI > > headers > > +are covered by the MIT license. > > + > > .. _drm_render_node: > > > > Render nodes > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > index 808b48a93330..14d57361e580 100644 > > --- a/include/uapi/drm/drm.h > > +++ b/include/uapi/drm/drm.h > > @@ -1,3 +1,4 @@ > > +/* SPDX-License-Identifier: MIT */ > > /** > > * \file drm.h > > * Header for the Direct Rendering Manager > > @@ -12,25 +13,6 @@ > > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > > * All rights reserved. > > - * > > - * Permission is hereby granted, free of charge, to any person obtaining a > > - * copy of this software and associated documentation files (the > > "Software"), > > - * to deal in the Software without restriction, including without > > limitation > > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > - * and/or sell copies of the Software, and to permit persons to whom the > > - * Software is furnished to do so, subject to the following conditions: > > - * > > - * The above copyright notice and this permission notice (including the > > next > > - * paragraph) shall be included in all copies or substantial portions of > > the > > - * Software. > > - * > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES > > OR > > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > - * OTHER DEALINGS IN THE SOFTWARE. > > */ > > > > #ifndef _DRM_H_ > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > > index 723c8e23ca87..51e2c8a825a3 100644 > > --- a/include/uapi/drm/drm_fourcc.h > > +++ b/include/uapi/drm/drm_fourcc.h > > @@ -1,24 +1,6 @@ > > +/* SPDX-License-Identifier: MIT */ > > /* > > * Copyright 2011 Intel Corporation > > - * > > - * Permission is hereby granted, free of charge, to any person obtaining a > > - * copy of this software and associated documentation files (the > > "Software"), > > - * to deal in the Software without restriction, including without > > limitation > > - * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > - * and/or sell copies of the Software, and to permit persons to whom the > > - * Software is furnished to do so, subject to the following conditions: > > - * > > - * The above copyright notice and this permission notice (including the > > next > > - * paragraph) shall be included in all copies or substantial portions of > > the > > - * Software. > > - * > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > - * VA LINUX
Re: [PATCH 1/2] drm/ttm: rework ttm_tt page limit v2
On Wed, Dec 16, 2020 at 03:04:26PM +0100, Christian König wrote:
> TTM implements a rather extensive accounting of allocated memory.
>
> There are two reasons for this:
> 1. It tries to block userspace allocating a huge number of very small
>BOs without accounting for the kmalloced memory.
>
> 2. Make sure we don't over allocate and run into an OOM situation
>during swapout while trying to handle the memory shortage.
>
> This is only partially a good idea. First of all it is perfectly
> valid for an application to use all of system memory, limiting it to
> 50% is not really acceptable.
>
> What we need to take care of is that the application is held
> accountable for the memory it allocated. This is what control
> mechanisms like memcg and the normal Linux page accounting already do.
>
> Making sure that we don't run into an OOM situation while trying to
> cope with a memory shortage is still a good idea, but this is also
> not very well implemented since it means another opportunity of
> recursion from the driver back into TTM.
>
> So start to rework all of this by implementing a shrinker callback which
> allows for TT object to be swapped out if necessary.
>
> v2: Switch from limit to shrinker callback.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 4 +-
> drivers/gpu/drm/ttm/ttm_memory.c| 7 ++-
> drivers/gpu/drm/ttm/ttm_tt.c| 82 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/ttm/ttm_bo_api.h| 2 +-
> include/drm/ttm/ttm_tt.h| 6 ++-
> 6 files changed, 91 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 31e8b3da5563..f1f3fd085465 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1412,7 +1412,7 @@ EXPORT_SYMBOL(ttm_bo_wait);
> * A buffer object shrink method that tries to swap out the first
> * buffer object on the bo_global::swap_lru list.
> */
> -int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
> +int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
> {
> struct ttm_bo_global *glob = &ttm_bo_glob;
> struct ttm_buffer_object *bo;
> @@ -1495,7 +1495,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
> if (bo->bdev->driver->swap_notify)
> bo->bdev->driver->swap_notify(bo);
>
> - ret = ttm_tt_swapout(bo->bdev, bo->ttm);
> + ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
> out:
>
> /**
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index a3bfbd9cea68..3d2479d0ce2c 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ttm_module.h"
>
> @@ -276,9 +277,9 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
> from_wq,
>
> while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
> spin_unlock(&glob->lock);
> - ret = ttm_bo_swapout(ctx);
> + ret = ttm_bo_swapout(ctx, 0);
General we don't treat gfp_mask as a set of additional flags, but the full
thing. So here we should have GFP_KERNEL.
Also having both the shrinker and the ttm_shrink_work is a bit much, the
shrink work should get deleted completely I think.
> spin_lock(&glob->lock);
> - if (unlikely(ret != 0))
> + if (unlikely(ret < 0))
> break;
> }
>
> @@ -453,6 +454,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
> zone->name, (unsigned long long)zone->max_mem >> 10);
> }
> ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
> + ttm_tt_mgr_init();
> return 0;
> out_no_zone:
> ttm_mem_global_release(glob);
> @@ -466,6 +468,7 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
>
> /* let the page allocator first stop the shrink work. */
> ttm_pool_mgr_fini();
> + ttm_tt_mgr_fini();
>
> flush_workqueue(glob->swap_queue);
> destroy_workqueue(glob->swap_queue);
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 7f75a13163f0..d454c428c56a 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -38,6 +38,8 @@
> #include
> #include
>
> +static struct shrinker mm_shrinker;
> +
> /*
> * Allocates a ttm structure for the given BO.
> */
> @@ -223,13 +225,23 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
> return ret;
> }
>
> -int ttm_tt_swapout(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
> +/**
> + * ttm_tt_swapout - swap out tt object
> + *
> + * @bdev: TTM device structure.
> + * @ttm: The struct ttm_tt.
> + * @gfp_flags: Flags to use for memory allocation.
> + *
> + * Swapout a TT object to a shmem_file, return number of pages swapped out or
> + * negative error code.
> + */
> +i
Re: [PATCH v2, 10/17] drm/mediatek: fix aal size config
Hi, Yongqiang:
Yongqiang Niu 於 2020年12月12日 週六 下午12:22寫道：
>
> fix aal size config
>
> Fixes: 0664d1392c26 (drm/mediatek: Add AAL engine basic function)
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index be61d11..e7d481e0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -33,8 +33,13 @@
> #define DISP_REG_UFO_START 0x
>
> #define DISP_AAL_EN0x
> +#define DISP_AAL_CFG 0x0020
> +#define AAL_RELAY_MODE BIT(0)
> +#define AAL_ENGINE_EN BIT(1)
> #define DISP_AAL_SIZE 0x0030
>
> +#define DISP_AAL_OUTPUT_SIZE 0x04d8
> +
> #define DISP_CCORR_EN 0x
> #define CCORR_EN BIT(0)
> #define DISP_CCORR_CFG 0x0020
> @@ -184,7 +189,11 @@ static void mtk_aal_config(struct mtk_ddp_comp *comp,
> unsigned int w,
>unsigned int h, unsigned int vrefresh,
>unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> {
> - mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_AAL_SIZE);
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_SIZE);
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_OUTPUT_SIZE);
> +
> + mtk_ddp_write_mask(NULL, AAL_RELAY_MODE, comp, DISP_AAL_CFG,
cmdq_pkt
> + AAL_RELAY_MODE | AAL_ENGINE_EN);
This patch is to fix size config, so move this statement to another patch.
Regards,
Chun-Kuang.
> }
>
> static void mtk_aal_start(struct mtk_ddp_comp *comp)
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/10] drm: uapi: Use SPDX in DRM core uAPI headers
On Wed, Dec 16, 2020 at 05:03:25PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wed, Dec 16, 2020 at 03:34:35PM +0100, Daniel Vetter wrote: > > On Wed, Dec 16, 2020 at 04:43:50AM +0200, Laurent Pinchart wrote: > > > The DRM core uAPI headers are licensed under the MIT license, and carry > > > copies of the license with slight variations. Replace them with SPDX > > > headers. > > > > > > Following a discussion with Daniel Vetter on this topic, add a > > > clarification in the drm-uapi.rst file that independent closed-source > > > userspace implementations of software using the DRM uAPI are accepted, > > > as allowed by the MIT license. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > Reviewed-by: Greg Kroah-Hartman > > > Reviewed-by: Thomas Gleixner > > > Reviewed-by: Daniel Vetter > > > > Maybe get and ack from Alex and Dave on this too, just to make sure > > everyone's happy. > > CC'ing Dave. Which Alex are you talking about ? The amd one, they're one of the big ones having closed userspace running on top of the upstream drm/amdgpu driver. cc'ed. -Daniel > > > > --- > > > Documentation/gpu/drm-uapi.rst | 4 > > > include/uapi/drm/drm.h | 20 +--- > > > include/uapi/drm/drm_fourcc.h | 20 +--- > > > include/uapi/drm/drm_mode.h| 19 +-- > > > include/uapi/drm/drm_sarea.h | 20 +--- > > > 5 files changed, 8 insertions(+), 75 deletions(-) > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > b/Documentation/gpu/drm-uapi.rst > > > index 7dce175f6d75..96ea55200f04 100644 > > > --- a/Documentation/gpu/drm-uapi.rst > > > +++ b/Documentation/gpu/drm-uapi.rst > > > @@ -109,6 +109,10 @@ is already rather painful for the DRM subsystem, > > > with multiple different uAPIs > > > for the same thing co-existing. If we add a few more complete mistakes > > > into the > > > mix every year it would be entirely unmanageable. > > > > > > +The DRM subsystem has however no concern with independent closed-source > > > +userspace implementations. To officialize that position, the DRM uAPI > > > headers > > > +are covered by the MIT license. > > > + > > > .. _drm_render_node: > > > > > > Render nodes > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > > index 808b48a93330..14d57361e580 100644 > > > --- a/include/uapi/drm/drm.h > > > +++ b/include/uapi/drm/drm.h > > > @@ -1,3 +1,4 @@ > > > +/* SPDX-License-Identifier: MIT */ > > > /** > > > * \file drm.h > > > * Header for the Direct Rendering Manager > > > @@ -12,25 +13,6 @@ > > > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > > > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > > > * All rights reserved. > > > - * > > > - * Permission is hereby granted, free of charge, to any person obtaining > > > a > > > - * copy of this software and associated documentation files (the > > > "Software"), > > > - * to deal in the Software without restriction, including without > > > limitation > > > - * the rights to use, copy, modify, merge, publish, distribute, > > > sublicense, > > > - * and/or sell copies of the Software, and to permit persons to whom the > > > - * Software is furnished to do so, subject to the following conditions: > > > - * > > > - * The above copyright notice and this permission notice (including the > > > next > > > - * paragraph) shall be included in all copies or substantial portions of > > > the > > > - * Software. > > > - * > > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > > EXPRESS OR > > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > > MERCHANTABILITY, > > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > > SHALL > > > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, > > > DAMAGES OR > > > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > > - * OTHER DEALINGS IN THE SOFTWARE. > > > */ > > > > > > #ifndef _DRM_H_ > > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > > > index 723c8e23ca87..51e2c8a825a3 100644 > > > --- a/include/uapi/drm/drm_fourcc.h > > > +++ b/include/uapi/drm/drm_fourcc.h > > > @@ -1,24 +1,6 @@ > > > +/* SPDX-License-Identifier: MIT */ > > > /* > > > * Copyright 2011 Intel Corporation > > > - * > > > - * Permission is hereby granted, free of charge, to any person obtaining > > > a > > > - * copy of this software and associated documentation files (the > > > "Software"), > > > - * to deal in the Software without restriction, including without > > > limitation > > > - * the rights to use, copy, modify, merge, publish, distribute, > > > sublicense, > > > - * and/or sell copies of the Software, and to permit persons to whom the > > > - * Software is furnished to do so, subject to the following conditions: > > > -
Re: [PATCH v2 01/10] drm: uapi: Use SPDX in DRM core uAPI headers
On Wed, Dec 16, 2020 at 04:12:14PM +0100, Daniel Vetter wrote: > On Wed, Dec 16, 2020 at 05:03:25PM +0200, Laurent Pinchart wrote: > > On Wed, Dec 16, 2020 at 03:34:35PM +0100, Daniel Vetter wrote: > > > On Wed, Dec 16, 2020 at 04:43:50AM +0200, Laurent Pinchart wrote: > > > > The DRM core uAPI headers are licensed under the MIT license, and carry > > > > copies of the license with slight variations. Replace them with SPDX > > > > headers. > > > > > > > > Following a discussion with Daniel Vetter on this topic, add a > > > > clarification in the drm-uapi.rst file that independent closed-source > > > > userspace implementations of software using the DRM uAPI are accepted, > > > > as allowed by the MIT license. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > > Reviewed-by: Greg Kroah-Hartman > > > > Reviewed-by: Thomas Gleixner > > > > Reviewed-by: Daniel Vetter > > > > > > Maybe get and ack from Alex and Dave on this too, just to make sure > > > everyone's happy. > > > > CC'ing Dave. Which Alex are you talking about ? > > The amd one, they're one of the big ones having closed userspace running > on top of the upstream drm/amdgpu driver. cc'ed. AMD legal seems to have nack'ed the previous version. I'll drop the AMD driver change (02/20) from v2, but I want to keep 01/10. > > > > --- > > > > Documentation/gpu/drm-uapi.rst | 4 > > > > include/uapi/drm/drm.h | 20 +--- > > > > include/uapi/drm/drm_fourcc.h | 20 +--- > > > > include/uapi/drm/drm_mode.h| 19 +-- > > > > include/uapi/drm/drm_sarea.h | 20 +--- > > > > 5 files changed, 8 insertions(+), 75 deletions(-) > > > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > > b/Documentation/gpu/drm-uapi.rst > > > > index 7dce175f6d75..96ea55200f04 100644 > > > > --- a/Documentation/gpu/drm-uapi.rst > > > > +++ b/Documentation/gpu/drm-uapi.rst > > > > @@ -109,6 +109,10 @@ is already rather painful for the DRM subsystem, > > > > with multiple different uAPIs > > > > for the same thing co-existing. If we add a few more complete mistakes > > > > into the > > > > mix every year it would be entirely unmanageable. > > > > > > > > +The DRM subsystem has however no concern with independent closed-source > > > > +userspace implementations. To officialize that position, the DRM uAPI > > > > headers > > > > +are covered by the MIT license. > > > > + > > > > .. _drm_render_node: > > > > > > > > Render nodes > > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > > > index 808b48a93330..14d57361e580 100644 > > > > --- a/include/uapi/drm/drm.h > > > > +++ b/include/uapi/drm/drm.h > > > > @@ -1,3 +1,4 @@ > > > > +/* SPDX-License-Identifier: MIT */ > > > > /** > > > > * \file drm.h > > > > * Header for the Direct Rendering Manager > > > > @@ -12,25 +13,6 @@ > > > > * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. > > > > * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. > > > > * All rights reserved. > > > > - * > > > > - * Permission is hereby granted, free of charge, to any person > > > > obtaining a > > > > - * copy of this software and associated documentation files (the > > > > "Software"), > > > > - * to deal in the Software without restriction, including without > > > > limitation > > > > - * the rights to use, copy, modify, merge, publish, distribute, > > > > sublicense, > > > > - * and/or sell copies of the Software, and to permit persons to whom > > > > the > > > > - * Software is furnished to do so, subject to the following conditions: > > > > - * > > > > - * The above copyright notice and this permission notice (including > > > > the next > > > > - * paragraph) shall be included in all copies or substantial portions > > > > of the > > > > - * Software. > > > > - * > > > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > > > EXPRESS OR > > > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > > > MERCHANTABILITY, > > > > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > > > SHALL > > > > - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, > > > > DAMAGES OR > > > > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR > > > > OTHERWISE, > > > > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE > > > > OR > > > > - * OTHER DEALINGS IN THE SOFTWARE. > > > > */ > > > > > > > > #ifndef _DRM_H_ > > > > diff --git a/include/uapi/drm/drm_fourcc.h > > > > b/include/uapi/drm/drm_fourcc.h > > > > index 723c8e23ca87..51e2c8a825a3 100644 > > > > --- a/include/uapi/drm/drm_fourcc.h > > > > +++ b/include/uapi/drm/drm_fourcc.h > > > > @@ -1,24 +1,6 @@ > > > > +/* SPDX-License-Identifier: MIT */ > > > > /* > > > > * Copyright 2011 Intel Corporation > > > > - * > > > > - * Permission is hereby granted, free of charge, to any person > > > > obtaining a > > > > - * copy of t
Re: [PATCH v2, 02/17] dt-bindings: mediatek: add CLK_MM_DISP_CONFIG control description for mt8192 display
Hi, Yongqiang: Yongqiang Niu 於 2020年12月12日 週六 下午12:12寫道： > > add CLK_MM_DISP_CONFIG control description for mt8192 displa display > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index 1972fa7..dfbec76 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -54,6 +54,9 @@ Required properties (all function blocks): >DPI controller nodes have multiple clock inputs. These are documented in >mediatek,dsi.txt and mediatek,dpi.txt, respectively. >An exception is that the mt8183 mutex is always free running with no > clocks property. > + An exception is that the mt8192 display add 2 more > clocks(CLK_MM_DISP_CONFIG, CLK_MM_26MHZ), > + and these 2 clocks need enabled before display module work like mutex > clock, so we add these > + 2 clocks controled same with mutex clock. If every display module needs these two clock, add these two clock to all the display module which need them. Regards, Chun-Kuang. > > Required properties (DMA function blocks): > - compatible: Should be one of > -- > 1.8.1.1.dirty > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm: require each CRTC to have a unique primary plane
On Monday, December 14th, 2020 at 9:41 AM, Pekka Paalanen
wrote:
> On Fri, 11 Dec 2020 14:39:35 +
> Simon Ser wrote:
>
> > On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen
> > wrote:
> >
> > > is there a reason why one cannot have more primary planes than CRTCs in
> > > existence?
> > >
> > > Daniel implied that in <20201209003637.GK401619@phenom.ffwll.local>,
> > > but I didn't get the reason for it yet.
> > >
> > > E.g. if all your planes are interchangeable in the sense that you can
> > > turn on a CRTC with any one of them, would one not then expose all the
> > > planes as "Primary"?
> >
> > I'm thinking of primary as a hint for simple user-space: "you can likely
> > light up a CRTC if you attach this plane and don't do anything crazy".
> > For anything more complicated, user-space uses atomic commits and can
> > completely ignore whether a plane is primary, cursor or overlay.
>
> That's a nice reason, do we have those written down anywhere?
Doesn't seem like it. The docs for enum drm_plane_type incorrectly say that the
a plane of type "Primary" will be used for legacy IOCTLs. Also, there are no
docs for the "type" property at all. I'm not even sure where to document it, as
there's no section for plane properties.
> - plane type "Primary" is a hint to userspace that using this plane
> alone on a CRTC has the highest probability of being able to turn on
> the CRTC
>
> - plane types are just a hint to userspace, userspace can and *should*
> use atomic test_only commits to discover more ways of making use of
> the planes (note: if this applies to cursor planes, it will invalidate
> some "optimizations" that virtual hardware drivers like vmwgfx(?)
> might do by having the cursor plane position controller directly from
> the host rather than looped through the guest)
Yes. In an old thread, I suggested having a DRM cap that needs to be enabled
to allow the driver to de-synchronize a cursor plane's CRTC_X/Y.
> > > If the planes have other differences, like supported formats or
> > > scaling, then marking them all "Primary" would let userspace know that
> > > it can pick any plane with the suitable properties and expect to turn
> > > on the CRTC with it.
> >
> > That's interesting, but I'd bet no user-space does that. If new user-space
> > wants to, it's better to rely on test-only commits instead.
>
> Ok. So plane types are not a good reason to prune a compositor's testing
> matrix to avoid testing some combinations.
They are a hint, so in this sense they do help pruning the testing matrix. For
instance it would be impossible for user-space to figure out the right cursor
buffer parameters without DRM_CAP_CURSOR_{WIDTH,HEIGHT}. I also think there's
an undocumented assumption that the cursor buffer must be allocated with a
LINEAR layout when the driver doesn't support modifiers.
However, for this particular case I don't think the hint would be helpful.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: move memory accounting into vmwgfx
On Wed, Dec 16, 2020 at 03:04:27PM +0100, Christian König wrote:
> This is just another feature which is only used by VMWGFX, so move
> it into the driver instead.
>
> I've tried to add the accounting sysfs file to the kobject of the drm
> minor, but I'm not 100% sure if this works as expected.
>
> Signed-off-by: Christian König
tbh, delete it all?
>From looking at callers in ttm, all this does is explicitly call your own
shrinker instead of through kmalloc. If we need this (and i915 history
somewhat suggests it might be needed, but that was with the global
dev->struct_mutex lock) then we should have this in the main ttm
allocation paths. Or more properly, in the core mm paths.
But reinventing half of the shrinker infra in a subsystem, much less in a
single driver doesn't sound like a good idea.
That means the sysfs interface goes belly up for everyone, but the real
solution for gpu memory limiting is cgroups, not something in drm hidden
away. Since you're deleting that from all other drivers I think we're
already working under the assumption that no one is using that little bit
of uapi anyway. If not, then this won't work anyway.
-Daniel
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 16 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 8 +--
> drivers/gpu/drm/drm_gem_vram_helper.c | 6 +--
> drivers/gpu/drm/nouveau/nouveau_bo.c | 7 +--
> drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
> drivers/gpu/drm/qxl/qxl_object.c | 4 +-
> drivers/gpu/drm/radeon/radeon_object.c| 8 +--
> drivers/gpu/drm/ttm/Makefile | 6 +--
> drivers/gpu/drm/ttm/ttm_bo.c | 52 ++-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
> drivers/gpu/drm/ttm/ttm_pool.c| 13 +
> drivers/gpu/drm/vmwgfx/Makefile | 2 +-
> drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c | 19 +++
> .../gpu/drm/vmwgfx}/ttm_memory.h | 5 +-
> drivers/gpu/drm/vmwgfx/ttm_object.h | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 22 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 28 +-
> include/drm/ttm/ttm_bo_api.h | 13 +
> include/drm/ttm/ttm_bo_driver.h | 1 -
> include/drm/ttm/ttm_tt.h | 1 +
> 21 files changed, 107 insertions(+), 114 deletions(-)
> rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c (97%)
> rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_memory.h (97%)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index a9647e7f98a8..5ed1c88b8748 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -118,6 +118,16 @@ void amdgpu_amdkfd_gpuvm_init_mem_limits(void)
> */
> #define ESTIMATE_PT_SIZE(mem_size) ((mem_size) >> 14)
>
> +static size_t amdgpu_amdkfd_acc_size(uint64_t size)
> +{
> + size >>= PAGE_SHIFT;
> + size *= sizeof(dma_addr_t) + sizeof(void *);
> +
> + return __roundup_pow_of_two(sizeof(struct amdgpu_bo)) +
> + __rountup_pow_of_two(sizeof(struct ttm_tt)) +
> + PAGE_ALIGN(size);
> +}
> +
> static int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
> uint64_t size, u32 domain, bool sg)
> {
> @@ -126,8 +136,7 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
> amdgpu_device *adev,
> size_t acc_size, system_mem_needed, ttm_mem_needed, vram_needed;
> int ret = 0;
>
> - acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
> -sizeof(struct amdgpu_bo));
> + acc_size = amdgpu_amdkfd_acc_size(size);
>
> vram_needed = 0;
> if (domain == AMDGPU_GEM_DOMAIN_GTT) {
> @@ -174,8 +183,7 @@ static void unreserve_mem_limit(struct amdgpu_device
> *adev,
> {
> size_t acc_size;
>
> - acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
> -sizeof(struct amdgpu_bo));
> + acc_size = amdgpu_amdkfd_acc_size(size);
>
> spin_lock(&kfd_mem_limit.mem_limit_lock);
> if (domain == AMDGPU_GEM_DOMAIN_GTT) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 6cc9919b12cc..599c9a132eb6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -523,7 +523,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
> };
> struct amdgpu_bo *bo;
> unsigned long page_align, size = bp->size;
> - size_t acc_size;
> int r;
>
> /* Note that GDS/GWS/OA allocates 1 page per byte/resource. */
> @@ -546,9 +545,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
>
> *bo_ptr = NULL;
>
> - acc_size = ttm_bo_dma_acc_s
Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
On Wed, Dec 16, 2020 at 02:52:25PM +, Deucher, Alexander wrote: > [AMD Public Use] > > > -Original Message- > > From: Laurent Pinchart > > Sent: Tuesday, December 15, 2020 9:15 PM > > To: Koenig, Christian > > Cc: Daniel Vetter ; Laurent Pinchart > > ; dri- > > de...@lists.freedesktop.org; Dave Airlie ; Greg Kroah- > > Hartman ; Thomas Gleixner > > ; Deucher, Alexander ; > > Rob Clark ; Sean Paul ; Ben > > Skeggs ; Gerd Hoffmann ; > > Thierry Reding ; Eric Anholt ; > > VMware Graphics ; Thomas > > Hellstrom > > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > > > Hi Christian, > > > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > > Most of the DRM drivers uAPI headers are licensed under the MIT > > > license, and carry copies of the license with slight variations. > > > Replace them with SPDX headers. > > > >>> My personal opinion is that this is a really good idea, but my > > > >>> professional is that we need the acknowledgment from our legal > > department for this. > > > >> I think official ack from amd on first patch, especially the .rst > > > >> snippet, would be really good indeed. > > > > Any update on this one ? > > > > > > Sorry totally forgot to forward this because I was waiting for split > > > up patches. > > > > > > Going to do so right now. > > > > Has there been any update ? :-) > > AMD legal requires the full license. Um, what? Please let me talk to them about this, it's not ok for one individual company, out of 450+, to somehow decide to do something different. Please put your lawyers in contact with me and I will have them discuss it with the proper lawyers on our side. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix unused function warning
Am 08.12.20 um 10:43 schrieb Christian König:
Am 08.12.20 um 09:18 schrieb Martin Peres:
On 04/12/2020 18:51, Arnd Bergmann wrote:
From: Arnd Bergmann
ttm_pool_type_count() is not used when debugfs is disabled:
drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
Move the definition into the #ifdef block.
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Signed-off-by: Arnd Bergmann
Thanks Arnd! The patch looks good to me:
Reviewed-by: Martin Peres
Reviewed-by: Christian König
I've just pushed that to drm-misc-next-fixes.
Christian.
---
drivers/gpu/drm/ttm/ttm_pool.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
b/drivers/gpu/drm/ttm/ttm_pool.c
index 5455b2044759..7b2f60616750 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -239,21 +239,6 @@ static struct page *ttm_pool_type_take(struct
ttm_pool_type *pt)
return p;
}
-/* Count the number of pages available in a pool_type */
-static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
-{
- unsigned int count = 0;
- struct page *p;
-
- spin_lock(&pt->lock);
- /* Only used for debugfs, the overhead doesn't matter */
- list_for_each_entry(p, &pt->pages, lru)
- ++count;
- spin_unlock(&pt->lock);
-
- return count;
-}
-
/* Initialize and add a pool type to the global shrinker list */
static void ttm_pool_type_init(struct ttm_pool_type *pt, struct
ttm_pool *pool,
enum ttm_caching caching, unsigned int order)
@@ -543,6 +528,20 @@ void ttm_pool_fini(struct ttm_pool *pool)
EXPORT_SYMBOL(ttm_pool_fini);
#ifdef CONFIG_DEBUG_FS
+/* Count the number of pages available in a pool_type */
+static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
+{
+ unsigned int count = 0;
+ struct page *p;
+
+ spin_lock(&pt->lock);
+ /* Only used for debugfs, the overhead doesn't matter */
+ list_for_each_entry(p, &pt->pages, lru)
+ ++count;
+ spin_unlock(&pt->lock);
+
+ return count;
+}
/* Dump information about the different pool types */
static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Update addresses for TI display drivers
On 2020-12-16 9:59, Tomi Valkeinen wrote: Update the maintainer email addresses for TI display drivers. Signed-off-by: Tomi Valkeinen Acked-by: Jyri Sarha --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 281de213ef47..c21471497a18 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5932,8 +5932,8 @@ F: Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml F: drivers/gpu/drm/stm DRM DRIVERS FOR TI KEYSTONE -M: Jyri Sarha -M: Tomi Valkeinen +M: Jyri Sarha +M: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc @@ -5943,15 +5943,15 @@ F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml F: drivers/gpu/drm/tidss/ DRM DRIVERS FOR TI LCDC -M: Jyri Sarha -R: Tomi Valkeinen +M: Jyri Sarha +R: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained F: Documentation/devicetree/bindings/display/tilcdc/ F: drivers/gpu/drm/tilcdc/ DRM DRIVERS FOR TI OMAP -M: Tomi Valkeinen +M: Tomi Valkeinen L: dri-devel@lists.freedesktop.org S: Maintained F: Documentation/devicetree/bindings/display/ti/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 12/16/20 9:21 AM, Daniel Vetter wrote: On Wed, Dec 16, 2020 at 9:04 AM Christian König wrote: Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: [SNIP] While we can't control user application accesses to the mapped buffers explicitly and hence we use page fault rerouting I am thinking that in this case we may be able to sprinkle drm_dev_enter/exit in any such sensitive place were we might CPU access a DMA buffer from the kernel ? Yes, I fear we are going to need that. Things like CPU page table updates, ring buffer accesses and FW memcpy ? Is there other places ? Puh, good question. I have no idea. Another point is that at this point the driver shouldn't access any such buffers as we are at the process finishing the device. AFAIK there is no page fault mechanism for kernel mappings so I don't think there is anything else to do ? Well there is a page fault handler for kernel mappings, but that one just prints the stack trace into the system log and calls BUG(); :) Long story short we need to avoid any access to released pages after unplug. No matter if it's from the kernel or userspace. I was just about to start guarding with drm_dev_enter/exit CPU accesses from kernel to GTT ot VRAM buffers but then i looked more in the code and seems like ttm_tt_unpopulate just deletes DMA mappings (for the sake of device to main memory access). Kernel page table is not touched until last bo refcount is dropped and the bo is released (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This is both for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped by ioremap. So as i see it, nothing will bad will happen after we unpopulate a BO while we still try to use a kernel mapping for it, system memory pages backing GTT BOs are still mapped and not freed and for VRAM BOs same is for the IO physical ranges mapped into the kernel page table since iounmap wasn't called yet. The problem is the system pages would be freed and if we kernel driver still happily write to them we are pretty much busted because we write to freed up memory. OK, i see i missed ttm_tt_unpopulate->..->ttm_pool_free which will release the GTT BO pages. But then isn't there a problem in ttm_bo_release since ttm_bo_cleanup_memtype_use which also leads to pages release comes before bo->destroy which unmaps the pages from kernel page table ? Won't we have end up writing to freed memory in this time interval ? Don't we need to postpone pages freeing to after kernel page table unmapping ? Similar for vram, if this is actual hotunplug and then replug, there's going to be a different device behind the same mmio bar range most likely (the higher bridges all this have the same windows assigned), No idea how this actually works but if we haven't called iounmap yet doesn't it mean that those physical ranges that are still mapped into page table should be reserved and cannot be reused for another device ? As a guess, maybe another subrange from the higher bridge's total range will be allocated. and that's bad news if we keep using it for current drivers. So we really have to point all these cpu ptes to some other place. We can't just unmap it without syncing against any in kernel accesses to those buffers and since page faulting technique we use for user mapped buffers seems to not be possible for kernel mapped buffers I am not sure how to do it gracefully... Andrey -Daniel Christian. I loaded the driver with vm_update_mode=3 meaning all VM updates done using CPU and hasn't seen any OOPs after removing the device. I guess i can test it more by allocating GTT and VRAM BOs and trying to read/write to them after device is removed. Andrey Regards, Christian. Andrey ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C6ee2a428d88a4742f45a08d8a1cde9c7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437253067654506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WRL2smY7iemgZdlH3taUZCoa8h%2BuaKD1Hv0tbHUclAQ%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: suspicious RCU usage in modeset_lock
On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2020 at 2:14 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of git://git.kernel.o..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=130558c550
> > kernel config: https://syzkaller.appspot.com/x/.config?x=ee8a1012a5314210
> > dashboard link: https://syzkaller.appspot.com/bug?extid=972b924c988834e868b2
> > compiler: gcc (GCC) 10.1.0-syz 20200507
> > userspace arch: i386
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+972b924c988834e86...@syzkaller.appspotmail.com
> >
> > =
> > WARNING: suspicious RCU usage
> > 5.10.0-rc7-syzkaller #0 Not tainted
> > -
> > kernel/sched/core.c:7270 Illegal context switch in RCU-sched read-side
> > critical section!
> >
> > other info that might help us debug this:
> >
> >
> > rcu_scheduler_active = 2, debug_locks = 0
> > 7 locks held by syz-executor.1/9232:
> > #0: 8b328c60 (console_lock){+.+.}-{0:0}, at:
> > do_fb_ioctl+0x2e4/0x690 drivers/video/fbdev/core/fbmem.c:1106
> > #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at: lock_fb_info
> > include/linux/fb.h:636 [inline]
> > #1: 888041bd4078 (&fb_info->lock){+.+.}-{3:3}, at:
> > do_fb_ioctl+0x2ee/0x690 drivers/video/fbdev/core/fbmem.c:1107
> > #2: 888041adca78 (&helper->lock){+.+.}-{3:3}, at:
> > drm_fb_helper_pan_display+0xce/0x970 drivers/gpu/drm/drm_fb_helper.c:1448
> > #3: 8880159f01b8 (&dev->master_mutex){+.+.}-{3:3}, at:
> > drm_master_internal_acquire+0x1d/0x70 drivers/gpu/drm/drm_auth.c:407
> > #4: 888041adc898 (&client->modeset_mutex){+.+.}-{3:3}, at:
> > drm_client_modeset_commit_locked+0x44/0x580
> > drivers/gpu/drm/drm_client_modeset.c:1143
> > #5: c90001c07730 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
> > drm_client_modeset_commit_atomic+0xb7/0x7c0
> > drivers/gpu/drm/drm_client_modeset.c:981
> > #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
> > ww_mutex_lock_slow include/linux/ww_mutex.h:287 [inline]
> > #6: 888015986108 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
> > modeset_lock+0x31c/0x650 drivers/gpu/drm/drm_modeset_lock.c:260
>
> Given that we managed to take all these locks without upsetting anyone
> the rcu section is very deep down. And looking at the backtrace below
> I just couldn't find anything.
>
> Best I can think of is that an interrupt of some sort leaked an rcu
> section, and we got shot here. But I'd assume the rcu debugging would
> catch this? Backtrace of the start of that rcu read side section would
> be really useful here, but I'm not seeing that in the logs. There's
> more stuff there, but it's just the usual "everything falls apart"
> stuff of little value to understanding how we got there.
In my experience, lockdep will indeed complain if an interrupt handler
returns while in an RCU read-side critical section.
> Adding some rcu people for more insights on what could have gone wrong here.
> -Daniel
>
> > stack backtrace:
> > CPU: 1 PID: 9232 Comm: syz-executor.1 Not tainted 5.10.0-rc7-syzkaller #0
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x107/0x163 lib/dump_stack.c:118
> > ___might_sleep+0x25d/0x2b0 kernel/sched/core.c:7270
> > __mutex_lock_common kernel/locking/mutex.c:935 [inline]
> > __ww_mutex_lock.constprop.0+0xa9/0x2cc0 kernel/locking/mutex.c:
> > ww_mutex_lock+0x3d/0x170 kernel/locking/mutex.c:1190
Acquiring a mutex while under the influence of rcu_read_lock() will
definitely get you this lockdep complaint, and rightfully so.
If you need to acquire a mutex with RCU-like protection, one approach
is to use SRCU. But usually this indicates (as you suspected) that
someone forgot to invoke rcu_read_unlock().
One way to locate this is to enlist the aid of lockdep. You can do this
by putting something like this in the callers:
RCU_LOCKDEP_WARN(lock_is_held(&rcu_bh_lock_map) ||
lock_is_held(&rcu_lock_map) ||
lock_is_held(&rcu_sched_lock_map),
"We are in an RCU read-side critical section");
This will get you a lockdep complaint much like the one above if the
caller is in any sort of RCU read-side critical section. You can push
this up the call stack one level at a time or just sprinkle it up the
stack in one go.
The complaint is specifically about RCU-sched, so you could focus on
that using this instead:
RCU_LOCKDEP_WARN(lock_is_held(&rcu_sched_lock_map),
"We are in an RCU-sched read-side critical section");
This of cours
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky: On 12/16/20 9:21 AM, Daniel Vetter wrote: On Wed, Dec 16, 2020 at 9:04 AM Christian König wrote: Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: [SNIP] While we can't control user application accesses to the mapped buffers explicitly and hence we use page fault rerouting I am thinking that in this case we may be able to sprinkle drm_dev_enter/exit in any such sensitive place were we might CPU access a DMA buffer from the kernel ? Yes, I fear we are going to need that. Things like CPU page table updates, ring buffer accesses and FW memcpy ? Is there other places ? Puh, good question. I have no idea. Another point is that at this point the driver shouldn't access any such buffers as we are at the process finishing the device. AFAIK there is no page fault mechanism for kernel mappings so I don't think there is anything else to do ? Well there is a page fault handler for kernel mappings, but that one just prints the stack trace into the system log and calls BUG(); :) Long story short we need to avoid any access to released pages after unplug. No matter if it's from the kernel or userspace. I was just about to start guarding with drm_dev_enter/exit CPU accesses from kernel to GTT ot VRAM buffers but then i looked more in the code and seems like ttm_tt_unpopulate just deletes DMA mappings (for the sake of device to main memory access). Kernel page table is not touched until last bo refcount is dropped and the bo is released (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This is both for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped by ioremap. So as i see it, nothing will bad will happen after we unpopulate a BO while we still try to use a kernel mapping for it, system memory pages backing GTT BOs are still mapped and not freed and for VRAM BOs same is for the IO physical ranges mapped into the kernel page table since iounmap wasn't called yet. The problem is the system pages would be freed and if we kernel driver still happily write to them we are pretty much busted because we write to freed up memory. OK, i see i missed ttm_tt_unpopulate->..->ttm_pool_free which will release the GTT BO pages. But then isn't there a problem in ttm_bo_release since ttm_bo_cleanup_memtype_use which also leads to pages release comes before bo->destroy which unmaps the pages from kernel page table ? Won't we have end up writing to freed memory in this time interval ? Don't we need to postpone pages freeing to after kernel page table unmapping ? BOs are only destroyed when there is a guarantee that nobody is accessing them any more. The problem here is that the pages as well as the VRAM can be immediately reused after the hotplug event. Similar for vram, if this is actual hotunplug and then replug, there's going to be a different device behind the same mmio bar range most likely (the higher bridges all this have the same windows assigned), No idea how this actually works but if we haven't called iounmap yet doesn't it mean that those physical ranges that are still mapped into page table should be reserved and cannot be reused for another device ? As a guess, maybe another subrange from the higher bridge's total range will be allocated. Nope, the PCIe subsystem doesn't care about any ioremap still active for a range when it is hotplugged. and that's bad news if we keep using it for current drivers. So we really have to point all these cpu ptes to some other place. We can't just unmap it without syncing against any in kernel accesses to those buffers and since page faulting technique we use for user mapped buffers seems to not be possible for kernel mapped buffers I am not sure how to do it gracefully... We could try to replace the kmap with a dummy page under the hood, but that is extremely tricky. Especially since BOs which are just 1 page in size could point to the linear mapping directly. Christian. Andrey -Daniel Christian. I loaded the driver with vm_update_mode=3 meaning all VM updates done using CPU and hasn't seen any OOPs after removing the device. I guess i can test it more by allocating GTT and VRAM BOs and trying to read/write to them after device is removed. Andrey Regards, Christian. Andrey ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C6ee2a428d88a4742f45a08d8a1cde9c7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437253067654506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WRL2smY7iemgZdlH3taUZCoa8h%2BuaKD1Hv0tbHUclAQ%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/li
Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
[AMD Official Use Only - Internal Distribution Only]
You can add amd-21.xx as well, since they will coming up next year. Maybe
amd-2*?
Alex
From: Rong Chen
Sent: Wednesday, December 16, 2020 3:48 AM
To: Deucher, Alexander ; Qinglang Miao
; kernel test robot
Cc: kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ; Felix
<"Xiong, "@ml01.01.org>
Subject: Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse:
sparse: incorrect type in argument 1 (different base types)
Hi Alex,
We have ignored the amd-20.xx branches:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fintel%2Flkp-tests%2Fcommit%2Facb8d1f213ec6841900e0d7e9737f8ea0960e4d3&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682479635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U2aA%2B31wbSToDkIHiUrJWriNOPNNJ162W3F1HjYG6mc%3D&reserved=0
Best Regards,
Rong Chen
On 12/15/20 10:24 PM, Deucher, Alexander wrote:
>
> [AMD Public Use]
>
>
> The test robot should probably not be testing the amd-20.xx branches
> in the first place. They are just mirrors of our packaged drivers so
> they contain a bunch of stuff that will never go upstream like kernel
> compatibility layers and dkms support.
>
> Alex
>
>
> *From:* Qinglang Miao
> *Sent:* Tuesday, December 15, 2020 3:21 AM
> *To:* kernel test robot ; Deucher, Alexander
>
> *Cc:* kbuild-...@lists.01.org ;
> dri-devel@lists.freedesktop.org ;
> Xiong, Yang (Felix)
> *Subject:* Re: [radeon-alex:amd-20.45 2127/2427]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39:
> sparse: sparse: incorrect type in argument 1 (different base types)
> Hi Alex,
>
> I think it's not a valid report from kernel test robot, for __le16 ought
> to be the right type for cpu_to_le16. The sparse warnings seems not
> right so I did't try effort to reproduce it.
>
> otherwise, when I take a carful look at this patch, an unconditional
> braces exists and I'm not sure about its benefit.
>
> if (bp_params->flags.INTERLACE) {
> params.susModeMiscInfo.usAccess =
> cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
> ATOM_INTERLACE);
> {
> le16_add_cpu(¶ms.usV_SyncOffset, 1);
> }
> }
>
> patch link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2F&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=loDpCZcwzSthBMwesVesMIEwtgf%2BGZoycOyTwBpqkfI%3D&reserved=0
>
> How do you think?
>
> 在 2020/12/15 14:44, kernel test robot 写道:
> > tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> > head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> > commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427]
> drm/amd/display: convert to use le16_add_cpu()
> > config: arc-randconfig-s031-20201214 (attached as .config)
> > compiler: arc-elf-gcc (GCC) 9.3.0
> > reproduce:
> > wget
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a6yKdL%2BoYm1zc5fYftUrWwmas%2BOfrTjqpivV14xci1Y%3D&reserved=0
> -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # apt-get install sparse
> > # sparse version: v0.6.3-184-g1b896707-dirty
> > git remote add radeon-alex
> git://people.freedesktop.org/~agd5f/linux.git
> > git fetch --no-tags radeon-alex amd-20.45
> > git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
> make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> >
> > "sparse warnings: (new ones prefixed by >>)"
> >
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: sparse: incorrect type in assignment (different base types)
> @@ expected unsigned int [addressable] [assigned] [usertype]
> ulSymClock @@ got restricted __le16 [usertype] @@
> >
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: ex
Re: [PATCH 2/2] drm/ttm: move memory accounting into vmwgfx
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10 next-20201215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v2/20201216-221614 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: riscv-rv32_defconfig (attached as .config) compiler: riscv32-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/b613e371433208f88816be875b9d46b6d24cf830 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v2/20201216-221614 git checkout b613e371433208f88816be875b9d46b6d24cf830 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): riscv32-linux-ld: drivers/gpu/drm/ttm/ttm_bo.o: in function `.L114': >> ttm_bo.c:(.text+0x62c): undefined reference to `__udivdi3' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On Wed, Dec 16, 2020 at 5:18 PM Christian König wrote: > > Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky: > > > > On 12/16/20 9:21 AM, Daniel Vetter wrote: > >> On Wed, Dec 16, 2020 at 9:04 AM Christian König > >> wrote: > >>> Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: > [SNIP] > >> While we can't control user application accesses to the mapped > >> buffers explicitly and hence we use page fault rerouting > >> I am thinking that in this case we may be able to sprinkle > >> drm_dev_enter/exit in any such sensitive place were we might > >> CPU access a DMA buffer from the kernel ? > > Yes, I fear we are going to need that. > > > >> Things like CPU page table updates, ring buffer accesses and FW > >> memcpy ? Is there other places ? > > Puh, good question. I have no idea. > > > >> Another point is that at this point the driver shouldn't access any > >> such buffers as we are at the process finishing the device. > >> AFAIK there is no page fault mechanism for kernel mappings so I > >> don't think there is anything else to do ? > > Well there is a page fault handler for kernel mappings, but that one > > just prints the stack trace into the system log and calls BUG(); :) > > > > Long story short we need to avoid any access to released pages after > > unplug. No matter if it's from the kernel or userspace. > > I was just about to start guarding with drm_dev_enter/exit CPU > accesses from kernel to GTT ot VRAM buffers but then i looked more in > the code > and seems like ttm_tt_unpopulate just deletes DMA mappings (for the > sake of device to main memory access). Kernel page table is not > touched > until last bo refcount is dropped and the bo is released > (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This > is both > for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped > by ioremap. So as i see it, nothing will bad will happen after we > unpopulate a BO while we still try to use a kernel mapping for it, > system memory pages backing GTT BOs are still mapped and not freed and > for > VRAM BOs same is for the IO physical ranges mapped into the kernel > page table since iounmap wasn't called yet. > >>> The problem is the system pages would be freed and if we kernel driver > >>> still happily write to them we are pretty much busted because we write > >>> to freed up memory. > > > > > > OK, i see i missed ttm_tt_unpopulate->..->ttm_pool_free which will > > release > > the GTT BO pages. But then isn't there a problem in ttm_bo_release since > > ttm_bo_cleanup_memtype_use which also leads to pages release comes > > before bo->destroy which unmaps the pages from kernel page table ? Won't > > we have end up writing to freed memory in this time interval ? Don't we > > need to postpone pages freeing to after kernel page table unmapping ? > > BOs are only destroyed when there is a guarantee that nobody is > accessing them any more. > > The problem here is that the pages as well as the VRAM can be > immediately reused after the hotplug event. > > > > > > >> Similar for vram, if this is actual hotunplug and then replug, there's > >> going to be a different device behind the same mmio bar range most > >> likely (the higher bridges all this have the same windows assigned), > > > > > > No idea how this actually works but if we haven't called iounmap yet > > doesn't it mean that those physical ranges that are still mapped into > > page > > table should be reserved and cannot be reused for another > > device ? As a guess, maybe another subrange from the higher bridge's > > total > > range will be allocated. > > Nope, the PCIe subsystem doesn't care about any ioremap still active for > a range when it is hotplugged. > > > > >> and that's bad news if we keep using it for current drivers. So we > >> really have to point all these cpu ptes to some other place. > > > > > > We can't just unmap it without syncing against any in kernel accesses > > to those buffers > > and since page faulting technique we use for user mapped buffers seems > > to not be possible > > for kernel mapped buffers I am not sure how to do it gracefully... > > We could try to replace the kmap with a dummy page under the hood, but > that is extremely tricky. > > Especially since BOs which are just 1 page in size could point to the > linear mapping directly. I think it's just more work. Essentially - convert as much as possible of the kernel mappings to vmap_local, which Thomas Zimmermann is rolling out. That way a dma_resv_lock will serve as a barrier, and ofc any new vmap needs to fail or hand out a dummy mapping. - handle fbcon somehow. I think shutting it all down should work out. - worst case keep the system backing storage around for shared dma-buf until the other non-dynamic driver releases it. for vram we require dynamic importers (and maybe it wa
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On Wed, Dec 16, 2020 at 6:12 PM Daniel Vetter wrote: > > On Wed, Dec 16, 2020 at 5:18 PM Christian König > wrote: > > > > Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky: > > > > > > On 12/16/20 9:21 AM, Daniel Vetter wrote: > > >> On Wed, Dec 16, 2020 at 9:04 AM Christian König > > >> wrote: > > >>> Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: > > [SNIP] > > >> While we can't control user application accesses to the mapped > > >> buffers explicitly and hence we use page fault rerouting > > >> I am thinking that in this case we may be able to sprinkle > > >> drm_dev_enter/exit in any such sensitive place were we might > > >> CPU access a DMA buffer from the kernel ? > > > Yes, I fear we are going to need that. > > > > > >> Things like CPU page table updates, ring buffer accesses and FW > > >> memcpy ? Is there other places ? > > > Puh, good question. I have no idea. > > > > > >> Another point is that at this point the driver shouldn't access any > > >> such buffers as we are at the process finishing the device. > > >> AFAIK there is no page fault mechanism for kernel mappings so I > > >> don't think there is anything else to do ? > > > Well there is a page fault handler for kernel mappings, but that one > > > just prints the stack trace into the system log and calls BUG(); :) > > > > > > Long story short we need to avoid any access to released pages after > > > unplug. No matter if it's from the kernel or userspace. > > > > I was just about to start guarding with drm_dev_enter/exit CPU > > accesses from kernel to GTT ot VRAM buffers but then i looked more in > > the code > > and seems like ttm_tt_unpopulate just deletes DMA mappings (for the > > sake of device to main memory access). Kernel page table is not > > touched > > until last bo refcount is dropped and the bo is released > > (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This > > is both > > for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped > > by ioremap. So as i see it, nothing will bad will happen after we > > unpopulate a BO while we still try to use a kernel mapping for it, > > system memory pages backing GTT BOs are still mapped and not freed and > > for > > VRAM BOs same is for the IO physical ranges mapped into the kernel > > page table since iounmap wasn't called yet. > > >>> The problem is the system pages would be freed and if we kernel driver > > >>> still happily write to them we are pretty much busted because we write > > >>> to freed up memory. > > > > > > > > > OK, i see i missed ttm_tt_unpopulate->..->ttm_pool_free which will > > > release > > > the GTT BO pages. But then isn't there a problem in ttm_bo_release since > > > ttm_bo_cleanup_memtype_use which also leads to pages release comes > > > before bo->destroy which unmaps the pages from kernel page table ? Won't > > > we have end up writing to freed memory in this time interval ? Don't we > > > need to postpone pages freeing to after kernel page table unmapping ? > > > > BOs are only destroyed when there is a guarantee that nobody is > > accessing them any more. > > > > The problem here is that the pages as well as the VRAM can be > > immediately reused after the hotplug event. > > > > > > > > > > >> Similar for vram, if this is actual hotunplug and then replug, there's > > >> going to be a different device behind the same mmio bar range most > > >> likely (the higher bridges all this have the same windows assigned), > > > > > > > > > No idea how this actually works but if we haven't called iounmap yet > > > doesn't it mean that those physical ranges that are still mapped into > > > page > > > table should be reserved and cannot be reused for another > > > device ? As a guess, maybe another subrange from the higher bridge's > > > total > > > range will be allocated. > > > > Nope, the PCIe subsystem doesn't care about any ioremap still active for > > a range when it is hotplugged. > > > > > > > >> and that's bad news if we keep using it for current drivers. So we > > >> really have to point all these cpu ptes to some other place. > > > > > > > > > We can't just unmap it without syncing against any in kernel accesses > > > to those buffers > > > and since page faulting technique we use for user mapped buffers seems > > > to not be possible > > > for kernel mapped buffers I am not sure how to do it gracefully... > > > > We could try to replace the kmap with a dummy page under the hood, but > > that is extremely tricky. > > > > Especially since BOs which are just 1 page in size could point to the > > linear mapping directly. > > I think it's just more work. Essentially > - convert as much as possible of the kernel mappings to vmap_local, > which Thomas Zimmermann is rolling out. That way a dma_resv_lock will > serve as a barrier, and ofc any new vmap needs to fail or hand
[PATCH v7 1/5] drm: Add function to convert rect in 16.16 fixed format to regular format
Much more clear to read one function call than four lines doing this
conversion.
v7:
- function renamed
- calculating width and height before truncate
- inlined
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
include/drm/drm_rect.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index e7f4d24cdd00..7eb84af4a818 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -206,6 +206,19 @@ static inline bool drm_rect_equals(const struct drm_rect
*r1,
r1->y1 == r2->y1 && r1->y2 == r2->y2;
}
+/**
+ * drm_rect_fp_to_int - Convert a rect in 16.16 fixed point form to int form.
+ * @destination: rect to be stored the converted value
+ * @source: rect in 16.16 fixed point form
+ */
+static inline void drm_rect_fp_to_int(struct drm_rect *destination,
+ const struct drm_rect *source)
+{
+ drm_rect_init(destination, source->x1 >> 16, source->y1 >> 16,
+ drm_rect_width(source) >> 16,
+ drm_rect_height(source) >> 16);
+}
+
bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip);
bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
const struct drm_rect *clip);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: cma_heap: Include linux/vmalloc.h to fix build failures on MIPS
Hi John,
On Wed, 16 Dec 2020 at 06:19, John Stultz wrote:
>
> We need to include in order for MIPS to find
> vmap(), as it doesn't otherwise get included there.
>
> Without this patch, one can hit the following build error:
> drivers/dma-buf/heaps/cma_heap.c: In function 'cma_heap_do_vmap':
> drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of
> function 'vmap'
Thanks for the patch; I've merged it to drm-misc-next-fixes.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
> cma_heap implementation")
> Reported-by: Guenter Roeck
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 5e7c3436310c..3c4e34301172 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
>
> struct cma_heap {
> --
> 2.17.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"
On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel wrote: > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > Simply disabling -mgeneral-regs-only left and right is risky, given that > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, > and GCC is known to use SIMD registers for spilling, and may invent > other uses of the FP/SIMD register file that have nothing to do with the > floating point code in question. Note that putting kernel_neon_begin() > and kernel_neon_end() around the code that does use FP is not sufficient > here, the problem is in all the other code that may be emitted with > references to SIMD registers in it. > > So the only way to do this properly is to put all floating point code in > a separate compilation unit, and only compile that unit with > -mgeneral-regs-only. But perhaps the use of floating point here is > something that should be reconsidered entirely. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Dave Martin > Cc: Rob Herring > Cc: Leo Li > Cc: Alex Deucher > Cc: "Christian König" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Daniel Kolesa > Cc: amd-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Ard Biesheuvel Can rebase this on Linus' master branch? There were a number of new asics added which copy pasted the ARM64 support. Alex > --- > drivers/gpu/drm/amd/display/Kconfig | 2 +- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 7 -- > drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile | 7 -- > drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 -- > drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 > > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 - > drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 - > drivers/gpu/drm/amd/display/dc/dml/Makefile | 13 > drivers/gpu/drm/amd/display/dc/dsc/Makefile | 5 -- > drivers/gpu/drm/amd/display/dc/os_types.h | 4 - > 10 files changed, 32 insertions(+), 102 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index 60dfdd432aba..3c410d236c49 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -6,7 +6,7 @@ config DRM_AMD_DC > bool "AMD DC - Enable new display engine" > default y > select SND_HDA_COMPONENT if SND_HDA_CORE > - select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && > KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) > + select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && > KCOV_ENABLE_COMPARISONS) > help > Choose this option if you want to use the new display engine > support for AMDGPU. This adds required support for Vega and > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index 64f515d74410..4674aca8f206 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -33,10 +33,6 @@ ifdef CONFIG_PPC64 > calcs_ccflags := -mhard-float -maltivec > endif > > -ifdef CONFIG_ARM64 > -calcs_rcflags := -mgeneral-regs-only > -endif > - > ifdef CONFIG_CC_IS_GCC > ifeq ($(call cc-ifversion, -lt, 0701, y), y) > IS_OLD_GCC = 1 > @@ -57,9 +53,6 @@ endif > CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags) > CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags) > CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags) > -Wno-tautological-compare > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags) > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags) > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags) > > BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o > > diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile > b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile > index 1a495759a034..52b1ce775a1e 100644 > --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile > @@ -104,13 +104,6 @@ ifdef CONFIG_PPC64 > CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call > cc-option,-mno-gnu-attribute) > endif > > -# prevent build errors: > -# ...: '-mgeneral-regs-only' is incompatible with the use of floating-point > types > -# this file is unused on arm64, just like on ppc64 > -ifdef CONFIG_ARM64 > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := > -mgeneral-regs-only > -endif > - > AMD_DAL_CLK_MGR_DCN21 = $(addprefix > $(AMDDALPATH)/dc/clk_mgr/dcn21/,$(CLK_MGR_DCN21)) > > AMD_DISPLAY_FILES += $(AMD_DAL_CLK_MGR_DCN21) > diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile > b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile > index 733e6e6e43bd..62ad1a11bff9 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn
Re: [PATCH 2/2] drm/ttm: move memory accounting into vmwgfx
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10 next-20201215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v2/20201216-221614
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-c001-20201216 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/b613e371433208f88816be875b9d46b6d24cf830
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-rework-ttm_tt-page-limit-v2/20201216-221614
git checkout b613e371433208f88816be875b9d46b6d24cf830
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/ttm/ttm_bo.o: in function `ttm_bo_global_init':
>> drivers/gpu/drm/ttm/ttm_bo.c:1242: undefined reference to `__udivdi3'
vim +1242 drivers/gpu/drm/ttm/ttm_bo.c
1223
1224 static int ttm_bo_global_init(void)
1225 {
1226 struct ttm_bo_global *glob = &ttm_bo_glob;
1227 uint64_t num_pages;
1228 struct sysinfo si;
1229 int ret = 0;
1230 unsigned i;
1231
1232 mutex_lock(&ttm_global_mutex);
1233 if (++ttm_bo_glob_use_count > 1)
1234 goto out;
1235
1236 si_meminfo(&si);
1237
1238 /* Limit the number of pages in the pool to about 50% of the
total
1239 * system memory.
1240 */
1241 num_pages = (u64)si.totalram * si.mem_unit;
> 1242 num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT;
1243
1244 ttm_pool_mgr_init(num_pages);
1245 ttm_tt_mgr_init();
1246
1247 spin_lock_init(&glob->lru_lock);
1248 glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
1249
1250 if (unlikely(glob->dummy_read_page == NULL)) {
1251 ret = -ENOMEM;
1252 goto out;
1253 }
1254
1255 for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
1256 INIT_LIST_HEAD(&glob->swap_lru[i]);
1257 INIT_LIST_HEAD(&glob->device_list);
1258 atomic_set(&glob->bo_count, 0);
1259
1260 ret = kobject_init_and_add(
1261 &glob->kobj, &ttm_bo_glob_kobj_type, ttm_get_kobj(),
"buffer_objects");
1262 if (unlikely(ret != 0))
1263 kobject_put(&glob->kobj);
1264 out:
1265 mutex_unlock(&ttm_global_mutex);
1266 return ret;
1267 }
1268
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 12/16/20 12:12 PM, Daniel Vetter wrote: On Wed, Dec 16, 2020 at 5:18 PM Christian König wrote: Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky: On 12/16/20 9:21 AM, Daniel Vetter wrote: On Wed, Dec 16, 2020 at 9:04 AM Christian König wrote: Am 15.12.20 um 21:18 schrieb Andrey Grodzovsky: [SNIP] While we can't control user application accesses to the mapped buffers explicitly and hence we use page fault rerouting I am thinking that in this case we may be able to sprinkle drm_dev_enter/exit in any such sensitive place were we might CPU access a DMA buffer from the kernel ? Yes, I fear we are going to need that. Things like CPU page table updates, ring buffer accesses and FW memcpy ? Is there other places ? Puh, good question. I have no idea. Another point is that at this point the driver shouldn't access any such buffers as we are at the process finishing the device. AFAIK there is no page fault mechanism for kernel mappings so I don't think there is anything else to do ? Well there is a page fault handler for kernel mappings, but that one just prints the stack trace into the system log and calls BUG(); :) Long story short we need to avoid any access to released pages after unplug. No matter if it's from the kernel or userspace. I was just about to start guarding with drm_dev_enter/exit CPU accesses from kernel to GTT ot VRAM buffers but then i looked more in the code and seems like ttm_tt_unpopulate just deletes DMA mappings (for the sake of device to main memory access). Kernel page table is not touched until last bo refcount is dropped and the bo is released (ttm_bo_release->destroy->amdgpu_bo_destroy->amdgpu_bo_kunmap). This is both for GTT BOs maped to kernel by kmap (or vmap) and for VRAM BOs mapped by ioremap. So as i see it, nothing will bad will happen after we unpopulate a BO while we still try to use a kernel mapping for it, system memory pages backing GTT BOs are still mapped and not freed and for VRAM BOs same is for the IO physical ranges mapped into the kernel page table since iounmap wasn't called yet. The problem is the system pages would be freed and if we kernel driver still happily write to them we are pretty much busted because we write to freed up memory. OK, i see i missed ttm_tt_unpopulate->..->ttm_pool_free which will release the GTT BO pages. But then isn't there a problem in ttm_bo_release since ttm_bo_cleanup_memtype_use which also leads to pages release comes before bo->destroy which unmaps the pages from kernel page table ? Won't we have end up writing to freed memory in this time interval ? Don't we need to postpone pages freeing to after kernel page table unmapping ? BOs are only destroyed when there is a guarantee that nobody is accessing them any more. The problem here is that the pages as well as the VRAM can be immediately reused after the hotplug event. Similar for vram, if this is actual hotunplug and then replug, there's going to be a different device behind the same mmio bar range most likely (the higher bridges all this have the same windows assigned), No idea how this actually works but if we haven't called iounmap yet doesn't it mean that those physical ranges that are still mapped into page table should be reserved and cannot be reused for another device ? As a guess, maybe another subrange from the higher bridge's total range will be allocated. Nope, the PCIe subsystem doesn't care about any ioremap still active for a range when it is hotplugged. and that's bad news if we keep using it for current drivers. So we really have to point all these cpu ptes to some other place. We can't just unmap it without syncing against any in kernel accesses to those buffers and since page faulting technique we use for user mapped buffers seems to not be possible for kernel mapped buffers I am not sure how to do it gracefully... We could try to replace the kmap with a dummy page under the hood, but that is extremely tricky. Especially since BOs which are just 1 page in size could point to the linear mapping directly. I think it's just more work. Essentially - convert as much as possible of the kernel mappings to vmap_local, which Thomas Zimmermann is rolling out. That way a dma_resv_lock will serve as a barrier, and ofc any new vmap needs to fail or hand out a dummy mapping. Read those patches. I am not sure how this helps with protecting against accesses to released backing pages or IO physical ranges of BO which is already mapped during the unplug event ? Andrey - handle fbcon somehow. I think shutting it all down should work out. - worst case keep the system backing storage around for shared dma-buf until the other non-dynamic driver releases it. for vram we require dynamic importers (and maybe it wasn't such a bright idea to allow pinning of importer buffers, might need to revisit that). Cheers, Daniel Christian. Andrey -Daniel Christian. I loaded the driver with vm_update_mode=3 meaning all VM updates done using CPU a
RE: [PATCH v5 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, December 16, 2020 11:01 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v5 07/15] drm/dp_helper: Add helpers to configure PCONs RGB-
> YCbCr Conversion
>
> DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion of
> colorspace from RGB to YCbCr.
> https://groups.vesa.org/wg/DP/document/previewpdf/15651
>
> This patch adds the relavant registers and helper functions to get the
> capability
> and set the color conversion bits for rgb->ycbcr conversion through PCON.
>
> v2: As suggested in review comments:
> -Fixed bug in the check condition in a drm_helper as reported by Dan
> Carpenter
> and Kernel test robot. (Dan Carepenter) -Modified the color-conversion cap
> helper function, to accomodate
> BT709 and BT2020 colorspace. (Uma Shankar) -Added spec details for the new
> cap for color conversion. (Uma Shankar)
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 61 +
> include/drm/drm_dp_helper.h | 19 +-
> 2 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 689fd0d5f6c5..9abd65c694ab 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -949,6 +949,38 @@ bool
> drm_dp_downstream_444_to_420_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE] }
> EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
>
> +/**
> + * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream
> facing port
> + * RGB->YCbCr conversion
> capability
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: downstream facing port capabilities
> + * @colorspc: Colorspace for which conversion cap is sought
> + *
> + * Returns: whether the downstream facing port can convert RGB->YCbCr
> +for a given
> + * colorspace.
> + */
> +bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4],
> +u8 color_spc)
> +{
> + if (!drm_dp_is_branch(dpcd))
> + return false;
> +
> + if (dpcd[DP_DPCD_REV] < 0x13)
> + return false;
> +
> + switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
> + case DP_DS_PORT_TYPE_HDMI:
> + if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> + return false;
> +
> + return port_cap[3] & color_spc;
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
> +
> /**
> * drm_dp_downstream_mode() - return a mode for downstream facing port
> * @dev: DRM device
> @@ -3101,3 +3133,32 @@ int drm_dp_pcon_pps_override_param(struct
> drm_dp_aux *aux, u8 pps_param[6])
> return 0;
> }
> EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
> +
> +/*
> + * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert
> +RGB to Ycbcr
> + * @aux: displayPort AUX channel
> + * @color_spc: Color-space/s for which conversion is to be enabled, 0 for
> disable.
> + *
> + * Returns 0 on success, else returns negative error code.
> + */
> +int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8
> +color_spc) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2,
> &buf);
> + if (ret < 0)
> + return ret;
> +
> + if (color_spc & DP_CONVERSION_RGB_YCBCR_MASK)
> + buf |= (color_spc & DP_CONVERSION_RGB_YCBCR_MASK);
> + else
> + buf &= ~DP_CONVERSION_RGB_YCBCR_MASK;
> +
> + ret = drm_dp_dpcd_writeb(aux,
> DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> baad87fe6b0a..e096ee98842b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -432,6 +432,17 @@ struct drm_device;
> # define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
> # define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
>
> +/*
> + * VESA DP-to-HDMI PCON Specification adds caps for colorspace
> + * conversion in DFP cap DPCD 83h. Sec6.1 Table-3.
> + * Based on the available support the source can enable
> + * color conversion by writing into PROTOCOL_COVERTER_CONTROL_2
> + * DPCD 3052h.
> + */
> +# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
> +# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
> +# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV (1 << 7)
[pull] amdgpu, amdkfd, radeon drm-fixes-5.11
Hi Dave, Daniel, Fixes for 5.11. The following changes since commit b10733527bfd864605c33ab2e9a886eec317ec39: Merge tag 'amd-drm-next-5.11-2020-12-09' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-12-10 16:55:53 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.11-2020-12-16 for you to fetch changes up to 6ae09fa49147e557eb6aebbb5b2059b63706d454: drm/amdgpu/disply: fix documentation warnings in display manager (2020-12-16 13:27:17 -0500) amd-drm-fixes-5.11-2020-12-16: amdgpu: - Fix a eDP regression for DCE asics - SMU fixes for sienna cichlid - Misc W=1 fixes - SDMA 5.2 reset fix - Suspend/resume fix - Misc display fixes - Misc runtime PM fixes and cleanups - Dimgrey Cavefish fixes - printk cleanup - Documentation warning fixes amdkfd: - Error logging fix - Fix pipe offset calculation radeon: - printk cleanup Alex Deucher (10): drm/amdgpu/display: move link_bandwidth_kbps under CONFIG_DRM_AMD_DC_DCN drm/amdgpu: split BOCO and ATPX handling drm/amdgpu: add check for ACPI power resources drm/amdgpu: update amdgpu_device_supports_boco() drm/amdgpu: support runtime pm for GPUs that support BOCO drm/amdgpu: no need to call pci_ignore_hotplug for _PR3 drm/amdgpu: simplify logic in atpx resume handling drm/amdgpu: print what method we are using for runtime pm drm/amdgpu: fix regression in vbios reservation handling on headless drm/amdgpu/disply: fix documentation warnings in display manager Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.46 Aric Cyr (4): drm/amd/display: HP Reverb G2 VR fails to light up drm/amd/display: Only update FP2 for full updates drm/amd/display: Fix cleanup typo in MPCC visual confirm drm/amd/display: 3.2.116 Christian König (1): drm/amdgpu: limit the amdgpu_vm_update_ptes trace point Colin Ian King (1): drm/amdgpu: Fix spelling mistake "Heterogenous" -> "Heterogeneous" Eric Bernstein (1): drm/amd/display: add dcn30_link_encoder_validate_output_with_stream to header Evan Quan (12): drm/amd/pm: support power source switch on Sienna Cichlid drm/amd/pm: correct power limit setting for SMU V11 drm/amd/pm: correct the gpo control for sienna cichlid drm/amd/pm: expose the firmware_capability from firmware_info table drm/amdgpu: new macro for determining 2ND_USB20PORT support drm/amd/pm: new SMC message for 2nd usb2.0 port workaround drm/amd/pm: fulfill sienna cichlid 2nd usb2.0 port workaround drm/amd/pm: typo fix (CUSTOM -> COMPUTE) drm/amd/pm: fulfill the sienna cichlid UMD PSTATE profiling clocks drm/amd/pm: correct the data structure for activity monitor coeff exchange drm/amd/pm: update the data strucutre for SMU metrics exchange drm/amd/pm: add deep sleep control for uclk and fclk Felipe (1): drm/amd/display: Fix OGAM LUT calculation precision Flora Cui (1): drm/amd/display: drop retired CONFIG_DRM_AMD_DC_DCN3_0 Jake Wang (1): drm/amd/display: updated wm table for Renoir Jiange Zhao (1): drm/amdgpu/SRIOV: Extend VF reset request wait period Jiansong Chen (1): drm/amdkfd: correct pipe offset calculation Leo (Hanghong) Ma (1): drm/amd/display: Add DP info frame update for dcn30 Likun Gao (1): drm/amdgpu: add judgement for suspend/resume sequence Martin Leung (1): drm/amd/display: delay fp2 programming until vactive before lock Max Tseng (1): drm/amd/display: Add missing DP_SEC register definitions and masks Rodrigo Siqueira (2): drm/amd/display: Drop unnecessary function call drm/amd/display: Add get_dig_frontend implementation for DCEx Souptick Joarder (2): drm/amd/display: Fixed kernel test robot warning drm/amd/display: Adding prototype for dccg21_update_dpp_dto() Stanley.Yang (1): drm/amdgpu: skip load smu and sdma microcode on sriov for SIENNA_CICHLID Tao Zhou (2): drm/amdgpu: set mode1 reset as default for dimgrey_cavefish drm/amdgpu: print mmhub client name for dimgrey_cavefish Tom Rix (2): drm/amdgpu: remove h from printk format specifier drm/radeon: remove h from printk format specifier Victor Lu (1): drm/amd/display: Change pstate expected timeout warning to 180us on linux Wayne Lin (1): drm/amd/display: Fix to be able to stop crc calculation Xiaomeng Hou (3): drm/amd/pm: update the smu v11.5 smc header for vangogh drm/amd/pm: inform SMU RLC status thus enable/disable DPM feature for vangogh drm/amdgpu/sdma5.2: soft reset sdma blocks before setup and start sdma Yifan Zhang (1): drm/amdkfd: correct amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu log. drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6
RE: [PATCH v6 15/15] drm/i915/display: Let PCON convert from RGB to YUV if it can
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, December 16, 2020 5:01 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> airl...@linux.ie; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com;
> Kulkarni, Vandita ; Sharma, Swati2
>
> Subject: [PATCH v6 15/15] drm/i915/display: Let PCON convert from RGB to YUV
> if it can
>
> If PCON has capability to convert RGB->YUV colorspace and also to 444->420
> downsampling then for any YUV420 only mode, we can let the PCON do all the
> conversion.
>
> v2: As suggested by Uma Shankar, considered case for colorspace
> BT709 and BT2020, and default to BT609. Also appended dir 'display' in commit
> message.
>
> v3: Fixed typo in condition for printing one of the error msg.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 68 +++
> drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
> 4 files changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index fbc07a93504b..17eaa56c5a99 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
>
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
> /*
>* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
> @@ -3731,7 +3732,7 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> intel_ddi_init_dp_buf_reg(encoder, crtc_state);
> if (!is_mst)
> intel_dp_set_power(intel_dp, DP_SET_POWER_D0);
> - intel_dp_configure_protocol_converter(intel_dp);
> + intel_dp_configure_protocol_converter(intel_dp, crtc_state);
> intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state); diff --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 4c01c7c23dfd..2009ae9e9678 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1460,6 +1460,7 @@ struct intel_dp {
> int pcon_max_frl_bw;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> + bool rgb_to_ycbcr;
> } dfp;
>
> /* Display stream compression testing */ diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index abc9b772d1c8..366b2e4e7f4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector
> *connector,
> !drm_mode_is_420_only(info, mode))
> return INTEL_OUTPUT_FORMAT_RGB;
>
> + if (intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420)
> + return INTEL_OUTPUT_FORMAT_RGB;
> +
> if (intel_dp->dfp.ycbcr_444_to_420)
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> else
> @@ -4311,7 +4315,8 @@ static void intel_dp_enable_port(struct intel_dp
> *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg); }
>
> -void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp)
> +void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
> +const struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 tmp;
> @@ -4338,14 +4343,34 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp)
> drm_dbg_kms(&i915->drm,
> "Failed to set protocol converter YCbCr 4:2:0
> conversion mode to %s\n",
> enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
> -
> - tmp = 0;
> -
> - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> -DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
> + if (intel_dp->dfp.rgb_to_ycbcr) {
> + bool bt2020, bt709;
> +
> + bt2020 =
> drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
> + intel_dp-
> >downstream_ports,
> +
> DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
Next line should match the parenthesis, seems off.
> + bt709 =
> drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
> + intel_dp-
> >downstream_ports,
[PATCH 1/8] drm/doc: rename FB_DAMAGE_CLIPS section
Make it more human-readable. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- Documentation/gpu/drm-kms.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 3c5ae4f6dfd2..76cf6acc23a5 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -475,8 +475,8 @@ Plane Composition Properties .. kernel-doc:: drivers/gpu/drm/drm_blend.c :export: -FB_DAMAGE_CLIPS -~~~ +Damage Tracking Properties +-- .. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c :doc: overview -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/doc: introduce new section for standard plane properties
Introduce a new "Standard Plane Properties" section for properties
defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_blend.c | 6 --
drivers/gpu/drm/drm_plane.c | 12
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index fcd4e15379b0..9cfaab4df21a 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -493,6 +493,12 @@ Standard CRTC Properties
.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
:doc: standard CRTC properties
+Standard Plane Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: standard plane properties
+
Plane Composition Properties
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 5c2141e9a9f4..26e2f2ffd255 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -185,12 +185,6 @@
* plane does not expose the "alpha" property, then this is
* assumed to be 1.0
*
- * IN_FORMATS:
- * Blob property which contains the set of buffer format and modifier
- * pairs supported by this plane. The blob is a drm_format_modifier_blob
- * struct. Without this property the plane doesn't support buffers with
- * modifiers. Userspace cannot change this property.
- *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 49b0a8b9ac02..4c1a45ac18e6 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -61,6 +61,18 @@
* userspace too much.
*/
+/**
+ * DOC: standard plane properties
+ *
+ * DRM planes have a few standardized properties:
+ *
+ * IN_FORMATS:
+ * Blob property which contains the set of buffer format and modifier
+ * pairs supported by this plane. The blob is a drm_format_modifier_blob
+ * struct. Without this property the plane doesn't support buffers with
+ * modifiers. Userspace cannot change this property.
+ */
+
static unsigned int drm_num_planes(struct drm_device *dev)
{
unsigned int num = 0;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/doc: move damage tracking functions to new section
Move drm_damage_helper function reference from the KMS properties section to the plane abstraction section. This makes the KMS properties section more readable for user-space developers. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- Documentation/gpu/drm-kms.rst | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 3f92d4eb224b..e6329e7e638e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -376,6 +376,15 @@ Plane Composition Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_blend.c :export: +Plane Damage Tracking Functions Reference +- + +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c + :export: + +.. kernel-doc:: include/drm/drm_damage_helper.h + :internal: + Display Modes Function Reference @@ -484,12 +493,6 @@ Damage Tracking Properties .. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c :doc: overview -.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c - :export: - -.. kernel-doc:: include/drm/drm_damage_helper.h - :internal: - Color Management Properties --- -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/doc: fix drm_plane_type docs
The docs for enum drm_plane_type mention legacy IOCTLs, however the
plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
cursor fields are. Add a small paragraph to reference these.
Instead, document expectations for primary and cursor planes for
non-legacy userspace. Note that these docs are for driver developers,
not userspace developers, so internal kernel APIs are mentionned.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/drm/drm_plane.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 1d82b264e5e4..94fdd0c68450 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -538,10 +538,14 @@ struct drm_plane_funcs {
*
* For compatibility with legacy userspace, only overlay planes are made
* available to userspace by default. Userspace clients may set the
- * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
+ * &DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
* wish to receive a universal plane list containing all plane types. See also
* drm_for_each_legacy_plane().
*
+ * In addition to setting each plane's type, drivers need to setup the
+ * &drm_crtc.primary and optionally &drm_crtc.cursor for legacy IOCTLs. See
+ * drm_crtc_init_with_planes().
+ *
* WARNING: The values of this enum is UABI since they're exposed in the "type"
* property.
*/
@@ -557,19 +561,20 @@ enum drm_plane_type {
/**
* @DRM_PLANE_TYPE_PRIMARY:
*
-* Primary planes represent a "main" plane for a CRTC. Primary planes
-* are the planes operated upon by CRTC modesetting and flipping
-* operations described in the &drm_crtc_funcs.page_flip and
-* &drm_crtc_funcs.set_config hooks.
+* A primary plane attached to a CRTC is the most likely to be able to
+* light up the CRTC when no scaling/cropping is used and the plane
+* covers the whole CRTC.
*/
DRM_PLANE_TYPE_PRIMARY,
/**
* @DRM_PLANE_TYPE_CURSOR:
*
-* Cursor planes represent a "cursor" plane for a CRTC. Cursor planes
-* are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
-* DRM_IOCTL_MODE_CURSOR2 IOCTLs.
+* A cursor plane attached to a CRTC is more likely to be able to be
+* enabled when no scaling/cropping is used and the framebuffer has the
+* size indicated by &drm_mode_config.cursor_width and
+* &drm_mode_config.cursor_height. Additionally, if the driver doesn't
+* support modifiers, the framebuffer should have a linear layout.
*/
DRM_PLANE_TYPE_CURSOR,
};
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/doc: the KMS properties section is for user-space devs
State that the "KMS Properties" section is mainly for user-space developers. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- Documentation/gpu/drm-kms.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2f3efb63e5ba..fcd4e15379b0 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -460,6 +460,9 @@ KMS Locking KMS Properties == +This section of the documentation is primarily aimed at user-space developers. +For the driver APIs, so the other sections. + Property Types and Blob Property Support -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/doc: move composition function docs to new section
Move drm_blend.c function reference from the KMS properties section to the plane abstraction section. This makes the KMS properties section more readable for user-space developers. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- Documentation/gpu/drm-kms.rst | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 76cf6acc23a5..3f92d4eb224b 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -370,6 +370,12 @@ Plane Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_plane.c :export: +Plane Composition Functions Reference +- + +.. kernel-doc:: drivers/gpu/drm/drm_blend.c + :export: + Display Modes Function Reference @@ -472,9 +478,6 @@ Plane Composition Properties .. kernel-doc:: drivers/gpu/drm/drm_blend.c :doc: overview -.. kernel-doc:: drivers/gpu/drm/drm_blend.c - :export: - Damage Tracking Properties -- -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/doc: document the type plane property
Add a new entry for "type" in the section for standard plane properties. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- drivers/gpu/drm/drm_plane.c | 39 + 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 4c1a45ac18e6..e21e0caaca0f 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -49,10 +49,8 @@ * &struct drm_plane (possibly as part of a larger structure) and registers it * with a call to drm_universal_plane_init(). * - * The type of a plane is exposed in the immutable "type" enumeration property, - * which has one of the following values: "Overlay", "Primary", "Cursor" (see - * enum drm_plane_type). A plane can be compatible with multiple CRTCs, see - * &drm_plane.possible_crtcs. + * Each plane has a type, see enum drm_plane_type. A plane can be compatible + * with multiple CRTCs, see &drm_plane.possible_crtcs. * * Legacy uAPI doesn't expose the primary and cursor planes directly. DRM core * relies on the driver to set the primary and optionally the cursor plane used @@ -66,6 +64,39 @@ * * DRM planes have a few standardized properties: * + * type: + * Immutable property describing the type of the plane. + * + * For user-space which has enabled the &DRM_CLIENT_CAP_UNIVERSAL_PLANES + * capability, the plane type is just a hint and is mostly superseded by + * atomic test-only commits. The type hint can still be used to come up + * more easily with a plane configuration accepted by the driver. + * + * The value of this property can be one of the following: + * + * "Primary": + * To light up a CRTC, attaching a primary plane is the most likely to + * work if it covers the whole CRTC and doesn't have scaling or + * cropping set up. + * + * Drivers may support more features for the primary plane, user-space + * can find out with test-only atomic commits. + * "Cursor": + * To enable this plane, using a framebuffer configured without scaling + * or cropping and with the following properties is the most likely to + * work: + * + * - If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and + * &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size. + * Otherwise, create a framebuffer with the size 64x64. + * - If the driver doesn't support modifiers, create a framebuffer with + * a linear layout. Otherwise, use the IN_FORMATS plane property. + * + * Drivers may support more features for the cursor plane, user-space + * can find out with test-only atomic commits. + * "Overlay": + * Neither primary nor cursor. + * * IN_FORMATS: * Blob property which contains the set of buffer format and modifier * pairs supported by this plane. The blob is a drm_format_modifier_blob -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] drm/doc: improve plane property docs
Re-organize and improve plane property docs. Simon Ser (8): drm/doc: rename FB_DAMAGE_CLIPS section drm/doc: move composition function docs to new section drm/doc: move damage tracking functions to new section drm/doc: move color management functions under CRTC section drm/doc: the KMS properties section is for user-space devs drm/doc: introduce new section for standard plane properties drm/doc: fix drm_plane_type docs drm/doc: document the type plane property Documentation/gpu/drm-kms.rst | 52 +++ drivers/gpu/drm/drm_blend.c | 6 drivers/gpu/drm/drm_plane.c | 51 +++--- include/drm/drm_plane.h | 21 -- 4 files changed, 95 insertions(+), 35 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/doc: move color management functions under CRTC section
Move drm_color_mgmt function reference from the KMS properties section to the CRTC abstraction section. This makes the KMS properties section more readable for user-space developers. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Pekka Paalanen --- Documentation/gpu/drm-kms.rst | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index e6329e7e638e..2f3efb63e5ba 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -319,6 +319,15 @@ CRTC Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_crtc.c :export: +Color Management Functions Reference + + +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c + :export: + +.. kernel-doc:: include/drm/drm_color_mgmt.h + :internal: + Frame Buffer Abstraction @@ -499,12 +508,6 @@ Color Management Properties .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c :doc: overview -.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c - :export: - -.. kernel-doc:: include/drm/drm_color_mgmt.h - :internal: - Tile Group Property --- -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/doc: move color management functions under CRTC section
On Wed, Dec 16, 2020 at 09:22:18PM +0100, Simon Ser wrote: > Move drm_color_mgmt function reference from the KMS properties > section to the CRTC abstraction section. This makes the KMS > properties section more readable for user-space developers. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Pekka Paalanen For patches 1-4: Reviewed-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index e6329e7e638e..2f3efb63e5ba 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -319,6 +319,15 @@ CRTC Functions Reference > .. kernel-doc:: drivers/gpu/drm/drm_crtc.c > :export: > > +Color Management Functions Reference > + > + > +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c > + :export: > + > +.. kernel-doc:: include/drm/drm_color_mgmt.h > + :internal: > + > Frame Buffer Abstraction > > > @@ -499,12 +508,6 @@ Color Management Properties > .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c > :doc: overview > > -.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c > - :export: > - > -.. kernel-doc:: include/drm/drm_color_mgmt.h > - :internal: > - > Tile Group Property > --- > > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
