Re: [PATCH] fbdev: Remove udlfb driver
Hi Am 30.11.20 um 15:31 schrieb Mikulas Patocka: On Mon, 30 Nov 2020, Thomas Zimmermann wrote: Udlfb has been superseded by DRM's udl. The DRM driver is better by any means and actively maintained. Remove udlfb. Hi I am using udlfb and it's definitely better than the DRM driver. The DRM driver will crash the kernel if you unplug the device while Xorg is running. The framebuffer driver doesn't crash in this case. (I have a cat and the cat sometimes unplugs cables and I don't want to reboot the system because of it :-) What's the exact STR here? Just open the /dev/fb* and pull the cable. Do I need a cat? :) The framebuffer driver is faster, it keeps back buffer and updates only data that differ between the front and back buffer. The DRM driver doesn't have such optimization, it will update everything in a given rectangle - this increases USB traffic and makes video playback more jerky. That's not quite true, but not false either. I think we could optimize what we have. The framebuffer driver supports programs running full-screen directly on the framebuffer console, such as web browser "links -g", image viewer "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", movie player "mplayer -vo fbdev". The DRM driver doesn't run them. I would expect that most programs have an SDL2 backend. (?) IIRC SDL2 has support for DRI interfaces. If you seach for someone to maintain the framebuffer driver, I can do it. I'm looking for reasons why udlfb is still around. What I got from this thread is the possible crash and a lack of DRM's fbdev performance. Thanks for the feedback. Best regards Thomas Mikulas Signed-off-by: Thomas Zimmermann --- CREDITS |5 + Documentation/fb/index.rst |1 - Documentation/fb/udlfb.rst | 162 --- MAINTAINERS |9 - drivers/video/fbdev/Kconfig | 17 +- drivers/video/fbdev/Makefile |1 - drivers/video/fbdev/udlfb.c | 1994 -- 7 files changed, 6 insertions(+), 2183 deletions(-) delete mode 100644 Documentation/fb/udlfb.rst delete mode 100644 drivers/video/fbdev/udlfb.c -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Remove udlfb driver
Hi Am 30.11.20 um 19:39 schrieb Mikulas Patocka: On Mon, 30 Nov 2020, Daniel Vetter wrote: On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote: The framebuffer driver supports programs running full-screen directly on the framebuffer console, such as web browser "links -g", image viewer "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", movie player "mplayer -vo fbdev". The DRM driver doesn't run them. Hm this should in general work on drm drivers. Without that it's clear the switch-over isn't really ready yet. I fixed it with this patch two years ago: https://lists.freedesktop.org/archives/dri-devel/2018-June/179023.html But the patch never went through and the fb_defio feature was removed in the kernel 5.6 (commit d0c4fc5a4814e431c15272935c8dc973c18073aa). Without fb_defio, the only other possibility how to update the screen is the ioctl DRM_IOCTL_MODE_DIRTYFB. But this ioctl requires master mode, so user programs like "links -g" can't issue it. That's confusing. DIRTYFB is only for DRM. And why can links not run as DRM master mode? If it renders to the terminal, it should act like a composer. In that case it almost certainly wants master status. Best regards Thomas Mikulas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device specific
handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must hold the GEM
+ * object's reservation lock from when calling this function until releasing
the
+ * mapping. Holding onto a mapping and the associated reservation lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd like
to have here isn't enough. We need to roll this out at the dma-buf level,
and enforce it.
The documentation for GEM vmap callbacks point here, so it was a good
point to start.
I know about the dependencies on dmabuf. But fixing everything now is
unrealistic. My hope for this patch is that we can find the necessary
rules and document them.
Enforce it = assert_lock_held
That's probably the final step of many.
Best regards
Thomas
Roll out = review everyone. Because this goes through dma-buf it'll come
back through shmem helpers (and other helpers and other subsystems) back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
That's what I meant with that this approach here is very sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+* Notes to implementors:
+*
+* - Implementations must expect pairs of @vmap and @vunmap to be
+* called frequently and should optimize for this case.
+*
+* - Implemenations may expect the caller to hold the GEM object's
+* reservation lock to protect against concurrent calls and relocation
+* of the GEM object.
+*
+* - Implementations may provide additional guarantees (e.g., working
+* without holding the reservation lock).
+*
* This callback is optional.
+*
+* See also drm_gem_dmabuf_vmap()
*/
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
@@ -148,6 +162,8 @@ struct drm_gem_object_funcs {
* drm_gem_dmabuf_vunmap() helper.
*
* This callback is optional.
+*
+* See also @vmap.
*/
void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
--
2.29.2
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, Dec 01, 2020 at 12:52:27AM -0500, Martin K. Petersen wrote: > > Gustavo, > > > This series aims to fix almost all remaining fall-through warnings in > > order to enable -Wimplicit-fallthrough for Clang. > > Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. Awesome! :) Thanks, Martin. -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] dt-bindings: display: add Unisoc's drm master bindings
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../display/sprd/sprd,display-subsystem.yaml | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
new file mode 100644
index 000..9487a39
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc DRM master device
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ The Unisoc DRM master device is a virtual device needed to list all
+ DPU devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: sprd,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Should contain a list of phandles pointing to display interface port
+ of DPU devices.
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "sprd,display-subsystem";
+ports = <&dpu_out>;
+};
+
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings
Hi Rob, Le lun. 30 nov. 2020 à 7:32, Rob Herring a écrit : On Mon, Nov 2, 2020 at 3:19 AM Paul Cercueil wrote: Le dim. 1 nov. 2020 à 13:29, Sam Ravnborg a écrit : > On Sun, Nov 01, 2020 at 09:31:48AM +, Paul Cercueil wrote: >> The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" 320x480 >> 24-bit IPS LCD panel. Its particularity is that it has non-square >> pixels >> (as it is 4:3 for a resolution of 320x480), and that it requires odd >> lines to be sent as RGB and even lines to be sent as GRB on its >> 8-bit >> bus. >> >> Signed-off-by: Paul Cercueil >> --- >> .../display/panel/abt,y030xx067a.yaml | 54 >> +++ >> 1 file changed, 54 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> new file mode 100644 >> index ..6407e8bf45fa >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> @@ -0,0 +1,54 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: >> http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD >> panel >> + >> +description: | >> + The panel must obey the rules for a SPI slave device as >> specified in >> + spi/spi-controller.yaml >> + >> +maintainers: >> + - Paul Cercueil >> + >> +allOf: >> + - $ref: panel-common.yaml# >> + >> +properties: >> + compatible: >> +const: abt,y030xx067a >> + >> + backlight: true >> + port: true >> + power-supply: true >> + reg: true >> + reset-gpios: true > > The binding is missing: > required: > - compatible > - reg > - power-supply > - reset-gpios > - ... > > additionalProperties: false > > So r-b only with these added. Stupid mistake, sorry about that. I'll V2. I don't have any V2 in my inbox, but looks like it is in linux-next now: Yes, Sam told me on IRC I could fix it while applying and avoid the V2. /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.example.dt.yaml: panel@0: 'spi-max-frequency' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml "make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml" doesn't complain here :( -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/rockchip: vop: fix reference leak when pm_runtime_get_sync fails
pm_runtime_get_sync will increment pm usage counter even
failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: 5e570373c015 ("drm/rockchip: vop: Enable pm domain before vop_initial")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd..006988a6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -587,7 +587,7 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
struct vop *vop = to_vop(crtc);
int ret, i;
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
@@ -1908,7 +1908,7 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] dt-bindings: display: add Unisoc's drm master bindings
Hi Rob
Rob Herring 于2020年12月1日周二 上午4:29写道：
>
> On Mon, Nov 30, 2020 at 7:28 AM Kevin Tang wrote:
> >
> > From: Kevin Tang
>
> Once again, DT patches must Cc the DT list if you want them reviewed.
Ok, i will add DT list to my Cc list.
>
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> > graphics subsystem
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin Tang
> > ---
> > .../display/sprd/sprd,display-subsystem.yaml | 39
++
> > 1 file changed, 39 insertions(+)
> > create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> >
> > diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> > new file mode 100644
> > index 000..9487a39
> > --- /dev/null
> > +++
b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> > @@ -0,0 +1,39 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc DRM master device
> > +
> > +maintainers:
> > + - Kevin Tang
> > +
> > +description: |
> > + The Unisoc DRM master device is a virtual device needed to list all
> > + DPU devices or other display interface nodes that comprise the
> > + graphics subsystem.
> > +
> > +properties:
> > + compatible:
> > +const: sprd,display-subsystem
>
> As I said before, we try to avoid these virtual nodes. Make the DRM
> driver bind to the DPU node.
>
> The case where this might be needed is if you have h/w that's a
> mixture of shared and discrete blocks. I don't see anything here
> matching that.
This is how I understand this sentence: "h/w that's a mixture of shared and
discrete blocks"
We have multiple display controllers and corresponding physical interfaces,
typical dual-screen display scenario
E.g:
1. dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
2. dpu0 binding to DSI for primary display, and dpu1 binding to DP for
external display;
It looks like this:
dpu0-->MIPI-DSI-->DPHY/CPHY Combo-->Panel0
^
|
|
dpu1-->DisplayPort-->PHY-->Panel1
For DTS like this:
display-subsystem {
compatible = "sprd,display-subsystem";
ports = <&dpu0_out>, <&dpu1_out>;
};
But this is our first time submitting code to the community, following the
suggestions of other reviewers, we only submitted a basic version. Other
virtual nodes and corresponding drivers will be submitted later.
>
> Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Add Unisoc's drm kms module
ChangeList: RFC v1: 1. only upstream modeset and atomic at first commit. 2. remove some unused code; 3. use alpha and blend_mode properties; 3. add yaml support; 4. remove auto-adaptive panel driver; 5. bugfix RFC v2: 1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder 2. remove gem drivers, use generic CMA handlers 3. remove redundant "module_init", all the sub modules loading by KMS RFC v3: 1. multi crtc&encoder design have problem, so rollback to v1 RFC v4: 1. update to gcc-linaro-7.5.0 2. update to Linux 5.6-rc3 3. remove pm_runtime support 4. add COMPILE_TEST, remove unused kconfig 5. "drm_dev_put" on drm_unbind 6. fix some naming convention issue 7. remove semaphore lock for crtc flip 8. remove static variables RFC v5: 1. optimize encoder and connector code implementation 2. use "platform_get_irq" and "platform_get_resource" 3. drop useless function return type, drop unless debug log 4. custom properties should be separate, so drop it 5. use DRM_XXX replase pr_xxx 6. drop dsi&dphy hal callback ops 7. drop unless callback ops checking 8. add comments for sprd dpu structure RFC v6: 1. Access registers via readl/writel 2. Checking for unsupported KMS properties (format, rotation, blend_mode, etc) on plane_check ops 3. Remove always true checks for dpu core ops RFC v7: 1. Fix DTC unit name warnings 2. Fix the problem of maintainers 3. Call drmm_mode_config_init to mode config init 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other subsystems 6. Remove plane_update stuff, dpu handles all the HW update in crtc->atomic_flush 7. Dsi&Dphy Code structure adjustment, all move to "sprd/" v0: 1. Remove dpu_core_ops stuff layer for sprd drtc driver, but dpu_layer need to keeping. Because all the HW update in crtc->atomic_flush, we need temporary storage all layers for the dpu pageflip of atomic_flush. 2. Add ports subnode with port@X. Kevin Tang (6): dt-bindings: display: add Unisoc's drm master bindings drm/sprd: add Unisoc's drm kms master dt-bindings: display: add Unisoc's dpu bindings drm/sprd: add Unisoc's drm display controller driver dt-bindings: display: add Unisoc's mipi dsi&dphy bindings drm/sprd: add Unisoc's drm mipi dsi&dphy driver .../display/sprd/sprd,display-subsystem.yaml | 39 + .../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 ++ .../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 ++ .../display/sprd/sprd,sharkl3-dsi-phy.yaml | 84 ++ drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/sprd/Kconfig | 13 + drivers/gpu/drm/sprd/Makefile | 12 + drivers/gpu/drm/sprd/dpu_r2p0.c| 598 drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 792 +++ drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 276 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 34 + drivers/gpu/drm/sprd/megacores_pll.c | 315 + drivers/gpu/drm/sprd/megacores_pll.h | 146 ++ drivers/gpu/drm/sprd/sprd_dphy.c | 335 + drivers/gpu/drm/sprd/sprd_dphy.h | 39 + drivers/gpu/drm/sprd/sprd_dpu.c| 457 ++ drivers/gpu/drm/sprd/sprd_dpu.h| 175 +++ drivers/gpu/drm/sprd/sprd_drm.c| 265 drivers/gpu/drm/sprd/sprd_drm.h| 22 + drivers/gpu/drm/sprd/sprd_dsi.c| 1105 +++ drivers/gpu/drm/sprd/sprd_dsi.h| 105 ++ 23 files changed, 6480 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml create mode 100644 drivers/gpu/drm/sprd/Kconfig create mode 100644 drivers/gpu/drm/sprd/Makefile create mode 100644 drivers/gpu/drm/sprd/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.c create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.h create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c create mode 100644 drivers/gpu/drm/sp
[PATCH 3/6] dt-bindings: display: add Unisoc's dpu bindings
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 ++
1 file changed, 83 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
new file mode 100644
index 000..a9052e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc Sharkl3 Display Processor Unit (DPU)
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
+ which transfers the image data from a video memory buffer to an internal
+ LCD interface.
+
+properties:
+ compatible:
+const: sprd,sharkl3-dpu
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the DPU registers set
+
+ interrupts:
+maxItems: 1
+description:
+ The interrupt signal from DPU
+
+ clocks:
+minItems: 2
+
+ clock-names:
+items:
+ - const: clk_src_128m
+ - const: clk_src_384m
+
+ power-domains:
+maxItems: 1
+description: A phandle to DPU power domain node.
+
+ iommus:
+maxItems: 1
+description: A phandle to DPU iommu node.
+
+ port:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DSI.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dpu: dpu@6300 {
+compatible = "sprd,sharkl3-dpu";
+reg = <0x6300 0x1000>;
+interrupts = ;
+clock-names = "clk_src_128m", "clk_src_384m";
+
+clocks = <&pll CLK_TWPLL_128M>,
+ <&pll CLK_TWPLL_384M>;
+
+dpu_port: port {
+dpu_out: endpoint {
+remote-endpoint = <&dsi_in>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings
Le lun. 30 nov. 2020 à 13:18, Rob Herring a écrit : On Mon, Nov 30, 2020 at 12:39 PM Paul Cercueil wrote: Hi Rob, Le lun. 30 nov. 2020 à 7:32, Rob Herring a écrit : > On Mon, Nov 2, 2020 at 3:19 AM Paul Cercueil > wrote: >> >> >> >> Le dim. 1 nov. 2020 à 13:29, Sam Ravnborg a >> écrit : >> > On Sun, Nov 01, 2020 at 09:31:48AM +, Paul Cercueil wrote: >> >> The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" >> 320x480 >> >> 24-bit IPS LCD panel. Its particularity is that it has >> non-square >> >> pixels >> >> (as it is 4:3 for a resolution of 320x480), and that it >> requires odd >> >> lines to be sent as RGB and even lines to be sent as GRB on its >> >> 8-bit >> >> bus. >> >> >> >> Signed-off-by: Paul Cercueil >> >> --- >> >> .../display/panel/abt,y030xx067a.yaml | 54 >> >> +++ >> >> 1 file changed, 54 insertions(+) >> >> create mode 100644 >> >> >> Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> >> >> >> diff --git >> >> >> a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> >> >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> >> new file mode 100644 >> >> index ..6407e8bf45fa >> >> --- /dev/null >> >> +++ >> >> >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml >> >> @@ -0,0 +1,54 @@ >> >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> >> +%YAML 1.2 >> >> +--- >> >> +$id: >> >> http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml# >> >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> >> + >> >> +title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS >> LCD >> >> panel >> >> + >> >> +description: | >> >> + The panel must obey the rules for a SPI slave device as >> >> specified in >> >> + spi/spi-controller.yaml >> >> + >> >> +maintainers: >> >> + - Paul Cercueil >> >> + >> >> +allOf: >> >> + - $ref: panel-common.yaml# >> >> + >> >> +properties: >> >> + compatible: >> >> +const: abt,y030xx067a >> >> + >> >> + backlight: true >> >> + port: true >> >> + power-supply: true >> >> + reg: true >> >> + reset-gpios: true >> > >> > The binding is missing: >> > required: >> > - compatible >> > - reg >> > - power-supply >> > - reset-gpios >> > - ... >> > >> > additionalProperties: false >> > >> > So r-b only with these added. >> >> Stupid mistake, sorry about that. >> >> I'll V2. > > I don't have any V2 in my inbox, but looks like it is in linux-next > now: Yes, Sam told me on IRC I could fix it while applying and avoid the V2. > /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.example.dt.yaml: > panel@0: 'spi-max-frequency' does not match any of the regexes: > 'pinctrl-[0-9]+' > From schema: > /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml "make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml" doesn't complain here :( Even if you do 'touch Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml' or do a clean build? I can't think of any kernel or dt-schema changes which would explain the difference. This is purely related to 'additionalProperties: false'. Ok, I see it now. Should I use 'unevaluatedProperties: false' instead? -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/rockchip: cdn-dp: fix reference leak when pm_runtime_get_sync fails
pm_runtime_get_sync will increment pm usage counter even
failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: efe0220fc2d2 ("drm/rockchip: cdn-dp: Fix error handling")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf9..9b4406191 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -98,7 +98,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_resume_and_get(dp->dev);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/mipi-dbi: Type B bus support, drm/tiny: MRB2801
From: Mikhail Durnev Hi All, This patch series is aiming at extending the mipi-dbi bus driver to support Intel 8080 type parallel bus (Type B) over GPIO and adding a new driver for ILI9341 display panels with 8- or 16-bit parallel interface. It was tested with the MRB2801 display module [1] that had a connector compatible with the ALIENTEK STM32 development board. The module was connected to Raspberry Pi 3 via GPIO pins. The parallel bus is implemented partially. It supports only write operations from the host to the display. Read operations would require switching GPIO mode between input and output back and forth. But this implementation is very simple, and GPIO mode can be set for all used pins to output once at initialization. The RD pin of the display has to always receive the logic high signal to make sure the data bus pins from the dislay side are always in the high impedance state. Otherwise the display module as well as the GPIO controller of the host can be damaged. To be on the safe side I recommend using protective resistors for all GPIO pins conneced to DB pins of the display. Resistors of 10 kOhms are just fine for RPi 3. The WR and DC pins may not work well with 10K resistors. Although there is no need to protect them, you can try using 1K resistors if you want. Bit banging is used to transmit data over the parallel bus from host to display. There are two numbers that contol timings. They should be defined in the device tree via the wr-up-down-delays property. The first number is related to the write control pulse duration, and the second number is related to the write cycle duration. For ILI9341, the write pulse cannot be shorter than 15 ns, and the write duration cannot be shorter than 66 ns. Delays of 10 and 51 ns respectively allow to meet the specifications on RPi 3. Faster machines may need values closer to 15 and 66. [1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801 Signed-off-by: Mikhail Durnev v1 -> v2: - Moved the definition of mipi_dbi_machine_little_endian() out of the "#if IS_ENABLED(CONFIG_SPI)" clause. That static function is used in mipi_dbi_gpio_init which does not need CONFIG_SPI enabled v0 -> v1: - Rebased on v5.10-rc6 - Replaced "dbi->spi = 0;" with "dbi->spi = NULL;" in mipi_dbi_gpio_init v0: - Based on branch rpi-5.10.y - Tested on Raspberry Pi 3 Model B V 1.2 Mikhail Durnev (3): drm/mipi-dbi: Add support for Type B drm/tiny: Add driver for ili9341 with parallel bus dt-bindings: panel: Add bindings for MRB2801 .../devicetree/bindings/display/ronbo,mrb2801.txt | 42 +++ drivers/gpu/drm/drm_mipi_dbi.c | 134 +- drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9341_gpio.c| 290 + include/drm/drm_mipi_dbi.h | 30 ++- 6 files changed, 499 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/rockchip: fix reference leak of pm_runtime_get_sync
Replace pm_runtime_get_sync with pm_runtime_resume_and_get to keep usage counter balanced. Qinglang Miao (3): drm/rockchip: cdn-dp: fix reference leak when pm_runtime_get_sync fails drm/rockchip: vop: fix reference leak when pm_runtime_get_sync fails drm/rockchip: lvds: fix reference leak when pm_runtime_get_sync fails drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++-- drivers/gpu/drm/rockchip/rockchip_lvds.c| 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support
On Fri, Nov 27, 2020 at 12:55:41PM -0800, Jianxin Xiong wrote:
>
> +function(rdma_multifile_module PY_MODULE MODULE_NAME LINKER_FLAGS)
I think just replace rdma_cython_module with this? No good reason I
can see to have two APIs?
> + set(ALL_CFILES "")
> + foreach(SRC_FILE ${ARGN})
> +get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
> +get_filename_component(DIR ${SRC_FILE} DIRECTORY)
> +get_filename_component(EXT ${SRC_FILE} EXT)
> +if (DIR)
> + set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
> +else()
> + set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> +endif()
> +if (${EXT} STREQUAL ".pyx")
> + set(PYX "${SRC_PATH}/${FILENAME}.pyx")
> + set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
> + include_directories(${PYTHON_INCLUDE_DIRS})
> + add_custom_command(
> +OUTPUT "${CFILE}"
> +MAIN_DEPENDENCY "${PYX}"
> +COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
> +"-I${PYTHON_INCLUDE_DIRS}"
> +COMMENT "Cythonizing ${PYX}"
> + )
> + set(ALL_CFILES "${ALL_CFILES};${CFILE}")
> +elseif(${EXT} STREQUAL ".c")
> + set(CFILE_ORIG "${SRC_PATH}/${FILENAME}.c")
> + set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
> + if (NOT ${CFILE_ORIG} STREQUAL ${CFILE})
> +rdma_create_symlink("${CFILE_ORIG}" "${CFILE}")
> + endif()
Why does this need the create_symlink? The compiler should work OK
from the source file?
> + set(ALL_CFILES "${ALL_CFILES};${CFILE}")
> +elseif(${EXT} STREQUAL ".h")
> + set(HFILE_ORIG "${SRC_PATH}/${FILENAME}.h")
> + set(HFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.h")
> + if (NOT ${HFILE_ORIG} STREQUAL ${HFILE})
> +rdma_create_symlink("${HFILE_ORIG}" "${HFILE}")
Here too? You probably don't need to specify h files at all, at worst
they should only be used with publish_internal_headers
> + endif()
> +else()
> + continue()
> +endif()
> + endforeach()
> + string(REGEX REPLACE "\\.so$" "" SONAME
> "${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
> + add_library(${SONAME} SHARED ${ALL_CFILES})
> + set_target_properties(${SONAME} PROPERTIES
> +COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
> -Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
> -Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
> -Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
Ugh, you copy and pasted this, but it shouldn't have existed in the
first place. Compiler arguments like this should not be specified
manually. I should fix it..
Also you should cc edward on all this pyverbs stuff, he knows it all
very well
It all looks reasonable to me
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/19] dt-bindings: memory: tegra20: emc: Document opp-supported-hw property
30.11.2020 21:23, Krzysztof Kozlowski пишет: > On Mon, Nov 30, 2020 at 11:48:18AM +0200, Georgi Djakov wrote: >> On 23.11.20 2:27, Dmitry Osipenko wrote: >>> Document opp-supported-hw property, which is not strictly necessary to >>> have on Tegra20, but it's very convenient to have because all other SoC >>> core devices will use hardware versioning, and thus, it's good to maintain >>> the consistency. >> >> Hi Dmitry, >> >> I believe Krzysztof is waiting for Ack on the binding before merging >> this patch (and the rest), but unfortunately it was not sent to the >> DT mailing list for review. Good catch, thank you. > Indeed I am still waiting for Rob's and Thierry's acks for this and the > following patches. It has been just a week so I'll give it few more > days. Rob doesn't review patches which aren't sent to the DT ML, which isn't cc'ed in v10 by accident. I'll make v11. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/sprd: add Unisoc's drm display controller driver
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. Cc: Orson Zhai Cc: Chunyan Zhang Signed-off-by: Kevin Tang --- drivers/gpu/drm/sprd/Kconfig| 1 + drivers/gpu/drm/sprd/Makefile | 6 +- drivers/gpu/drm/sprd/dpu_r2p0.c | 598 drivers/gpu/drm/sprd/sprd_dpu.c | 457 ++ drivers/gpu/drm/sprd/sprd_dpu.h | 175 drivers/gpu/drm/sprd/sprd_drm.c | 1 + drivers/gpu/drm/sprd/sprd_drm.h | 2 + 7 files changed, 1238 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/sprd/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig index 6e80cc9..9b4ef9a 100644 --- a/drivers/gpu/drm/sprd/Kconfig +++ b/drivers/gpu/drm/sprd/Kconfig @@ -3,6 +3,7 @@ config DRM_SPRD depends on ARCH_SPRD || COMPILE_TEST depends on DRM && OF select DRM_KMS_HELPER + select VIDEOMODE_HELPERS select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER select DRM_MIPI_DSI diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile index 86d95d9..0ba48f2 100644 --- a/drivers/gpu/drm/sprd/Makefile +++ b/drivers/gpu/drm/sprd/Makefile @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 -subdir-ccflags-y += -I$(srctree)/$(src) +obj-y := sprd_drm.o \ + sprd_dpu.o + +obj-y += dpu_r2p0.o -obj-y := sprd_drm.o diff --git a/drivers/gpu/drm/sprd/dpu_r2p0.c b/drivers/gpu/drm/sprd/dpu_r2p0.c new file mode 100644 index 000..46ab8b3 --- /dev/null +++ b/drivers/gpu/drm/sprd/dpu_r2p0.c @@ -0,0 +1,598 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Unisoc Inc. + */ + +#include +#include +#include +#include + +#include "sprd_dpu.h" + +/* Global control registers */ +#define REG_DPU_CTRL 0x04 +#define REG_DPU_CFG0 0x08 +#define REG_DPU_CFG1 0x0C +#define REG_DPU_CFG2 0x10 +#define REG_PANEL_SIZE 0x20 +#define REG_BLEND_SIZE 0x24 +#define REG_BG_COLOR 0x2C + +/* Layer0 control registers */ +#define REG_LAY_BASE_ADDR0 0x30 +#define REG_LAY_BASE_ADDR1 0x34 +#define REG_LAY_BASE_ADDR2 0x38 +#define REG_LAY_CTRL 0x40 +#define REG_LAY_SIZE 0x44 +#define REG_LAY_PITCH 0x48 +#define REG_LAY_POS0x4C +#define REG_LAY_ALPHA 0x50 +#define REG_LAY_PALLETE0x58 +#define REG_LAY_CROP_START 0x5C + +/* Interrupt control registers */ +#define REG_DPU_INT_EN 0x1E0 +#define REG_DPU_INT_CLR0x1E4 +#define REG_DPU_INT_STS0x1E8 + +/* DPI control registers */ +#define REG_DPI_CTRL 0x1F0 +#define REG_DPI_H_TIMING 0x1F4 +#define REG_DPI_V_TIMING 0x1F8 + +/* MMU control registers */ +#define REG_MMU_EN 0x800 +#define REG_MMU_VPN_RANGE 0x80C +#define REG_MMU_VAOR_ADDR_RD 0x818 +#define REG_MMU_VAOR_ADDR_WR 0x81C +#define REG_MMU_INV_ADDR_RD0x820 +#define REG_MMU_INV_ADDR_WR0x824 +#define REG_MMU_PPN1 0x83C +#define REG_MMU_RANGE1 0x840 +#define REG_MMU_PPN2 0x844 +#define REG_MMU_RANGE2 0x848 + +/* Global control bits */ +#define BIT_DPU_RUNBIT(0) +#define BIT_DPU_STOP BIT(1) +#define BIT_DPU_REG_UPDATE BIT(2) +#define BIT_DPU_IF_EDPIBIT(0) +#define BIT_DPU_COEF_NARROW_RANGE BIT(4) +#define BIT_DPU_Y2R_COEF_ITU709_STANDARD BIT(5) + +/* Layer control bits */ +#define BIT_DPU_LAY_EN BIT(0) +#define BIT_DPU_LAY_LAYER_ALPHA(0x01 << 2) +#define BIT_DPU_LAY_COMBO_ALPHA(0x02 << 2) +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_2PLANE (0x01 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4) +#define BIT_DPU_LAY_FORMAT_ARGB(0x03 << 4) +#define BIT_DPU_LAY_FORMAT_RGB565 (0x04 << 4) +#define BIT_DPU_LAY_DATA_ENDIAN_B0B1B2B3 (0x00 << 8) +#define BIT_DPU_LAY_DATA_ENDIAN_B3B2B1B0 (0x01 << 8) +#define BIT_DPU_LAY_NO_SWITCH (0x00 << 10) +#define BIT_DPU_LAY_RB_OR_UV_SWITCH(0x01 << 10) +#define BIT_DPU_LAY_MODE_BLEND_NORMAL (0x00 << 16) +#define BIT_DPU_LAY_MODE_BLEND_PREMULT (0x01 << 16) + +/* Interrupt control & status bits */ +#define BIT_DPU_INT_DONE BIT(0) +#define BIT_DPU_INT_TE BIT(1) +#define BIT_DPU_INT_ERRBIT(2) +#define BIT_DPU_INT_UPDATE_DONEBIT(4) +#define BIT_DPU_INT_VSYNC BIT(5) +#define BIT_DPU_INT_FBC_PLD_ERR
Re: [PATCH] drm/panfrost: fix reference leak in panfrost_job_hw_submit
在 2020/11/27 18:06, Steven Price 写道:
On 27/11/2020 09:44, Qinglang Miao wrote:
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal
with usage counter")
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 30e7b7196..04cf3bb67 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -147,7 +147,7 @@ static void panfrost_job_hw_submit(struct
panfrost_job *job, int js)
panfrost_devfreq_record_busy(&pfdev->pfdevfreq);
- ret = pm_runtime_get_sync(pfdev->dev);
+ ret = pm_runtime_resume_and_get(pfdev->dev);
Sorry, but in this case this change isn't correct.
panfrost_job_hw_submit() is expected to be unbalanced (the PM reference
count is expected to be incremented on return).
In the case where pm_runtime_get_sync() fails, the job will eventually
timeout, and there's a corresponding pm_runtime_put_noidle() in
panfrost_reset().
Potentially this could be handled better (e.g. without waiting for the
timeout to occur), but equally this isn't something we expect to happen
in normal operation).
Steve
Sorry, I didn't notice the pm_runtime_put_noidle() in
panfrost_job_timedout() before.
Thanks for your reply.
if (ret < 0)
return;
.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/mipi-dbi: Add support for Type B
From: Mikhail Durnev
Intel 8080 type (Type B) parallel bus over GPIO.
The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
It is enough to support only write operations to initialize displays
and output video data. The bus driver returns EOPNOTSUPP for all read
operations requested through a display driver.
Bit banging is used to transmit data over the parallel bus from host
to display. There are two numbers that contol timings: wr_up_delay
and wr_down_delay. They should be provided by the display driver.
The first number is related to the write control pulse duration, and
the second number is related to the write cycle duration that can
be found in the specification of the display.
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/drm_mipi_dbi.c | 134 ++---
include/drm/drm_mipi_dbi.h | 30 -
2 files changed, 153 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd..3edb041 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -61,7 +61,7 @@
*3. 8-bit with the Data/Command signal as a separate D/CX pin
*
* Currently mipi_dbi only supports Type C options 1 and 3 with
- * mipi_dbi_spi_init().
+ * mipi_dbi_spi_init() and Type B with mipi_dbi_gpio_init().
*/
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
@@ -701,6 +701,15 @@ int mipi_dbi_poweron_conditional_reset(struct mipi_dbi_dev
*dbidev)
}
EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);
+static bool mipi_dbi_machine_little_endian(void)
+{
+#if defined(__LITTLE_ENDIAN)
+ return true;
+#else
+ return false;
+#endif
+}
+
#if IS_ENABLED(CONFIG_SPI)
/**
@@ -721,15 +730,6 @@ u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi,
size_t len)
}
EXPORT_SYMBOL(mipi_dbi_spi_cmd_max_speed);
-static bool mipi_dbi_machine_little_endian(void)
-{
-#if defined(__LITTLE_ENDIAN)
- return true;
-#else
- return false;
-#endif
-}
-
/*
* MIPI DBI Type C Option 1
*
@@ -1158,6 +1158,120 @@ EXPORT_SYMBOL(mipi_dbi_spi_transfer);
#endif /* CONFIG_SPI */
+/*
+ * This function implements data transfer only from host to display.
+ */
+static void mipi_dbi_gpio_transfer(struct mipi_dbi *dbi, u16 data)
+{
+ unsigned long ldata = data;
+
+ /*
+* Set W/R to low to start transfer.
+* Set DB bits with provided data when W/R is low.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 0);
+ gpiod_set_array_value_cansleep(dbi->db->ndescs, dbi->db->desc,
+ dbi->db->info, &ldata);
+
+ /*
+* The bus usually needs additional delay.
+*/
+ ndelay(dbi->wr_up_delay);
+
+ /*
+* Set W/R to high to indicate that DB lines are set.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 1);
+
+ /*
+* The connected display needs some time to read the data.
+*/
+ ndelay(dbi->wr_down_delay);
+}
+
+static int mipi_dbi_gpio_command(struct mipi_dbi *dbi, u8 *cmd,
+ u8 *par, size_t num)
+{
+ int i;
+
+ /*
+* Read commands are not currently supported.
+*/
+ if (mipi_dbi_command_is_read(dbi, *cmd))
+ return -EOPNOTSUPP;
+
+ MIPI_DBI_DEBUG_COMMAND(*cmd, par, num);
+
+ gpiod_set_value_cansleep(dbi->dc, 0);
+ mipi_dbi_gpio_transfer(dbi, (u16)*cmd);
+ gpiod_set_value_cansleep(dbi->dc, 1);
+
+ if (dbi->db->ndescs == 16 &&
+ (*cmd == MIPI_DCS_WRITE_MEMORY_START ||
+*cmd == MIPI_DCS_WRITE_MEMORY_CONTINUE)) {
+ /*
+* Only a couple of commands supports 16-bit transfer.
+*/
+ for (i = 0; i < num; i += 2) {
+ u16 data = *(u16 *)&par[i];
+
+ if (dbi->swap_bytes)
+ data = (data >> 8) | (data << 8);
+
+ mipi_dbi_gpio_transfer(dbi, data);
+ }
+ } else {
+ for (i = 0; i < num; i++) {
+ /*
+* Other commands ignore most significant bits.
+*/
+ mipi_dbi_gpio_transfer(dbi, (u16)par[i]);
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface implemented via
GPIO
+ * @dbi: MIPI DBI structure to initialize
+ * @dc: D/C gpio
+ * @wr: W/R gpio
+ * @db: DB gpios
+ * @wr_up_delay: Delay after setting DB and before changing W/R from low to
high
+ * @wr_down_delay: Delay after changing W/R from low to high
+ *
+ * This function sets &mipi_dbi->command, enable
[PATCH v5] drm/bridge: add it6505 driver
This adds support for the iTE IT6505. This device can convert DPI signal to DP output. From: Allen Chen Signed-off-by: Jitao Shi Signed-off-by: Pi-Hsun Shih Signed-off-by: Yilun Lin Signed-off-by: Hermes Wu Signed-off-by: Allen Chen --- drivers/gpu/drm/bridge/Kconfig |7 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++ 3 files changed, 3351 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3c..25d34d7196004 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT6505 + tristate "ITE IT6505 DisplayPort bridge" + depends on OF + select DRM_KMS_HELPER + help + ITE IT6505 DisplayPort bridge chip driver. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d6..2b2f8f0b5b0fa 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += megachips-stdp-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c new file mode 100644 index 0..e4251c69fc991 --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it6505.c @@ -0,0 +1,3343 @@ +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define REG_IC_VER 0x04 + +#define REG_RESET_CTRL 0x05 +#define VIDEO_RESET BIT(0) +#define AUDIO_RESET BIT(1) +#define ALL_LOGIC_RESET BIT(2) +#define AUX_RESET BIT(3) +#define HDCP_RESET BIT(4) + +#define INT_STATUS_01 0x06 +#define INT_MASK_01 0x09 +#define INT_HPD_CHANGE BIT(0) +#define INT_RECEIVE_HPD_IRQ BIT(1) +#define INT_SCDT_CHANGE BIT(2) +#define INT_HDCP_FAIL BIT(3) +#define INT_HDCP_DONE BIT(4) + +#define INT_STATUS_02 0x07 +#define INT_MASK_02 0x0A +#define INT_AUX_CMD_FAIL BIT(0) +#define INT_HDCP_KSV_CHECK BIT(1) +#define INT_AUDIO_FIFO_ERROR BIT(2) + +#define INT_STATUS_03 0x08 +#define INT_MASK_03 0x0B +#define INT_LINK_TRAIN_FAIL BIT(4) +#define INT_VID_FIFO_ERROR BIT(5) +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) + +#define REG_SYSTEM_STS 0x0D +#define INT_STS BIT(0) +#define HPD_STS BIT(1) +#define VIDEO_STB BIT(2) + +#define REG_LINK_TRAIN_STS 0x0E +#define LINK_STATE_CR BIT(2) +#define LINK_STATE_EQ BIT(3) +#define LINK_STATE_NORP BIT(4) + +#define REG_BANK_SEL 0x0F +#define REG_CLK_CTRL0 0x10 +#define M_PCLK_DELAY 0x03 + +#define REG_AUX_OPT 0x11 +#define AUX_AUTO_RST BIT(0) +#define AUX_FIX_FREQ BIT(3) + +#define REG_DATA_CTRL0 0x12 +#define VIDEO_LATCH_EDGE BIT(4) +#define ENABLE_PCLK_COUNTER BIT(7) + +#define REG_PCLK_COUNTER_VALUE 0x13 + +#define REG_501_FIFO_CTRL 0x15 +#define RST_501_FIFO BIT(1) + +#define REG_TRAIN_CTRL0 0x16 +#define FORCE_LBR BIT(0) +#define LANE_COUNT_MASK 0x06 +#define LANE_SWAP BIT(3) +#define SPREAD_AMP_5 BIT(4) +#define FORCE_CR_DONE BIT(5) +#define FORCE_EQ_DONE BIT(6) + +#define REG_TRAIN_CTRL1 0x17 +#define AUTO_TRAIN BIT(0) +#define MANUAL_TRAIN BIT(1) +#define FORCE_RETRAIN BIT(2) + +#define REG_AUX_CTRL 0x23 +#define CLR_EDID_FIFO BIT(0) +#define AUX_USER_MODE BIT(1) +#define AUX_NO_SEGMENT_WR BIT(6) +#define AUX_EN_FIFO_READ BIT(7) + +#define REG_AUX_ADR_0_7 0x24 +#define REG_AUX_ADR_8_15 0x25 +#define REG_AUX_ADR_16_19 0x26 +#define REG_AUX_OUT_DATA0 0x27 + +#define REG_AUX_CMD_REQ 0x2B +#define AUX_BUSY BIT(5) + +#define REG_AUX_DATA_0_7 0x2C +#define REG_AUX_DATA_8_15 0x2D +#define REG_AUX_DATA_16_23 0x2E +#define REG_AUX_DATA_24_31 0x2F + +#define REG_AUX_DATA_FIFO 0x2F + +#define REG_AUX_ERROR_STS 0x9F +#define M_AUX_REQ_FAIL 0x03 + +#define REG_HDCP_CTRL1 0x38 +#define HDCP_CP_ENABLE BIT(0) + +#define REG_HDCP_TRIGGER 0x39 +#define HDCP_TRIGGER_START BIT(0) +#define HDCP_TRIGGER_CPIRQ BIT(1) +#define HDCP_TRIGGER_KSV_DONE BIT(4) +#define HDCP_TRIGGER_KSV_FAIL BIT(5) + +#define REG_HDCP_CTRL2 0x3A +#define HDCP_AN_SEL BIT(0) +#define
Re: [PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support
On Mon, Nov 30, 2020 at 03:57:41PM +0100, Daniel Vetter wrote: > > + err = ioctl(dri->fd, DRM_IOCTL_AMDGPU_GEM_CREATE, &gem_create); > > + if (err) > > + return err; > > + > > + *handle = gem_create.out.handle; > > + return 0; > > +} > > + > > +static int radeon_alloc(struct dri *dri, size_t size, uint32_t *handle) > > Tbh radeon chips are old enough I wouldn't care. Also doesn't support p2p > dma-buf, so always going to be in system memory when you share. Plus you > also need some more flags like I suggested above I think. What about nouveau? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/rockchip: lvds: fix reference leak when pm_runtime_get_sync fails
pm_runtime_get_sync will increment pm usage counter even
failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
Fixes: cca1705c3d89 ("drm/rockchip: lvds: Add PX30 support")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index f292c6a6e..c3b1ac484 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -145,7 +145,7 @@ static int rk3288_lvds_poweron(struct rockchip_lvds *lvds)
DRM_DEV_ERROR(lvds->dev, "failed to enable lvds pclk %d\n",
ret);
return ret;
}
- ret = pm_runtime_get_sync(lvds->dev);
+ ret = pm_runtime_resume_and_get(lvds->dev);
if (ret < 0) {
DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
clk_disable(lvds->pclk);
@@ -329,7 +329,7 @@ static int px30_lvds_poweron(struct rockchip_lvds *lvds)
{
int ret;
- ret = pm_runtime_get_sync(lvds->dev);
+ ret = pm_runtime_resume_and_get(lvds->dev);
if (ret < 0) {
DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sprd/Makefile |9 +-
drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 792 +
drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 276 ++
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 34 +
drivers/gpu/drm/sprd/megacores_pll.c | 315 +++
drivers/gpu/drm/sprd/megacores_pll.h | 146
drivers/gpu/drm/sprd/sprd_dphy.c | 335
drivers/gpu/drm/sprd/sprd_dphy.h | 39 +
drivers/gpu/drm/sprd/sprd_drm.c| 42 +
drivers/gpu/drm/sprd/sprd_drm.h|4 +
drivers/gpu/drm/sprd/sprd_dsi.c| 1105
drivers/gpu/drm/sprd/sprd_dsi.h| 105 +++
13 files changed, 4675 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
index 0ba48f2..75d6a519 100644
--- a/drivers/gpu/drm/sprd/Makefile
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -1,7 +1,12 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := sprd_drm.o \
- sprd_dpu.o
+ sprd_dpu.o \
+ sprd_dsi.o \
+ sprd_dphy.o \
+ dpu_r2p0.o \
+ dw_dsi_ctrl.o \
+ dw_dsi_ctrl_ppi.o \
+ megacores_pll.o
-obj-y += dpu_r2p0.o
diff --git a/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
new file mode 100644
index 000..1470d7d
--- /dev/null
+++ b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
@@ -0,0 +1,792 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "dw_dsi_ctrl.h"
+
+/*
+ * Modify power status of DSI Host core
+ */
+void dsi_power_enable(struct dsi_context *ctx, int enable)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(enable, ®->SOFT_RESET);
+}
+/*
+ * Enable/disable DPI video mode
+ */
+void dsi_video_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(0, ®->DSI_MODE_CFG);
+}
+/*
+ * Enable command mode (Generic interface)
+ */
+void dsi_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(1, ®->DSI_MODE_CFG);
+}
+
+bool dsi_is_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ return readl(®->DSI_MODE_CFG);
+}
+/*
+ * Configure the read back virtual channel for the generic interface
+ */
+void dsi_rx_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.gen_rx_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Write the DPI video virtual channel destination
+ */
+void dsi_video_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.video_pkt_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Set DPI video mode type (burst/non-burst - with sync pulses or events)
+ */
+void dsi_dpi_video_burst_mode(struct dsi_context *ctx, int mode)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x38 vid_mode_cfg;
+
+ vid_mode_cfg.val = readl(®->VID_MODE_CFG);
+ vid_mode_cfg.bits.vid_mode_type = mode;
+
+ writel(vid_mode_cfg.val, ®->VID_MODE_CFG);
+}
+/*
+ * Set DPI video color coding
+ */
+void dsi_dpi_color_coding(struct dsi_context *ctx, int coding)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x20 dpi_video_format;
+
+ dpi_video_format.val = readl(®->DPI_VIDEO_FORMAT);
+ dpi_video_format.bits.dpi_video_mode_format = coding;
+
+ writel(dpi_video_format.val, ®->DPI_VIDEO_FORMAT);
+}
+/*
+ * Configure the Horizontal Line time
+ * param "byte_cycle" taken to transmit the total of the horizontal line
+ */
+void dsi_dpi_hline_time(struct dsi_context *ctx, u16 byte_cycle)
+{
+
Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"
On 11/24/20 12:57 PM, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA processing on the Lenovo Yoga C630")'.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index dce75b85253c..046d241183c5 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -353,13 +353,11 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> {
> dma_addr_t rx_dma;
> unsigned long time_left;
> - void *dma_buf = NULL;
> + void *dma_buf;
> struct geni_se *se = &gi2c->se;
> size_t len = msg->len;
>
> - if (!of_machine_is_compatible("lenovo,yoga-c630"))
> - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> -
> + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> if (dma_buf)
> geni_se_select_mode(se, GENI_SE_DMA);
> else
> @@ -394,13 +392,11 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev
> *gi2c, struct i2c_msg *msg,
> {
> dma_addr_t tx_dma;
> unsigned long time_left;
> - void *dma_buf = NULL;
> + void *dma_buf;
> struct geni_se *se = &gi2c->se;
> size_t len = msg->len;
>
> - if (!of_machine_is_compatible("lenovo,yoga-c630"))
> - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> -
> + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> if (dma_buf)
> geni_se_select_mode(se, GENI_SE_DMA);
> else
Tested-by: Steev Klimaszewski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
Hi Ivaylo,
> Am 27.11.2020 um 19:44 schrieb Ivaylo Dimitrov :
>
> Hi,
>
> On 27.11.20 г. 19:30 ч., Tomi Valkeinen wrote:
>> On 27/11/2020 17:37, Ivaylo Dimitrov wrote:
>>> With 5.9.11 and the patch on top, n900 boots fine, albeit display remains
>>> blank, could be related to
>>> brightness, we're still investigating.
>> Ok. A DSS regdump for a working version and the latest one would be good
>> too. There's a omapdss
>> debugfs dir, with dss, dispc and clk files which are of interest here.
>
> It turned out to be a long standing bug in the panel driver, with the bellow
> fix it works fine:
>
>
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> index fc6a7e451abe..304267f7849a
> --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> @@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
>lcd->spi = spi;
>mutex_init(&lcd->mutex);
>
> - lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
> + lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH);
>if (IS_ERR(lcd->reset_gpio)) {
>dev_err(&spi->dev, "failed to get reset GPIO\n");
>return PTR_ERR(lcd->reset_gpio);
>
> Proper patch will follow.
I just found another issue which seems to hit a handful of SPI based panel
drivers,
for example the panel-tpo-td028ttec1.
It is commit
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
which breaks our DM3730 based GTA04 panel
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c.
It may also affect other SPI based drivers if they are operated though spi-gpio
(I would
have to look up the N900 hardware setup).
BR,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports
To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
have dual LVDS ports and require only a single power-supply.
The first port receives odd pixels, and the second port receives even pixels.
Optionally, a backlight and an enable GPIO can be specified as properties.
Panels with swapped pixel order, if any, need dedicated bindings.
Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
The objectives with one file for all the simple LVDS panels with dual ports are:
- Make it simpler to add bindings for this kind of LVDS panels
- Keep the number of bindings file lower
- Keep the binding documentation for this kind of LVDS panels more consistent
- Make it possible for drivers to get pixel order via
drm_of_lvds_get_dual_link_pixel_order(), as the 'ports' property is required
Suggested-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Lucas Stach
Cc: Sebastian Reichel
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v4->v5:
* Require the 'ports' property and update commit message accordingly. (Rob)
* Add Rob's R-b tag.
v3->v4:
* Add type and descriptions for dual-lvds-{odd,even}-pixels properties.
Also, update descriptions for port@0 and port@1 properties accordingly. (Rob)
v2->v3:
* Do not allow 'port' property. (Rob)
* Define port number. (Rob)
* Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' properties. (Rob)
v1->v2:
* Correct pixel order in example LVDS panel node.
.../panel/panel-simple-lvds-dual-ports.yaml| 131 +
.../bindings/display/panel/panel-simple.yaml | 10 --
2 files changed, 131 insertions(+), 10 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
new file mode 100644
index ..b43bafd
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple LVDS panels with one power supply and dual LVDS ports
+
+maintainers:
+ - Liu Ying
+ - Thierry Reding
+ - Sam Ravnborg
+
+description: |
+ This binding file is a collection of the LVDS panels that
+ has dual LVDS ports and requires only a single power-supply.
+ The first port receives odd pixels, and the second port receives even pixels.
+ There are optionally a backlight and an enable GPIO.
+ The panel may use an OF graph binding for the association to the display,
+ or it may be a direct child node of the display.
+
+ If the panel is more advanced a dedicated binding file is required.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+
+ compatible:
+enum:
+# compatible must be listed in alphabetical order, ordered by compatible.
+# The description in the comment is mandatory for each compatible.
+
+# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
+ - auo,g133han01
+# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
+ - auo,g185han01
+# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
+# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT
LCD panel
+ - koe,tx26d202vm0bwa
+# NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
+ - nlt,nl192108ac18-02d
+
+ ports:
+type: object
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ port@0:
+type: object
+description: The first sink port.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels:
+type: boolean
+description: The first sink port for odd pixels.
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The second sink port.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels:
+type: boolean
+description: The second sink port for even pixels.
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+ backlight: true
+ enable-gpios: true
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - ports
+ - power-supply
+
+examples:
+ - |
+pa
[PATCH 2/6] drm/sprd: add Unisoc's drm kms master
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS test tool) and Android HWComposer.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/sprd/Kconfig| 12 +++
drivers/gpu/drm/sprd/Makefile | 5 +
drivers/gpu/drm/sprd/sprd_drm.c | 222
drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
6 files changed, 258 insertions(+)
create mode 100644 drivers/gpu/drm/sprd/Kconfig
create mode 100644 drivers/gpu/drm/sprd/Makefile
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b..15b4e13 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -388,6 +388,8 @@ source "drivers/gpu/drm/tidss/Kconfig"
source "drivers/gpu/drm/xlnx/Kconfig"
+source "drivers/gpu/drm/sprd/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8156900..d3001e7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
obj-$(CONFIG_DRM_MCDE) += mcde/
obj-$(CONFIG_DRM_TIDSS) += tidss/
obj-y += xlnx/
+obj-$(CONFIG_DRM_SPRD) += sprd/
diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
new file mode 100644
index 000..6e80cc9
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Kconfig
@@ -0,0 +1,12 @@
+config DRM_SPRD
+ tristate "DRM Support for Unisoc SoCs Platform"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on DRM && OF
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DSI
+ help
+ Choose this option if you have a Unisoc chipset.
+ If M is selected the module will be called sprd_drm.
+
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
new file mode 100644
index 000..86d95d9
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+subdir-ccflags-y += -I$(srctree)/$(src)
+
+obj-y := sprd_drm.o
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
new file mode 100644
index 000..ec101de
--- /dev/null
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sprd_drm.h"
+
+#define DRIVER_NAME"sprd"
+#define DRIVER_DESC"Spreadtrum SoCs' DRM Driver"
+#define DRIVER_DATE"20200201"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper =
{
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void sprd_drm_mode_config_init(struct drm_device *drm)
+{
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 8192;
+ drm->mode_config.max_height = 8192;
+ drm->mode_config.allow_fb_modifiers = true;
+
+ drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
+ drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
+
+static struct drm_driver sprd_drm_drv = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .fops = &sprd_drm_fops,
+
+ /* GEM Operations */
+ DRM_GEM_CMA_DRIVER_OPS,
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+};
+
+static int sprd_drm_bind(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+ int ret;
+
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
+ sprd_drm_mode_config_init(drm);
+
+ /* bind and init sub drivers */
+ ret = component_bind_all(drm->dev, drm);
+ if (ret) {
+ drm_err(drm, "failed to bind all component.\n");
+ goto err_dc_cleanup;
+ }
+
+ /* vblank init */
+ ret = drm_vblank_init(dr
[PATCH] drm/nouveau/svm: Only map migrating pages
Only pages which were actually migrated should be mapped on the GPU.
migrate_vma_pages() clears MIGRATE_PFN_MIGRATE in the src_pfn array, so
test this prior to mapping the pages on the GPU. If any pages failed to
migrate don't install any mappings - the GPU will demand fault any as
required.
Fixes: e3d8b0890469 ("drm/nouveau/svm: map pages after migration")
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 92987daa5e17..a2169644f114 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -618,8 +618,9 @@ static void nouveau_dmem_migrate_chunk(struct nouveau_drm
*drm,
dma_addr_t *dma_addrs, u64 *pfns)
{
struct nouveau_fence *fence;
- unsigned long addr = args->start, nr_dma = 0, i;
+ unsigned long addr = args->start, nr_dma = 0, i, npages;
+ npages = (args->end - args->start) >> PAGE_SHIFT;
for (i = 0; addr < args->end; i++) {
args->dst[i] = nouveau_dmem_migrate_copy_one(drm, svmm,
args->src[i], dma_addrs + nr_dma, pfns + i);
@@ -631,7 +632,16 @@ static void nouveau_dmem_migrate_chunk(struct nouveau_drm
*drm,
nouveau_fence_new(drm->dmem->migrate.chan, false, &fence);
migrate_vma_pages(args);
nouveau_dmem_fence_done(&fence);
- nouveau_pfns_map(svmm, args->vma->vm_mm, args->start, pfns, i);
+
+ for (i = 0; i < npages; i++)
+ if (!(args->src[i] & MIGRATE_PFN_MIGRATE))
+ break;
+
+ /* If all pages were migrated successfully map them on the GPU. If any
+* failed just let the GPU fault to create the mapping.
+*/
+ if (i == npages)
+ nouveau_pfns_map(svmm, args->vma->vm_mm, args->start, pfns,
npages);
while (nr_dma--) {
dma_unmap_page(drm->dev->dev, dma_addrs[nr_dma], PAGE_SIZE,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support
On Mon, Nov 30, 2020 at 05:04:43PM +0100, Daniel Vetter wrote: > On Mon, Nov 30, 2020 at 11:55:44AM -0400, Jason Gunthorpe wrote: > > On Mon, Nov 30, 2020 at 03:57:41PM +0100, Daniel Vetter wrote: > > > > + err = ioctl(dri->fd, DRM_IOCTL_AMDGPU_GEM_CREATE, &gem_create); > > > > + if (err) > > > > + return err; > > > > + > > > > + *handle = gem_create.out.handle; > > > > + return 0; > > > > +} > > > > + > > > > +static int radeon_alloc(struct dri *dri, size_t size, uint32_t *handle) > > > > > > Tbh radeon chips are old enough I wouldn't care. Also doesn't support p2p > > > dma-buf, so always going to be in system memory when you share. Plus you > > > also need some more flags like I suggested above I think. > > > > What about nouveau? > > Reallistically chances that someone wants to use rdma together with the > upstream nouveau driver are roughly nil. Imo also needs someone with the > right hardware to make sure it works (since the flags are all kinda arcane > driver specific stuff testing is really needed). Well, it would be helpful if we can test the mlx5 part of the implementation, and I have a lab stocked with nouveau compatible HW.. But you are right someone needs to test/etc, so this does not seem like Jianxin should worry Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/19] dt-bindings: memory: tegra20: emc: Document opp-supported-hw property
On 23.11.20 2:27, Dmitry Osipenko wrote: Document opp-supported-hw property, which is not strictly necessary to have on Tegra20, but it's very convenient to have because all other SoC core devices will use hardware versioning, and thus, it's good to maintain the consistency. Hi Dmitry, I believe Krzysztof is waiting for Ack on the binding before merging this patch (and the rest), but unfortunately it was not sent to the DT mailing list for review. Thanks, Georgi Signed-off-by: Dmitry Osipenko --- .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index 67ac8d1297da..fe99ce1013bd 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -16,6 +16,12 @@ Properties: - #interconnect-cells : Should be 0. - operating-points-v2: See ../bindings/opp/opp.txt for details. +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: One bitfield indicating SoC process ID mask + + A bitwise AND is performed against this value and if any bit + matches, the OPP gets enabled. + Optional properties: - core-supply: Phandle of voltage regulator of the SoC "core" power domain. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] dt-bindings: panel: Add bindings for MRB2801
From: Mikhail Durnev
Add binding for Ronbo MRB2801 display module.
This binding is for display panels using an Ilitek ILI9341 controller in
parallel mode.
Signed-off-by: Mikhail Durnev
---
.../devicetree/bindings/display/ronbo,mrb2801.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
diff --git a/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
new file mode 100644
index 000..db1a861e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
@@ -0,0 +1,42 @@
+MRB2801 display panel
+
+This binding is for display panels using an Ilitek ILI9341 controller in
+parallel mode.
+
+Required properties:
+- compatible: "ronbo,mrb2801"
+- dc-gpios:D/C pin
+- wr-gpios:W/R pin
+- db-gpios:8 or 16 DB pins
+- reset-gpios: Reset pin
+- wr-up-down-delays: Delays in ns for changing W/R from down to up and from
up to down
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ mrb2801{
+ compatible = "ronbo,mrb2801";
+ db-gpios = <&gpio 17 0>, /* DB0 */
+ <&gpio 18 0>, /* DB1 */
+ <&gpio 27 0>, /* DB2 */
+ <&gpio 22 0>, /* DB3 */
+ <&gpio 23 0>, /* DB4 */
+ <&gpio 24 0>, /* DB5 */
+ <&gpio 25 0>, /* DB6 */
+ <&gpio 4 0>, /* DB7 */
+ <&gpio 14 0>, /* DB8 */
+ <&gpio 15 0>, /* DB9 */
+ <&gpio 5 0>, /* DB10 */
+ <&gpio 6 0>, /* DB11 */
+ <&gpio 13 0>, /* DB12 */
+ <&gpio 19 0>, /* DB13 */
+ <&gpio 26 0>, /* DB14 */
+ <&gpio 12 0>; /* DB15 */
+ dc-gpios = <&gpio 16 0>; /* D/C */
+ wr-gpios = <&gpio 20 0>; /* W/R */
+ wr-up-down-delays = <10 51>;
+ reset-gpios = <&gpio 21 0>; /* RST */
+ backlight = <&backlight>;
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
GPU-side memory protection landscape
Hi, On #dri-devel Daniel invited me to chime in on the topic of clearing GPU memory handed to userspace, so here I go. I was asking how information leak from giving userspace dirty memory previously used by another process is not seen as a security issue. I was pointed to a recent thread, which offers a little perspective: https://lists.freedesktop.org/archives/dri-devel/2020-November/287144.html I think the main argument shown there is weak: > And for the legacy node model with authentication of clients against > the X server, leaking that all around was ok. seeing how there's the XCSECURITY extension that is supposed to limit what clients can retrieve, or there could be two X servers running for different users. My other concern is how easy it is to cause system instability or hangs by out-of-bounds writes from the GPU (via compute shaders or copy commands). In my experience of several years doing GPU computing with NVIDIA tech, I don't recall needing to lose time rebooting my PC after running a buggy CUDA "kernel". Heck, I could run the GCC C testsuite on the GPU without worrying about locking myself and others from the server. But now when I develop on a laptop with AMD's latest mobile SoC, every time I make a mistake in my GLSL code it more often than not forces a reboot. I hope you understand what a huge pain it is. What are the existing GPU hardware capabilities for memory protection (both in terms of preventing random accesses to system memory like with an IOMMU, and in terms of isolating different process contexts from each other), and to what extend Linux DRM drivers are taking advantage of them? Would you consider producing a document with answers to the above so users know what to expect? Thank you. Alexander ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
Gustavo, > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. -- Martin K. Petersen Oracle Linux Engineering ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 17/19] ARM: tegra: Add EMC OPP properties to Tegra20 device-trees
01.12.2020 00:17, Jon Hunter пишет: > Hi Dmitry, > > On 23/11/2020 00:27, Dmitry Osipenko wrote: >> Add EMC OPP DVFS tables and update board device-trees by removing >> unsupported OPPs. >> >> Signed-off-by: Dmitry Osipenko > This change is generating the following warning on Tegra20 Ventana > and prevents the EMC from probing ... > > [2.485711] tegra20-emc 7000f400.memory-controller: device-tree doesn't > have memory timings > [2.499386] tegra20-emc 7000f400.memory-controller: 32bit DRAM bus > [2.505810] [ cut here ] > [2.510511] WARNING: CPU: 0 PID: 1 at > /local/workdir/tegra/mlt-linux_next/kernel/drivers/opp/of.c:875 > _of_add_opp_table_v2+0x598/0x61c > [2.529746] Modules linked in: > [2.540140] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 5.10.0-rc5-next-20201130 #1 > [2.554606] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) > [2.560892] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [2.568640] [] (show_stack) from [] > (dump_stack+0xc8/0xdc) > [2.575866] [] (dump_stack) from [] > (__warn+0x104/0x108) > [2.582912] [] (__warn) from [] > (warn_slowpath_fmt+0xb0/0xb8) > [2.590397] [] (warn_slowpath_fmt) from [] > (_of_add_opp_table_v2+0x598/0x61c) > [2.599269] [] (_of_add_opp_table_v2) from [] > (dev_pm_opp_of_add_table+0x3c/0x1a0) > [2.608582] [] (dev_pm_opp_of_add_table) from [] > (tegra_emc_probe+0x478/0x940) > [2.617548] [] (tegra_emc_probe) from [] > (platform_drv_probe+0x48/0x98) > [2.625899] [] (platform_drv_probe) from [] > (really_probe+0x218/0x3b8) > [2.634162] [] (really_probe) from [] > (driver_probe_device+0x5c/0xb4) > [2.642338] [] (driver_probe_device) from [] > (device_driver_attach+0x58/0x60) > [2.651208] [] (device_driver_attach) from [] > (__driver_attach+0x80/0xbc) > [2.659730] [] (__driver_attach) from [] > (bus_for_each_dev+0x74/0xb4) > [2.667905] [] (bus_for_each_dev) from [] > (bus_add_driver+0x164/0x1e8) > [2.676168] [] (bus_add_driver) from [] > (driver_register+0x7c/0x114) > [2.684259] [] (driver_register) from [] > (do_one_initcall+0x54/0x2b0) > [2.692441] [] (do_one_initcall) from [] > (kernel_init_freeable+0x1a4/0x1f4) > [2.701145] [] (kernel_init_freeable) from [] > (kernel_init+0x8/0x118) > [2.709321] [] (kernel_init) from [] > (ret_from_fork+0x14/0x24) > [2.716885] Exception stack(0xc1501fb0 to 0xc1501ff8) > [2.721933] 1fa0: > > [2.730106] 1fc0: > > [2.738278] 1fe0: 0013 > [2.751940] ---[ end trace 61e3b76deca27ef3 ]--- > > > Cheers > Jon > Hello Jon, That is harmless and expected to happen because the patch "memory: tegra20: Support hardware versioning and clean up OPP table initialization" isn't applied yet, while Thierry already applied the DT patches from this v10. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
general protection fault in drm_client_buffer_vunmap
Hello, syzbot found the following issue on: HEAD commit:6147c83f Add linux-next specific files for 20201126 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=109130a550 kernel config: https://syzkaller.appspot.com/x/.config?x=9b91566da897c24f dashboard link: https://syzkaller.appspot.com/bug?extid=10328e8428a896b65119 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1254136950 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1365c66350 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+10328e8428a896b65...@syzkaller.appspotmail.com [drm] Initialized udl on minor 2 [drm:udl_get_edid_block] *ERROR* Read EDID byte 0 failed err ffb9 udl 1-1:0.0: [drm] Cannot find any crtc or sizes usb 1-1: USB disconnect, device number 2 general protection fault, probably for non-canonical address 0xdc02: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0010-0x0017] CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.10.0-rc5-next-20201126-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:drm_client_buffer_vunmap+0x26/0x50 drivers/gpu/drm/drm_client.c:347 Code: 00 00 00 00 53 48 89 fb 48 83 ec 08 e8 83 8b 3f fd 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 8d 73 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0e 48 8b 7b 10 48 83 c4 08 5b e9 56 61 f7 ff 48 89 RSP: 0018:c9cc7710 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 815524de RDX: 0002 RSI: 0018 RDI: 0010 RBP: 88801db748c8 R08: R09: 88801db74a17 R10: ed1003b6e942 R11: R12: R13: 88801db748d8 R14: 88801db74810 R15: dead0100 FS: () GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55f43f9d79e0 CR3: 0b08e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: drm_fbdev_cleanup+0x380/0x440 drivers/gpu/drm/drm_fb_helper.c:2042 drm_fbdev_release drivers/gpu/drm/drm_fb_helper.c:2049 [inline] drm_fbdev_client_unregister+0x61/0x80 drivers/gpu/drm/drm_fb_helper.c:2376 drm_client_dev_unregister+0x239/0x3b0 drivers/gpu/drm/drm_client.c:175 drm_dev_unregister+0xe9/0x2b0 drivers/gpu/drm/drm_drv.c:942 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458 __device_release_driver+0x3bd/0x6f0 drivers/base/dd.c:1154 device_release_driver_internal drivers/base/dd.c:1185 [inline] device_release_driver+0x26/0x40 drivers/base/dd.c:1208 bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:533 device_del+0x502/0xec0 drivers/base/core.c:3113 usb_disable_device+0x35b/0x7b0 drivers/usb/core/message.c:1417 usb_disconnect.cold+0x27d/0x780 drivers/usb/core/hub.c:2218 hub_port_connect drivers/usb/core/hub.c:5074 [inline] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] port_event drivers/usb/core/hub.c:5509 [inline] hub_event+0x1c8a/0x42d0 drivers/usb/core/hub.c:5591 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2272 process_scheduled_works kernel/workqueue.c:2334 [inline] worker_thread+0x82b/0x1120 kernel/workqueue.c:2420 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Modules linked in: ---[ end trace 5e45793b7de819bc ]--- RIP: 0010:drm_client_buffer_vunmap+0x26/0x50 drivers/gpu/drm/drm_client.c:347 Code: 00 00 00 00 53 48 89 fb 48 83 ec 08 e8 83 8b 3f fd 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 8d 73 18 48 --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/tiny: Add driver for ili9341 with parallel bus
From: Mikhail Durnev
MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.
It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.
[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/tiny/Kconfig| 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9341_gpio.c | 290
3 files changed, 304 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
If M is selected the module will be called ili9341.
+config TINYDRM_ILI9341_GPIO
+ tristate "DRM support for ILI9341 display panels with parallel bus
interface over GPIO"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..de8a63b8
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+ mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+ mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+ mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+ mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+ mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+ /* Memory
[PATCH 5/6] dt-bindings: display: add Unisoc's mipi dsi&dphy bindings
From: Kevin Tang
Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 +
.../display/sprd/sprd,sharkl3-dsi-phy.yaml | 84
2 files changed, 191 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
new file mode 100644
index 000..fe0e89d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI Controller
+
+maintainers:
+ - Kevin Tang
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-host
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the registers set for the device.
+
+ interrupts:
+maxItems: 2
+description:
+ Should contain DSI interrupt.
+
+ clocks:
+minItems: 1
+
+ clock-names:
+items:
+ - const: clk_src_96m
+
+ power-domains:
+maxItems: 1
+description: A phandle to DSIM power domain node
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DPU.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DPHY.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dsi: dsi@6310 {
+compatible = "sprd,sharkl3-dsi-host";
+reg = <0x6310 0x1000>;
+interrupts = ,
+ ;
+clock-names = "clk_src_96m";
+clocks = <&pll CLK_TWPLL_96M>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <&dpu_out>;
+};
+};
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <&dphy_in>;
+};
+};
+};
+};
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
new file mode 100644
index 000..b4715d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI-PHY (D-PHY)
+
+maintainers:
+ - Kevin Tang
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-phy
+
+ reg:
+maxItems: 1
+description:
+ Must be the dsi controller base address.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated panel.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DSI controller.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ports
+
+add
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must hold
the GEM
+ * object's reservation lock from when calling this function until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd like
to have here isn't enough. We need to roll this out at the dma-buf level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf it'll come
back through shmem helpers (and other helpers and other subsystems) back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions which I
added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't allow for
specifying where to pin. With fbdev emulation, this means that console
buffers might never make it to VRAM for scanout. If anything, the policy
should be that pin always pins in HW-accessible memory.
Pin has quite a bit of overhead (more locking, buffer movement), so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock internally.
Therefore I think we still would want some additional helpers, such as:
pin_unlocked(), which acquires the resv lock, calls regular pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned and
then calls regalar vmap. Same for vunmap_pinned()
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map
*map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+ * Notes to implementors:
+ *
+ * - Implementations must expect pairs of @vmap and @vunmap to be
+ * called frequently and should optimize for this case.
+ *
+ * - Implemenations may expect the caller to hold the GEM object's
+ * reservation lock to protect against concurrent calls and
relocation
+ * of the GEM object.
+ *
+ * - Implementations may provide additional guarantees (e.g.,
working
+ * without holding the reservation lock).
+ *
* This callback is optional.
+ *
+ * See also drm_gem_dmabuf_vmap()
*/
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
@@ -148,6 +162,8 @@ struct drm_gem_object_funcs {
* drm_gem_dmabuf
Re: [PATCH] drm/vkms: detect modes during output initialization
On Mon, 30 Nov 2020 12:20:08 + Simon Ser wrote: > CC Daniel and Ville > > On Monday, November 30, 2020 12:24 PM, Pekka Paalanen > wrote: > > > > > Please record the justitication for that patch in its commit message. > > > > "Can't" does not explain anything. > > > > > > Yeah, sorry about that. I'm just annoyed by all of this get_connector > > > uAPI, so I don't really want to spend a lot of time documenting why > > > it's so gross. > > > > But I still don't understand why the kernel cannot be fixed to do the > > right thing that most of us assumed it should be doing: probe > > automatically so userspace never needs to. > > My understanding is that it could maybe be implemented this way, but > that it's not the way it works right now. So someone would need to go > through all DRM drivers and implement the better behavior, then could > restore this doc section. Right, so that would be really good to explain in the commit message. Thanks, pq pgpaofvQxSfeg.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
On Mon, 30 Nov 2020, Sam Ravnborg wrote: > On Mon, Nov 30, 2020 at 01:14:52PM +0100, Thomas Zimmermann wrote: > > > > > > Am 28.11.20 um 23:40 schrieb Sam Ravnborg: > > > Fix W=1 warnings: > > > - Fix kernel-doc > > > - Drop unused variables/code > > > > > > v2: > > >- Updated subject (Lee) > > > > > > Signed-off-by: Sam Ravnborg > > > Cc: Antonino Daplas > > > Cc: linux-fb...@vger.kernel.org > > > Cc: Lee Jones > > > --- > > > drivers/video/fbdev/riva/fbdev.c | 9 - > > > drivers/video/fbdev/riva/riva_hw.c | 28 > > > 2 files changed, 12 insertions(+), 25 deletions(-) > > > > > > diff --git a/drivers/video/fbdev/riva/fbdev.c > > > b/drivers/video/fbdev/riva/fbdev.c > > > index ce55b9d2e862..4b0433cb 100644 > > > --- a/drivers/video/fbdev/riva/fbdev.c > > > +++ b/drivers/video/fbdev/riva/fbdev.c > > > @@ -464,7 +464,7 @@ static inline void reverse_order(u32 *l) > > > /** > > >* rivafb_load_cursor_image - load cursor image to hardware > > > - * @data: address to monochrome bitmap (1 = foreground color, 0 = > > > background) > > > + * @data8: address to monochrome bitmap (1 = foreground color, 0 = > > > background) > > >* @par: pointer to private data > > >* @w:width of cursor image in pixels > > >* @h:height of cursor image in scanlines > > > @@ -843,9 +843,9 @@ static void riva_update_var(struct fb_var_screeninfo > > > *var, > > > /** > > >* rivafb_do_maximize - > > >* @info: pointer to fb_info object containing info for current riva > > > board > > > - * @var: > > > - * @nom: > > > - * @den: > > > + * @var: standard kernel fb changeable data > > > + * @nom: nom > > > + * @den: den Cop-out! Do what I do and make something up (joke)! :'D > > Well, it fixes the warning ;) > > Yeah, I could not dig up anything useful to say here. > Was tempted to just drop all the kernel-doc syntax but that > was a larger change. Did you trace it from it's origin down to it's final use? -- 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] drm/vkms: detect modes during output initialization
On Tuesday, December 1, 2020 9:46 AM, Pekka Paalanen wrote: > On Mon, 30 Nov 2020 12:20:08 + > Simon Ser cont...@emersion.fr wrote: > > > CC Daniel and Ville > > On Monday, November 30, 2020 12:24 PM, Pekka Paalanen ppaala...@gmail.com > > wrote: > > > > > > > Please record the justitication for that patch in its commit message. > > > > > "Can't" does not explain anything. > > > > > > > > Yeah, sorry about that. I'm just annoyed by all of this get_connector > > > > uAPI, so I don't really want to spend a lot of time documenting why > > > > it's so gross. > > > > > > But I still don't understand why the kernel cannot be fixed to do the > > > right thing that most of us assumed it should be doing: probe > > > automatically so userspace never needs to. > > > > My understanding is that it could maybe be implemented this way, but > > that it's not the way it works right now. So someone would need to go > > through all DRM drivers and implement the better behavior, then could > > restore this doc section. > > Right, so that would be really good to explain in the commit message. v2 should take care of it. Let me know if you think the new commit message can be improved. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: document that user-space should force-probe connectors
On Mon, 30 Nov 2020 16:26:12 +
Simon Ser wrote:
> It seems like we can't have nice things, so let's just document the
> disappointing behaviour instead.
>
> The previous version assumed the kernel would perform the probing work
> when appropriate, however this is not the case today. Update the
> documentation to reflect reality.
Hi Simon,
yeah, this message actually explains something. Good.
> v2:
>
> - Improve commit message to explain why this change is made (Pekka)
> - Keep the bit about flickering (Daniel)
> - Explain when user-space should force-probe, and when it shouldn't (Daniel)
>
> Signed-off-by: Simon Ser
> Fixes: 2ac5ef3b2362 ("drm: document drm_mode_get_connector")
> Reviewed-by: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrjala
> ---
> include/uapi/drm/drm_mode.h | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index b49fbf2bdc40..1c064627e6c3 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -414,15 +414,12 @@ enum drm_mode_subconnector {
> *
> * If the @count_modes field is set to zero, the kernel will perform a forced
> * probe on the connector to refresh the connector status, modes and EDID.
> - * A forced-probe can be slow and the ioctl will block. A force-probe can
> cause
> - * flickering and temporary freezes, so it should not be performed
> - * automatically.
> + * A forced-probe can be slow, might cause flickering and the ioctl will
> block.
> *
> - * User-space shouldn't need to force-probe connectors in general: the kernel
> - * will automatically take care of probing connectors that don't support
> - * hot-plug detection when appropriate. However, user-space may force-probe
> - * connectors on user request (e.g. clicking a "Scan connectors" button, or
> - * opening a UI to manage screens).
> + * User-space needs to force-probe connectors to ensure their metadata is
> + * up-to-date at startup and after receiving a hot-plug event. User-space
> + * may perform a forced-probe when the user explicitly requests it.
> User-space
> + * shouldn't perform a forced-probe in other situations.
> */
> struct drm_mode_get_connector {
> /** @encoders_ptr: Pointer to ``__u32`` array of object IDs. */
Sounds good, err... accurate to me.
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgpRWwcuijEUO.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
Hi Lee, > > Cop-out! > > Do what I do and make something up (joke)! :'D If I thought anyone would actually read the comments then maybe yes. But I assume that apart from this thread no-one will read it. > > > > Well, it fixes the warning ;) > > > > Yeah, I could not dig up anything useful to say here. > > Was tempted to just drop all the kernel-doc syntax but that > > was a larger change. > > Did you trace it from it's origin down to it's final use? Yeah, but not something that seemed useful. I could have added "translating from pixels->bytes" as they are described somewhere else. But I could not convince myself this was right so I just silenced the warning. The only reason I kept the kernel-doc in the first place is that I am told some editors use it. The only effect the kernel-doc in fbdev has right now is burning effort that could have been spent (better?) somewhere else, and I would personally prefer to drop the kernel-doc annotations. But I already discussed this in another thread (not fbdev related) and I was told it was useful for some, so it is kept. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.11.20 um 16:33 schrieb Christian König:
> > Am 30.11.20 um 16:30 schrieb Daniel Vetter:
> >> On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
> >>> Mapping a GEM object's buffer into kernel address space prevents the
> >>> buffer from being evicted from VRAM, which in turn may result in
> >>> out-of-memory errors. It's therefore required to only vmap GEM BOs for
> >>> short periods of time; unless the GEM implementation provides additional
> >>> guarantees.
> >>>
> >>> Signed-off-by: Thomas Zimmermann
> >>> ---
> >>> drivers/gpu/drm/drm_prime.c | 6 ++
> >>> include/drm/drm_gem.h | 16
> >>> 2 files changed, 22 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >>> index 7db55fce35d8..9c9ece9833e0 100644
> >>> --- a/drivers/gpu/drm/drm_prime.c
> >>> +++ b/drivers/gpu/drm/drm_prime.c
> >>> @@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
> >>>* callback. Calls into &drm_gem_object_funcs.vmap for device
> >>> specific handling.
> >>>* The kernel virtual address is returned in map.
> >>>*
> >>> + * To prevent the GEM object from being relocated, callers must hold
> >>> the GEM
> >>> + * object's reservation lock from when calling this function until
> >>> releasing the
> >>> + * mapping. Holding onto a mapping and the associated reservation
> >>> lock for an
> >>> + * unbound time may result in out-of-memory errors. Calls to
> >>> drm_gem_dmabuf_vmap()
> >>> + * should therefore be accompanied by a call to
> >>> drm_gem_dmabuf_vunmap().
> >>> + *
> >>>* Returns 0 on success or a negative errno code otherwise.
> >> This is a dma-buf hook, which means just documenting the rules you'd like
> >> to have here isn't enough. We need to roll this out at the dma-buf level,
> >> and enforce it.
> >>
> >> Enforce it = assert_lock_held
> >>
> >> Roll out = review everyone. Because this goes through dma-buf it'll come
> >> back through shmem helpers (and other helpers and other subsystems) back
> >> to any driver using vmap for gpu buffers. This includes the media
> >> subsystem, and the media subsystem definitely doesn't cope with just
> >> temporarily mapping buffers. So there we need to pin them, which I think
> >> means we'll need 2 version of dma_buf_vmap - one that's temporary and
> >> requires we hold dma_resv lock, the other requires that the buffer is
> >> pinned.
> >
> > OR start to proper use the dma_buf_pin/dma_buf_unpin functions which I
> > added to cover this use case as well.
>
> While I generally agree, here are some thoughts:
>
> I found all generic pin functions useless, because they don't allow for
> specifying where to pin. With fbdev emulation, this means that console
> buffers might never make it to VRAM for scanout. If anything, the policy
> should be that pin always pins in HW-accessible memory.
>
> Pin has quite a bit of overhead (more locking, buffer movement), so it
> should be the second choice after regular vmap. To make both work
> together, pin probably relies on holding the reservation lock internally.
>
> Therefore I think we still would want some additional helpers, such as:
>
>pin_unlocked(), which acquires the resv lock, calls regular pin and
> then drops the resv lock. Same for unpin_unlocked()
>
>vmap_pinned(), which enforces that the buffer has been pinned and
> then calls regalar vmap. Same for vunmap_pinned()
>
> A typical pattern with these functions would look like this.
>
> drm_gem_object bo;
> dma_buf_map map;
>
> init() {
> pin_unlocked(bo);
> vmap_pinned(bo, map);
> }
>
> worker() {
> begin_cpu_access()
> // access bo via map
> end_cpu_access()
> }
>
> fini() {
> vunmap_pinned(bo, map);
> unpin_unlocked(bo);
> }
>
> init()
> while (...) {
> worker()
> }
> fini()
>
> Is that reasonable for media drivers?
So media drivers go through dma-buf, which means we always pin into
system memory. Which I guess for vram-only display drivers makes no
sense and should be rejected, but we still need somewhat consistent
rules.
The other thing is that if you do a dma_buf_attach without dynamic
mode, dma-buf will pin things for you already. So in many cases it
could be that we don't need a separate pin (but since the pin is in
the exporter, not dma-buf layer, we can't check for that). I'm also
not seeing why existing users need to split up their dma_buf_vmap into
a pin + vmap, they don't need them separately.
I think we could use what we've done for dynamic dma-buf attachment
(which also change locking rules) and just have new functions for the
new way (i.e. short term vmap protected by dma_resv lock. Maybe call
these dma_buf_vmap_local, in the spirit of the new kmap_
[PATCH 5.9 129/152] drm/nouveau: fix relocations applying logic and a double-free
From: Matti Hamalainen
[ Upstream commit 2be65641642ef423f82162c3a5f28c754d1637d2 ]
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
a logic-bug which results in the relocations not actually getting
applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
never reached. This causes a regression with graphical corruption,
triggered when relocations need to be done (for example after a
suspend/resume cycle.)
Fix by setting *apply_relocs value only if there were more than 0
relocations.
Additionally, the never reached code had a leftover u_free() call,
which, after fixing the logic, now got called and resulted in a
double-free. Fix by removing one u_free(), moving the other
and adding check for errors.
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matti Hamalainen
Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl")
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201120152338.1203257-1-...@tnsp.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 124d3dcc5c590..98e99aa8a547e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -570,8 +570,10 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
NV_PRINTK(err, cli, "validating bo list\n");
validate_fini(op, chan, NULL, NULL);
return ret;
+ } else if (ret > 0) {
+ *apply_relocs = true;
}
- *apply_relocs = ret;
+
return 0;
}
@@ -674,7 +676,6 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
}
- u_free(reloc);
return ret;
}
@@ -884,9 +885,10 @@ out:
break;
}
}
- u_free(reloc);
}
out_prevalid:
+ if (!IS_ERR(reloc))
+ u_free(reloc);
u_free(bo);
u_free(push);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Am 01.12.20 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides
additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must
hold the GEM
+ * object's reservation lock from when calling this function until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd
like
to have here isn't enough. We need to roll this out at the dma-buf
level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf it'll
come
back through shmem helpers (and other helpers and other subsystems)
back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I
think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions which
I added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't allow
for specifying where to pin. With fbdev emulation, this means that
console buffers might never make it to VRAM for scanout. If anything,
the policy should be that pin always pins in HW-accessible memory.
Yes, completely agree. The major missing part here are some kind of
usage flags what we want to do with the buffer.
Pin has quite a bit of overhead (more locking, buffer movement), so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock internally.
There is a dma_resv_assert_held() at the beginning of those two functions.
Therefore I think we still would want some additional helpers, such as:
pin_unlocked(), which acquires the resv lock, calls regular pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned and
then calls regalar vmap. Same for vunmap_pinned()
I would rather open code that in each driver, hiding the locking logic
in some midlayer is usually not a good idea.
Regards,
Christian.
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very sprawling :-/
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 10:13 schrieb Christian König:
Am 01.12.20 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides
additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must
hold the GEM
+ * object's reservation lock from when calling this function until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd
like
to have here isn't enough. We need to roll this out at the dma-buf
level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf it'll
come
back through shmem helpers (and other helpers and other subsystems)
back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I
think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions which
I added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't allow
for specifying where to pin. With fbdev emulation, this means that
console buffers might never make it to VRAM for scanout. If anything,
the policy should be that pin always pins in HW-accessible memory.
Yes, completely agree. The major missing part here are some kind of
usage flags what we want to do with the buffer.
Not sure, but wasn't that not wanted by someone? I don't really remember.
Given Daniel's reply about pin, it really feels like we have
contradicting policies for this interface.
Pin has quite a bit of overhead (more locking, buffer movement), so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock internally.
There is a dma_resv_assert_held() at the beginning of those two functions.
Therefore I think we still would want some additional helpers, such as:
pin_unlocked(), which acquires the resv lock, calls regular pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned and
then calls regalar vmap. Same for vunmap_pinned()
I would rather open code that in each driver, hiding the locking logic
in some midlayer is usually not a good idea.
These helpers are less about hiding logic and more about making drivers
do the right thing. The idea behind pin_unlocked() is that it drops the
reservation lock immediately before returning. I suspect that some
driver might not do that with an open-coded version. And vmap_pinned()
does check for the BO to be pinned. Regular vmap would assert for the
reservation lock instead.
Best regards
Thomas
Regards,
Christian.
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very sprawling :-/
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 10:10 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmermann wrote:
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must hold
the GEM
+ * object's reservation lock from when calling this function until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd like
to have here isn't enough. We need to roll this out at the dma-buf level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf it'll come
back through shmem helpers (and other helpers and other subsystems) back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions which I
added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't allow for
specifying where to pin. With fbdev emulation, this means that console
buffers might never make it to VRAM for scanout. If anything, the policy
should be that pin always pins in HW-accessible memory.
Pin has quite a bit of overhead (more locking, buffer movement), so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock internally.
Therefore I think we still would want some additional helpers, such as:
pin_unlocked(), which acquires the resv lock, calls regular pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned and
then calls regalar vmap. Same for vunmap_pinned()
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
So media drivers go through dma-buf, which means we always pin into
system memory. Which I guess for vram-only display drivers makes no
sense and should be rejected, but we still need somewhat consistent
rules.
The other thing is that if you do a dma_buf_attach without dynamic
mode, dma-buf will pin things for you already. So in many cases it
Do you have a pointer to code that illustrates this well?
could be that we don't need a separate pin (but since the pin is in
the exporter, not dma-buf layer, we can't check for that). I'm also
not seeing why existing users need to split up their dma_buf_vmap into
a pin + vmap, they don't need them separately.
It's two different operations, with pin having some possible overhead
and failure conditions. And during the last discussion, pin was say to
be for userspace-managed buffers. Kernel code should hold the
reservation lock.
For my POV, the current interfaces have no clear policy or semantics.
Looking through the different GEM implementations, each one seems to
have its own interpretation.
I think we could use what we've done for dynamic dma-buf attachment
(which also change
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
On Tue, 01 Dec 2020, Sam Ravnborg wrote: > Hi Lee, > > > > > Cop-out! > > > > Do what I do and make something up (joke)! :'D > > If I thought anyone would actually read the comments then maybe yes. > But I assume that apart from this thread no-one will read it. > > > > > > > Well, it fixes the warning ;) > > > > > > Yeah, I could not dig up anything useful to say here. > > > Was tempted to just drop all the kernel-doc syntax but that > > > was a larger change. > > > > Did you trace it from it's origin down to it's final use? > Yeah, but not something that seemed useful. > I could have added "translating from pixels->bytes" as they > are described somewhere else. But I could not convince myself > this was right so I just silenced the warning. > > The only reason I kept the kernel-doc in the first place is > that I am told some editors use it. > > The only effect the kernel-doc in fbdev has right now is burning > effort that could have been spent (better?) somewhere else, and > I would personally prefer to drop the kernel-doc annotations. > > But I already discussed this in another thread (not fbdev related) > and I was told it was useful for some, so it is kept. I personally think they should be kept. Despite not being referenced by any kernel-doc:: key-words. As you say, it can be helpful as an in-code reference for driver writers, people debugging code, et al. Not sure I would just repeat the variable name just to silence the warning though - that is definitely a hack. In the thousands (literally!) of these that I've fixed thus far, I haven't needed to do that. -- 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 09/15] drm/nouveau: Remove references to struct drm_device.pdev
Hi Sam
Am 24.11.20 um 22:42 schrieb Sam Ravnborg:
Hi Thomas.
On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote:
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Ben Skeggs
Suggestion to an alternative implmentation below.
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 12 +++-
drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 11 ---
drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 --
drivers/gpu/drm/nouveau/nouveau_vga.c | 20
10 files changed, 58 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index d204ea8a5618..7cc683b8dc7a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -110,6 +110,9 @@ static int call_lvds_manufacturer_script(struct drm_device
*dev, struct dcb_outp
struct nvbios *bios = &drm->vbios;
uint8_t sub = bios->data[bios->fp.xlated_entry + script] + (bios->fp.link_c_increment
&& dcbent->or & DCB_OUTPUT_C ? 1 : 0);
uint16_t scriptofs = ROM16(bios->data[bios->init_script_tbls_ptr + sub
* 2]);
+#ifdef __powerpc__
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+#endif
Or
int device = 0;
if (!bios->fp.xlated_entry || !sub || !scriptofs)
return -EINVAL;
@@ -123,8 +126,8 @@ static int call_lvds_manufacturer_script(struct drm_device
*dev, struct dcb_outp
#ifdef __powerpc__
/* Powerbook specific quirks */
device = to_pci_dev(dev->dev)->device;
if (script == LVDS_RESET && (device == 0x0179 || device == 0x0189 ||
device == 0x0329))
I see the point, but I'm trying to not change the existing
implementation too much.
if (script == LVDS_RESET &&
- (dev->pdev->device == 0x0179 || dev->pdev->device == 0x0189 ||
-dev->pdev->device == 0x0329))
+ (pdev->device == 0x0179 || pdev->device == 0x0189 ||
+pdev->device == 0x0329))
nv_write_tmds(dev, dcbent->or, 0, 0x02, 0x72);
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 24ec5339efb4..4fc0fa696461 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -396,7 +396,9 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
NV_INFO(drm, "allocated %dx%d fb: 0x%llx, bo %p\n",
fb->width, fb->height, nvbo->offset, nvbo);
- vga_switcheroo_client_fb_set(dev->pdev, info);
+ if (dev_is_pci(dev->dev))
+ vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), info);
+
I cannot see why dev_is_pci() is needed here.
So I am obviously missing something :-(
vga_switcheroo_client_fb_set() expects a PCI device. It's a bit of a
stretch, but at least it is possible to pass NULL for non-PCI devices.
Passing the upcasted dev->dev is just garbage.
As the VGA switcheroo is only relevant for PCI devices, I added the
branching to make this work reliably.
Best regards
Thomas
return 0;
out_unlock:
@@ -548,7 +550,7 @@ nouveau_fbcon_init(struct drm_device *dev)
int ret;
if (!dev->mode_config.num_crtc ||
- (dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
+ (to_pci_dev(dev->dev)->class >> 8) != PCI_CLASS_DISPLAY_VGA)
return 0;
fbcon = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index c85dd8afa3c3..7c4b374b3eca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -87,18 +87,20 @@ nouveau_vga_init(struct nouveau_drm *drm)
{
struct drm_device *dev = drm->dev;
bool runtime = nouveau_pmops_runtime();
+ struct pci_dev *pdev;
/* only relevant for PCI devices */
- if (!dev->pdev)
+ if (!dev_is_pci(dev->dev))
return;
+ pdev = to_pci_dev(dev->dev);
- vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
+ vga_client_register(pdev, dev, NULL, nouveau_vga_set_decode);
/* don't register Thunderbolt eGPU with vga_switcheroo */
- if (pci_is_thunderbolt_attached(dev->pdev))
+ if (pci_is_thunderbolt_attached(pdev))
return;
- vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops, runtime);
+ vga_switcheroo_register_client(pdev, &nouveau_switcheroo_ops, runtime);
Re: [PATCH v2 08/28] video: fbdev: sis: Fix defined but not used warning of SiS_TVDelay
Hi Am 30.11.20 um 20:01 schrieb Sam Ravnborg: Hi Thomas. On Mon, Nov 30, 2020 at 10:13:05AM +0100, Thomas Zimmermann wrote: Am 28.11.20 um 23:40 schrieb Sam Ravnborg: Fix W=1 warning by commenting unused SiS_TVDelay* variables. The SiS_TVDelay* variables seem to contain some magic numbers so looks like data worth keeping around but not as code we build. I would remove it. sisfb is broken beyond repair and no one's going to try to use it anyway. In any case Acked-by: Thomas Zimemrmann Thanks for your patience pointing out all my spelling and grammar errors. I once had codespell set up to catch some of this, will need to do so again. Ironically I copied the above "Acked-by:" line to most of the commits and just noticed it had a spelling error :-) Perfect! :D I have applied everything that you acked and will push when I have fixed the above and verified I did not break anything. Will post a v3 with the remaining patches later. Sam -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/bridge: add it6505 driver
Hi Allen.
On Tue, Dec 01, 2020 at 01:44:41PM +0800, allen wrote:
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
>
> From: Allen Chen
> Signed-off-by: Jitao Shi
> Signed-off-by: Pi-Hsun Shih
> Signed-off-by: Yilun Lin
> Signed-off-by: Hermes Wu
> Signed-off-by: Allen Chen
I recall I provided the same comment as last time, but may remember
wrong.
New bridge drivers shall support that connector creation is optional.
This driver does not do that - see following code snippet:
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ DRM_ERROR("Fix bridge driver to make connector optional!");
+ return -EINVAL;
+ }
+
I did not check, but likely the drive needs to implment some of the
connector hooks too. (detect, get_edid, etc).
Please include a changelog too - it can be very hard to remember what
feedback was provided when one reviews several patches/week.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
On Tue, Dec 1, 2020 at 10:40 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 01.12.20 um 10:10 schrieb Daniel Vetter:
> > On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 30.11.20 um 16:33 schrieb Christian König:
> >>> Am 30.11.20 um 16:30 schrieb Daniel Vetter:
> On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
> > Mapping a GEM object's buffer into kernel address space prevents the
> > buffer from being evicted from VRAM, which in turn may result in
> > out-of-memory errors. It's therefore required to only vmap GEM BOs for
> > short periods of time; unless the GEM implementation provides additional
> > guarantees.
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> >drivers/gpu/drm/drm_prime.c | 6 ++
> >include/drm/drm_gem.h | 16
> >2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 7db55fce35d8..9c9ece9833e0 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
> > * callback. Calls into &drm_gem_object_funcs.vmap for device
> > specific handling.
> > * The kernel virtual address is returned in map.
> > *
> > + * To prevent the GEM object from being relocated, callers must hold
> > the GEM
> > + * object's reservation lock from when calling this function until
> > releasing the
> > + * mapping. Holding onto a mapping and the associated reservation
> > lock for an
> > + * unbound time may result in out-of-memory errors. Calls to
> > drm_gem_dmabuf_vmap()
> > + * should therefore be accompanied by a call to
> > drm_gem_dmabuf_vunmap().
> > + *
> > * Returns 0 on success or a negative errno code otherwise.
> This is a dma-buf hook, which means just documenting the rules you'd like
> to have here isn't enough. We need to roll this out at the dma-buf level,
> and enforce it.
>
> Enforce it = assert_lock_held
>
> Roll out = review everyone. Because this goes through dma-buf it'll come
> back through shmem helpers (and other helpers and other subsystems) back
> to any driver using vmap for gpu buffers. This includes the media
> subsystem, and the media subsystem definitely doesn't cope with just
> temporarily mapping buffers. So there we need to pin them, which I think
> means we'll need 2 version of dma_buf_vmap - one that's temporary and
> requires we hold dma_resv lock, the other requires that the buffer is
> pinned.
> >>>
> >>> OR start to proper use the dma_buf_pin/dma_buf_unpin functions which I
> >>> added to cover this use case as well.
> >>
> >> While I generally agree, here are some thoughts:
> >>
> >> I found all generic pin functions useless, because they don't allow for
> >> specifying where to pin. With fbdev emulation, this means that console
> >> buffers might never make it to VRAM for scanout. If anything, the policy
> >> should be that pin always pins in HW-accessible memory.
> >>
> >> Pin has quite a bit of overhead (more locking, buffer movement), so it
> >> should be the second choice after regular vmap. To make both work
> >> together, pin probably relies on holding the reservation lock internally.
> >>
> >> Therefore I think we still would want some additional helpers, such as:
> >>
> >> pin_unlocked(), which acquires the resv lock, calls regular pin and
> >> then drops the resv lock. Same for unpin_unlocked()
> >>
> >> vmap_pinned(), which enforces that the buffer has been pinned and
> >> then calls regalar vmap. Same for vunmap_pinned()
> >>
> >> A typical pattern with these functions would look like this.
> >>
> >> drm_gem_object bo;
> >> dma_buf_map map;
> >>
> >> init() {
> >> pin_unlocked(bo);
> >> vmap_pinned(bo, map);
> >> }
> >>
> >> worker() {
> >> begin_cpu_access()
> >> // access bo via map
> >> end_cpu_access()
> >> }
> >>
> >> fini() {
> >> vunmap_pinned(bo, map);
> >> unpin_unlocked(bo);
> >> }
> >>
> >> init()
> >> while (...) {
> >> worker()
> >> }
> >> fini()
> >>
> >> Is that reasonable for media drivers?
> >
> > So media drivers go through dma-buf, which means we always pin into
> > system memory. Which I guess for vram-only display drivers makes no
> > sense and should be rejected, but we still need somewhat consistent
> > rules.
> >
> > The other thing is that if you do a dma_buf_attach without dynamic
> > mode, dma-buf will pin things for you already. So in many cases it
>
> Do you have a pointer to code that illustrates this well?
>
> > could be
Re: [PATCH v2 22/28] video: fbdev: omapfb: Fix set but not used warnings in dsi
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix several W=1 warnings.
This removes unused code and avoids an assignment by moving
the use inside the conditional block.
The register read FLD_GET(r, 15, 8) could be dropped as it was done a
few lines before too.
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Aditya Pakki
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index 6f9c25fec994..72d45a02c3ac 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -1178,13 +1178,12 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
static void _dsi_print_reset_status(struct platform_device *dsidev)
{
- u32 l;
int b0, b1, b2;
/* A dummy read using the SCP interface to any DSIPHY register is
* required after DSIPHY reset to complete the reset of the DSI complex
* I/O. */
- l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
+ dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
b0 = 28;
@@ -3627,7 +3626,7 @@ static int dsi_proto_config(struct platform_device
*dsidev)
static void dsi_proto_timings(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- unsigned tlpx, tclk_zero, tclk_prepare, tclk_trail;
+ unsigned tlpx, tclk_zero, tclk_prepare;
unsigned tclk_pre, tclk_post;
unsigned ths_prepare, ths_prepare_ths_zero, ths_zero;
unsigned ths_trail, ths_exit;
@@ -3646,7 +3645,6 @@ static void dsi_proto_timings(struct platform_device
*dsidev)
r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG1);
tlpx = FLD_GET(r, 20, 16) * 2;
- tclk_trail = FLD_GET(r, 15, 8);
tclk_zero = FLD_GET(r, 7, 0);
r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG2);
@@ -4040,7 +4038,6 @@ static int dsi_update(struct omap_dss_device *dssdev, int
channel,
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- u16 dw, dh;
dsi_perf_mark_setup(dsidev);
@@ -4049,11 +4046,8 @@ static int dsi_update(struct omap_dss_device *dssdev, int channel,
dsi->framedone_callback = callback;
dsi->framedone_data = data;
- dw = dsi->timings.x_res;
- dh = dsi->timings.y_res;
-
#ifdef DSI_PERF_MEASURE
- dsi->update_bytes = dw * dh *
+ dsi->update_bytes = dsi->timings.x_res * dsi->timings.y_res *
dsi_get_pixel_size(dsi->pix_fmt) / 8;
#endif
dsi_update_screen_dispc(dsidev);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
On Tue, Dec 1, 2020 at 10:46 AM Lee Jones wrote: > > On Tue, 01 Dec 2020, Sam Ravnborg wrote: > > > Hi Lee, > > > > > > > > Cop-out! > > > > > > Do what I do and make something up (joke)! :'D > > > > If I thought anyone would actually read the comments then maybe yes. > > But I assume that apart from this thread no-one will read it. > > > > > > > > > > Well, it fixes the warning ;) > > > > > > > > Yeah, I could not dig up anything useful to say here. > > > > Was tempted to just drop all the kernel-doc syntax but that > > > > was a larger change. > > > > > > Did you trace it from it's origin down to it's final use? > > Yeah, but not something that seemed useful. > > I could have added "translating from pixels->bytes" as they > > are described somewhere else. But I could not convince myself > > this was right so I just silenced the warning. > > > > The only reason I kept the kernel-doc in the first place is > > that I am told some editors use it. > > > > The only effect the kernel-doc in fbdev has right now is burning > > effort that could have been spent (better?) somewhere else, and > > I would personally prefer to drop the kernel-doc annotations. > > > > But I already discussed this in another thread (not fbdev related) > > and I was told it was useful for some, so it is kept. > > I personally think they should be kept. Despite not being referenced > by any kernel-doc:: key-words. As you say, it can be helpful as an > in-code reference for driver writers, people debugging code, et al. > > Not sure I would just repeat the variable name just to silence the > warning though - that is definitely a hack. In the thousands > (literally!) of these that I've fixed thus far, I haven't needed to do > that. Personally what I've done is to just remove the kerneldoc marker (and anything else that's obviously wrong) and leave plain comments behind. At least for old outdated code that no one actively maintains anymore. Keeps the comment as maybe something useful, and avoids pointless busy work of inventing kerneldoc which might or might not actually be correctly describing what's going on. -Daniel -- 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 23/28] video: fbdev: omapfb: Fix set but not used warnings in hdmi*_core
Hi Am 28.11.20 um 23:41 schrieb Sam Ravnborg: Fix a few W=1 warnings about unused assignments. Drop the unused error code. v2: - Subject updated (Lee) Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Qilong Zhang Cc: "Alexander A. Klimov" Cc: Daniel Vetter Cc: Lee Jones --- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 4 ++-- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c index 726c190862d4..e6363a420933 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c @@ -679,7 +679,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config acore; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -741,7 +741,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, &n, &cts); + hdmi_compute_acr(pclk, fs_nr, &n, &cts); I'd rather return the error reported by hdmi_compute_acr() Best regards Thomas /* Audio clock regeneration settings */ acore.n = n; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c index eda29d3032e1..cb63bc0e92ca 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c @@ -790,7 +790,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config core_cfg; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -833,7 +833,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, &n, &cts); + hdmi_compute_acr(pclk, fs_nr, &n, &cts); core_cfg.n = n; core_cfg.cts = cts; -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 24/28] video: fbdev: s3c-fb: Fix kernel-doc and set but not used warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix several W=1 warnings
- Updated kernel-doc as needed
- Deleted unused local variable, it was assigned but never used
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Jingoo Han
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/s3c-fb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index ba316bd56efd..3b134e1bbc38 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -75,6 +75,7 @@ struct s3c_fb;
* @buf_size: Offset of buffer size registers.
* @buf_end: Offset of buffer end registers.
* @osd: The base for the OSD registers.
+ * @osd_stride: stride of osd
* @palette: Address of palette memory, or 0 if none.
* @has_prtcon: Set if has PRTCON register.
* @has_shadowcon: Set if has SHADOWCON register.
@@ -155,7 +156,7 @@ struct s3c_fb_palette {
* @windata: The platform data supplied for the window configuration.
* @parent: The hardware that this window is part of.
* @fbinfo: Pointer pack to the framebuffer info for this window.
- * @varint: The variant information for this window.
+ * @variant: The variant information for this window.
* @palette_buffer: Buffer/cache to hold palette entries.
* @pseudo_palette: For use in TRUECOLOUR modes for entries 0..15/
* @index: The window number of this window.
@@ -336,7 +337,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
/**
* s3c_fb_calc_pixclk() - calculate the divider to create the pixel clock.
* @sfb: The hardware state.
- * @pixclock: The pixel clock wanted, in picoseconds.
+ * @pixclk: The pixel clock wanted, in picoseconds.
*
* Given the specified pixel clock, work out the necessary divider to get
* close to the output frequency.
@@ -733,7 +734,7 @@ static inline unsigned int chan_to_field(unsigned int chan,
* @red: The red field for the palette data.
* @green: The green field for the palette data.
* @blue: The blue field for the palette data.
- * @trans: The transparency (alpha) field for the palette data.
+ * @transp: The transparency (alpha) field for the palette data.
* @info: The framebuffer being changed.
*/
static int s3c_fb_setcolreg(unsigned regno,
@@ -1133,6 +1134,7 @@ static void s3c_fb_free_memory(struct s3c_fb *sfb, struct
s3c_fb_win *win)
/**
* s3c_fb_release_win() - release resources for a framebuffer window.
+ * @sfb: The base resources for the hardware.
* @win: The window to cleanup the resources for.
*
* Release the resources that where claimed for the hardware window,
@@ -1160,6 +1162,7 @@ static void s3c_fb_release_win(struct s3c_fb *sfb, struct
s3c_fb_win *win)
/**
* s3c_fb_probe_win() - register an hardware window
* @sfb: The base resources for the hardware
+ * @win_no: The window number
* @variant: The variant information for this window.
* @res: Pointer to where to place the resultant window.
*
@@ -1170,7 +1173,6 @@ static int s3c_fb_probe_win(struct s3c_fb *sfb, unsigned
int win_no,
struct s3c_fb_win_variant *variant,
struct s3c_fb_win **res)
{
- struct fb_var_screeninfo *var;
struct fb_videomode initmode;
struct s3c_fb_pd_win *windata;
struct s3c_fb_win *win;
@@ -1198,7 +1200,6 @@ static int s3c_fb_probe_win(struct s3c_fb *sfb, unsigned
int win_no,
win = fbinfo->par;
*res = win;
- var = &fbinfo->var;
win->variant = *variant;
win->fbinfo = fbinfo;
win->parent = sfb;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 25/28] video: fbdev: uvesafb: Fix set but not used warning
Hi
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix W=1 warning by deleting unused local variable.
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Michal Januszewski
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
---
drivers/video/fbdev/uvesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index def14ac0ebe1..8ee0fc9c63cf 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -554,12 +554,12 @@ static int uvesafb_vbe_getmodes(struct uvesafb_ktask
*task,
static int uvesafb_vbe_getpmi(struct uvesafb_ktask *task,
struct uvesafb_par *par)
{
- int i, err;
+ int i;
uvesafb_reset(task);
task->t.regs.eax = 0x4f0a;
task->t.regs.ebx = 0x0;
- err = uvesafb_exec(task);
+ uvesafb_exec(task);
Would it be better to report the error here?
Best regards
Thomas
if ((task->t.regs.eax & 0x) != 0x4f || task->t.regs.es < 0xc000) {
par->pmi_setpal = par->ypan = 0;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
On Tue, 01 Dec 2020, Daniel Vetter wrote: > On Tue, Dec 1, 2020 at 10:46 AM Lee Jones wrote: > > > > On Tue, 01 Dec 2020, Sam Ravnborg wrote: > > > > > Hi Lee, > > > > > > > > > > > Cop-out! > > > > > > > > Do what I do and make something up (joke)! :'D > > > > > > If I thought anyone would actually read the comments then maybe yes. > > > But I assume that apart from this thread no-one will read it. > > > > > > > > > > > > > Well, it fixes the warning ;) > > > > > > > > > > Yeah, I could not dig up anything useful to say here. > > > > > Was tempted to just drop all the kernel-doc syntax but that > > > > > was a larger change. > > > > > > > > Did you trace it from it's origin down to it's final use? > > > Yeah, but not something that seemed useful. > > > I could have added "translating from pixels->bytes" as they > > > are described somewhere else. But I could not convince myself > > > this was right so I just silenced the warning. > > > > > > The only reason I kept the kernel-doc in the first place is > > > that I am told some editors use it. > > > > > > The only effect the kernel-doc in fbdev has right now is burning > > > effort that could have been spent (better?) somewhere else, and > > > I would personally prefer to drop the kernel-doc annotations. > > > > > > But I already discussed this in another thread (not fbdev related) > > > and I was told it was useful for some, so it is kept. > > > > I personally think they should be kept. Despite not being referenced > > by any kernel-doc:: key-words. As you say, it can be helpful as an > > in-code reference for driver writers, people debugging code, et al. > > > > Not sure I would just repeat the variable name just to silence the > > warning though - that is definitely a hack. In the thousands > > (literally!) of these that I've fixed thus far, I haven't needed to do > > that. > > Personally what I've done is to just remove the kerneldoc marker (and > anything else that's obviously wrong) and leave plain comments behind. > At least for old outdated code that no one actively maintains anymore. > Keeps the comment as maybe something useful, and avoids pointless busy > work of inventing kerneldoc which might or might not actually be > correctly describing what's going on. Right. Demoting is also a good option if in doubt. -- 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 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 11:00 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 10:40 AM Thomas Zimmermann wrote:
Hi
Am 01.12.20 um 10:10 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmermann wrote:
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must hold
the GEM
+ * object's reservation lock from when calling this function until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules you'd like
to have here isn't enough. We need to roll this out at the dma-buf level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf it'll come
back through shmem helpers (and other helpers and other subsystems) back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with just
temporarily mapping buffers. So there we need to pin them, which I think
means we'll need 2 version of dma_buf_vmap - one that's temporary and
requires we hold dma_resv lock, the other requires that the buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions which I
added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't allow for
specifying where to pin. With fbdev emulation, this means that console
buffers might never make it to VRAM for scanout. If anything, the policy
should be that pin always pins in HW-accessible memory.
Pin has quite a bit of overhead (more locking, buffer movement), so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock internally.
Therefore I think we still would want some additional helpers, such as:
pin_unlocked(), which acquires the resv lock, calls regular pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned and
then calls regalar vmap. Same for vunmap_pinned()
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
So media drivers go through dma-buf, which means we always pin into
system memory. Which I guess for vram-only display drivers makes no
sense and should be rejected, but we still need somewhat consistent
rules.
The other thing is that if you do a dma_buf_attach without dynamic
mode, dma-buf will pin things for you already. So in many cases it
Do you have a pointer to code that illustrates this well?
could be that we don't need a separate pin (but since the pin is in
the exporter, not dma-buf layer, we can't check for that). I'm also
not seeing why existing users need to split up their dma_buf_vmap into
a pin + vmap, they don't need them separately.
It's two different operations, with pin having some possible overhead
and failure conditions. And during the last discussion, pin was say to
be for userspace-managed buffers. Kernel code should hold the
reservation lock.
For my POV, the current interfaces have no clear policy or semantics.
Looking through the different GEM implementations, each
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Am 01.12.20 um 11:27 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:00 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 10:40 AM Thomas Zimmermann
wrote:
Hi
Am 01.12.20 um 10:10 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmermann
wrote:
Hi
Am 30.11.20 um 16:33 schrieb Christian König:
Am 30.11.20 um 16:30 schrieb Daniel Vetter:
On Mon, Nov 30, 2020 at 01:04:26PM +0100, Thomas Zimmermann wrote:
Mapping a GEM object's buffer into kernel address space
prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM
BOs for
short periods of time; unless the GEM implementation provides
additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c
b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device
specific handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers
must hold
the GEM
+ * object's reservation lock from when calling this function
until
releasing the
+ * mapping. Holding onto a mapping and the associated reservation
lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to
drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
This is a dma-buf hook, which means just documenting the rules
you'd like
to have here isn't enough. We need to roll this out at the
dma-buf level,
and enforce it.
Enforce it = assert_lock_held
Roll out = review everyone. Because this goes through dma-buf
it'll come
back through shmem helpers (and other helpers and other
subsystems) back
to any driver using vmap for gpu buffers. This includes the media
subsystem, and the media subsystem definitely doesn't cope with
just
temporarily mapping buffers. So there we need to pin them, which
I think
means we'll need 2 version of dma_buf_vmap - one that's
temporary and
requires we hold dma_resv lock, the other requires that the
buffer is
pinned.
OR start to proper use the dma_buf_pin/dma_buf_unpin functions
which I
added to cover this use case as well.
While I generally agree, here are some thoughts:
I found all generic pin functions useless, because they don't
allow for
specifying where to pin. With fbdev emulation, this means that
console
buffers might never make it to VRAM for scanout. If anything, the
policy
should be that pin always pins in HW-accessible memory.
Pin has quite a bit of overhead (more locking, buffer movement),
so it
should be the second choice after regular vmap. To make both work
together, pin probably relies on holding the reservation lock
internally.
Therefore I think we still would want some additional helpers,
such as:
pin_unlocked(), which acquires the resv lock, calls regular
pin and
then drops the resv lock. Same for unpin_unlocked()
vmap_pinned(), which enforces that the buffer has been pinned
and
then calls regalar vmap. Same for vunmap_pinned()
A typical pattern with these functions would look like this.
drm_gem_object bo;
dma_buf_map map;
init() {
pin_unlocked(bo);
vmap_pinned(bo, map);
}
worker() {
begin_cpu_access()
// access bo via map
end_cpu_access()
}
fini() {
vunmap_pinned(bo, map);
unpin_unlocked(bo);
}
init()
while (...) {
worker()
}
fini()
Is that reasonable for media drivers?
So media drivers go through dma-buf, which means we always pin into
system memory. Which I guess for vram-only display drivers makes no
sense and should be rejected, but we still need somewhat consistent
rules.
The other thing is that if you do a dma_buf_attach without dynamic
mode, dma-buf will pin things for you already. So in many cases it
Do you have a pointer to code that illustrates this well?
could be that we don't need a separate pin (but since the pin is in
the exporter, not dma-buf layer, we can't check for that). I'm also
not seeing why existing users need to split up their dma_buf_vmap into
a pin + vmap, they don't need them separately.
It's two different operations, with pin having some possible overhead
and failure conditions. And during the last discussion, pin was say to
be for userspace-managed buffers. Kernel code should hold the
reservation lock.
For my POV, the current interfaces have n
[PATCH v2 00/20] drm: Move struct drm_device.pdev to legacy
The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devices. Meanwhile we also support USB, SPI and platform devices. Each of those uses the generic device stored in struct drm_device.dev. To reduce duplication and remove the special case of PCI, this patchset converts all modesetting drivers from pdev to dev and makes pdev a field for legacy UMS drivers. For PCI devices, the pointer in struct drm_device.dev can be upcasted to struct pci_device; or tested for PCI with dev_is_pci(). In several places the code can use the dev field directly. After converting all drivers and the DRM core, the pdev fields becomes only relevant for legacy drivers. In a later patchset, we may want to convert these as well and remove pdev entirely. The patchset touches many files, but the individual changes are mostly trivial. I suggest to merge each driver's patch through the respective tree and later the rest through drm-misc-next. v2: * move whitespace fixes into separate patches (Alex, Sam) * move i915 gt/ and gvt/ changes into separate patches (Joonas) Thomas Zimmermann (20): drm/amdgpu: Fix trailing whitespaces drm/amdgpu: Remove references to struct drm_device.pdev drm/ast: Remove references to struct drm_device.pdev drm/bochs: Remove references to struct drm_device.pdev drm/cirrus: Remove references to struct drm_device.pdev drm/gma500: Fix trailing whitespaces drm/gma500: Remove references to struct drm_device.pdev drm/hibmc: Remove references to struct drm_device.pdev drm/i915: Remove references to struct drm_device.pdev drm/i915/gt: Remove references to struct drm_device.pdev drm/i915/gvt: Remove references to struct drm_device.pdev drm/mgag200: Remove references to struct drm_device.pdev drm/nouveau: Remove references to struct drm_device.pdev drm/qxl: Remove references to struct drm_device.pdev drm/radeon: Fix trailing whitespaces drm/radeon: Remove references to struct drm_device.pdev drm/vboxvideo: Remove references to struct drm_device.pdev drm/virtgpu: Remove references to struct drm_device.pdev drm/vmwgfx: Remove references to struct drm_device.pdev drm: Upcast struct drm_device.dev to struct pci_device; replace pdev drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 23 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 +-- drivers/gpu/drm/ast/ast_drv.c | 4 +- drivers/gpu/drm/ast/ast_main.c| 25 +++--- drivers/gpu/drm/ast/ast_mm.c | 17 ++-- drivers/gpu/drm/ast/ast_mode.c| 5 +- drivers/gpu/drm/ast/ast_post.c| 8 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 - drivers/gpu/drm/bochs/bochs_hw.c | 4 +- drivers/gpu/drm/drm_agpsupport.c | 9 +- drivers/gpu/drm/drm_bufs.c| 4 +- drivers/gpu/drm/drm_edid.c| 7 +- drivers/gpu/drm/drm_irq.c | 12 +-- drivers/gpu/drm/drm_pci.c | 26 +++--- drivers/gpu/drm/drm_vm.c | 2 +- drivers/gpu/drm/gma500/cdv_device.c | 30 --- drivers/gpu/drm/gma500/cdv_intel_crt.c| 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 4 +- drivers/gpu/drm/gma500/framebuffer.c | 9 +- drivers/gpu/drm/gma500/gma_device.c | 3 +- drivers/gpu/drm/gma500/gma_display.c | 4 +- drivers/gpu/drm/gma500/gtt.c | 20 +++-- drivers/gpu/drm/gma500/intel_bios.c | 6 +- drivers/gpu/drm/gma500/intel_gmbus.c | 4 +- drivers/gpu/drm/gma500/intel_i2c.c| 2 +- drivers/gpu/drm/gma500/mdfld_device.c | 4 +- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 8 +- drivers/gpu/drm/gma500/mid_bios.c | 9 +- drivers/gpu/drm/gma500/oaktrail_device.c | 5 +- drivers/gpu/drm/gma500/oaktrail_lvds.c| 2 +- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c| 2 +- drivers/gpu/drm/gma500/opregion.c | 3 +- drivers/gpu/drm/gma500/power.c| 13 +-- drivers/gpu/drm/gma500/psb_drv.c | 16 ++-- drivers/gpu/drm/gma500/psb_drv.h | 8 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 6 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c| 36 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 10 +-- .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 4 +- drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 14 +-- drivers/gpu/drm/i915/display/in
[PATCH v2 02/20] drm/amdgpu: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert amdgpu to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Alex Deucher
Acked-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 -
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 +-
7 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index da23c0f21311..26ee571ff9f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1404,9 +1404,9 @@ static void amdgpu_switcheroo_set_state(struct pci_dev
*pdev,
/* don't suspend or resume card normally */
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
- pci_set_power_state(dev->pdev, PCI_D0);
- amdgpu_device_load_pci_state(dev->pdev);
- r = pci_enable_device(dev->pdev);
+ pci_set_power_state(pdev, PCI_D0);
+ amdgpu_device_load_pci_state(pdev);
+ r = pci_enable_device(pdev);
if (r)
DRM_WARN("pci_enable_device failed (%d)\n", r);
amdgpu_device_resume(dev, true);
@@ -1418,10 +1418,10 @@ static void amdgpu_switcheroo_set_state(struct pci_dev
*pdev,
drm_kms_helper_poll_disable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
amdgpu_device_suspend(dev, true);
- amdgpu_device_cache_pci_state(dev->pdev);
+ amdgpu_device_cache_pci_state(pdev);
/* Shut down the device */
- pci_disable_device(dev->pdev);
- pci_set_power_state(dev->pdev, PCI_D3cold);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3cold);
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
}
}
@@ -1684,8 +1684,7 @@ static void amdgpu_device_enable_virtual_display(struct
amdgpu_device *adev)
adev->enable_virtual_display = false;
if (amdgpu_virtual_display) {
- struct drm_device *ddev = adev_to_drm(adev);
- const char *pci_address_name = pci_name(ddev->pdev);
+ const char *pci_address_name = pci_name(adev->pdev);
char *pciaddstr, *pciaddstr_tmp, *pciaddname_tmp, *pciaddname;
pciaddstr = kstrdup(amdgpu_virtual_display, GFP_KERNEL);
@@ -3375,7 +3374,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
}
}
- pci_enable_pcie_error_reporting(adev->ddev.pdev);
+ pci_enable_pcie_error_reporting(adev->pdev);
/* Post card if necessary */
if (amdgpu_device_need_post(adev)) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 2e8a8b57639f..77974c3981fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -721,13 +721,14 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct amdgpu_device *adev = drm_to_adev(dev);
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj == NULL) {
- dev_err(&dev->pdev->dev, "No GEM object associated to handle
0x%08X, "
+ dev_err(&adev->pdev->dev, "No GEM object associated to handle
0x%08X, "
"can't create framebuffer\n", mode_cmd->handles[0]);
return ERR_PTR(-ENOENT);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 624294e0b9f3..bdc35c3f8523 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1192,7 +1192,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- ddev->pdev = pdev;
pci_set_drvdata(pdev, ddev);
ret = amdgpu_driver_load_kms(adev, ent->driver_data);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 0bf7d36c6686..51cd49c6f38f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -271,7 +271,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
DRM_INFO("fb depth is %d\n", fb->format->depth);
[PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Acked-by: Sam Ravnborg Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5f304425c948..da23c0f21311 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4922,8 +4922,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta case pci_channel_io_normal: return PCI_ERS_RESULT_CAN_RECOVER; /* Fatal error, prepare for slot reset */ - case pci_channel_io_frozen: - /* + case pci_channel_io_frozen: + /* * Cancel and wait for all TDRs in progress if failing to * set adev->in_gpu_reset in amdgpu_device_lock_adev * @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) goto out; } - adev->in_pci_err_recovery = true; + adev->in_pci_err_recovery = true; r = amdgpu_device_pre_asic_reset(adev, NULL, &need_full_reset); adev->in_pci_err_recovery = false; if (r) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/20] drm/gma500: Fix trailing whitespaces
Adhere to kernel coding style.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_device.c | 8
drivers/gpu/drm/gma500/intel_bios.c | 4 ++--
drivers/gpu/drm/gma500/oaktrail_device.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index e75293e4a52f..e0b728f246fb 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -421,16 +421,16 @@ static int cdv_power_up(struct drm_device *dev)
static void cdv_hotplug_work_func(struct work_struct *work)
{
struct drm_psb_private *dev_priv = container_of(work, struct
drm_psb_private,
- hotplug_work);
+ hotplug_work);
struct drm_device *dev = dev_priv->dev;
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
-}
+}
/* The core driver has received a hotplug IRQ. We are in IRQ context
so extract the needed information and kick off queued processing */
-
+
static int cdv_hotplug_event(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
@@ -449,7 +449,7 @@ static void cdv_hotplug_enable(struct drm_device *dev, bool
on)
} else {
REG_WRITE(PORT_HOTPLUG_EN, 0);
REG_WRITE(PORT_HOTPLUG_STAT, REG_READ(PORT_HOTPLUG_STAT));
- }
+ }
}
static const char *force_audio_names[] = {
diff --git a/drivers/gpu/drm/gma500/intel_bios.c
b/drivers/gpu/drm/gma500/intel_bios.c
index 8ad6337eeba3..08e1dacbdbc8 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -50,7 +50,7 @@ parse_edp(struct drm_psb_private *dev_priv, struct bdb_header
*bdb)
uint8_t panel_type;
edp = find_section(bdb, BDB_EDP);
-
+
dev_priv->edp.bpp = 18;
if (!edp) {
if (dev_priv->edp.support) {
@@ -80,7 +80,7 @@ parse_edp(struct drm_psb_private *dev_priv, struct bdb_header
*bdb)
dev_priv->edp.pps = *edp_pps;
DRM_DEBUG_KMS("EDP timing in vbt t1_t3 %d t8 %d t9 %d t10 %d t11_t12
%d\n",
- dev_priv->edp.pps.t1_t3, dev_priv->edp.pps.t8,
+ dev_priv->edp.pps.t1_t3, dev_priv->edp.pps.t8,
dev_priv->edp.pps.t9, dev_priv->edp.pps.t10,
dev_priv->edp.pps.t11_t12);
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 8754290b0e23..d9f8324f7c58 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -505,7 +505,7 @@ static int oaktrail_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
int ret;
-
+
if (pci_enable_msi(dev->pdev))
dev_warn(dev->dev, "Enabling MSI failed!\n");
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 063c66bb946d..49228e2cf480 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -216,7 +216,7 @@ static void psb_intel_lvds_set_power(struct drm_device
*dev, bool on)
dev_err(dev->dev, "set power, chip off!\n");
return;
}
-
+
if (on) {
REG_WRITE(PP_CONTROL, REG_READ(PP_CONTROL) |
POWER_TARGET_ON);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/20] drm/ast: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert ast to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_drv.c | 4 ++--
drivers/gpu/drm/ast/ast_main.c | 25 +
drivers/gpu/drm/ast/ast_mm.c | 17 +
drivers/gpu/drm/ast/ast_mode.c | 5 +++--
drivers/gpu/drm/ast/ast_post.c | 8 +---
5 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 667b450606ef..ea8164e7a6dc 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -147,7 +147,7 @@ static int ast_drm_freeze(struct drm_device *dev)
error = drm_mode_config_helper_suspend(dev);
if (error)
return error;
- pci_save_state(dev->pdev);
+ pci_save_state(to_pci_dev(dev->dev));
return 0;
}
@@ -162,7 +162,7 @@ static int ast_drm_resume(struct drm_device *dev)
{
int ret;
- if (pci_enable_device(dev->pdev))
+ if (pci_enable_device(to_pci_dev(dev->dev)))
return -EIO;
ret = ast_drm_thaw(dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 1b13199858cb..0ac3c2039c4b 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -67,8 +67,9 @@ uint8_t ast_get_index_reg_mask(struct ast_private *ast,
static void ast_detect_config_mode(struct drm_device *dev, u32 *scu_rev)
{
- struct device_node *np = dev->pdev->dev.of_node;
+ struct device_node *np = dev->dev->of_node;
struct ast_private *ast = to_ast_private(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
uint32_t data, jregd0, jregd1;
/* Defaults */
@@ -85,7 +86,7 @@ static void ast_detect_config_mode(struct drm_device *dev,
u32 *scu_rev)
}
/* Not all families have a P2A bridge */
- if (dev->pdev->device != PCI_CHIP_AST2000)
+ if (pdev->device != PCI_CHIP_AST2000)
return;
/*
@@ -119,6 +120,7 @@ static void ast_detect_config_mode(struct drm_device *dev,
u32 *scu_rev)
static int ast_detect_chip(struct drm_device *dev, bool *need_post)
{
struct ast_private *ast = to_ast_private(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
uint32_t jreg, scu_rev;
/*
@@ -143,19 +145,19 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
ast_detect_config_mode(dev, &scu_rev);
/* Identify chipset */
- if (dev->pdev->revision >= 0x50) {
+ if (pdev->revision >= 0x50) {
ast->chip = AST2600;
drm_info(dev, "AST 2600 detected\n");
- } else if (dev->pdev->revision >= 0x40) {
+ } else if (pdev->revision >= 0x40) {
ast->chip = AST2500;
drm_info(dev, "AST 2500 detected\n");
- } else if (dev->pdev->revision >= 0x30) {
+ } else if (pdev->revision >= 0x30) {
ast->chip = AST2400;
drm_info(dev, "AST 2400 detected\n");
- } else if (dev->pdev->revision >= 0x20) {
+ } else if (pdev->revision >= 0x20) {
ast->chip = AST2300;
drm_info(dev, "AST 2300 detected\n");
- } else if (dev->pdev->revision >= 0x10) {
+ } else if (pdev->revision >= 0x10) {
switch (scu_rev & 0x0300) {
case 0x0200:
ast->chip = AST1100;
@@ -265,7 +267,7 @@ static int ast_detect_chip(struct drm_device *dev, bool
*need_post)
static int ast_get_dram_info(struct drm_device *dev)
{
- struct device_node *np = dev->pdev->dev.of_node;
+ struct device_node *np = dev->dev->of_node;
struct ast_private *ast = to_ast_private(dev);
uint32_t mcr_cfg, mcr_scu_mpll, mcr_scu_strap;
uint32_t denum, num, div, ref_pll, dsel;
@@ -409,10 +411,9 @@ struct ast_private *ast_device_create(const struct
drm_driver *drv,
return ast;
dev = &ast->base;
- dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
- ast->regs = pci_iomap(dev->pdev, 1, 0);
+ ast->regs = pci_iomap(pdev, 1, 0);
if (!ast->regs)
return ERR_PTR(-EIO);
@@ -421,14 +422,14 @@ struct ast_private *ast_device_create(const struct
drm_driver *drv,
* assume the chip has MMIO enabled by default (rev 0x20
* and higher).
*/
- if (!(pci_resource_flags(dev->pdev, 2) & IORESOURCE_IO)) {
+ if (!(pci_resource_flags(pdev, 2) & IORESOURCE_IO)) {
drm_info(dev, "platform has no IO space, trying MMIO\n");
ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
}
/* "map" IO regs if the above hasn't done so already */
if (!ast->ioregs) {
- ast->ioregs = pci_iomap(dev->pdev, 2, 0);
+ ast->ioregs = pci_iomap(pdev, 2, 0);
if
[PATCH v2 04/20] drm/bochs: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert bochs to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 -
drivers/gpu/drm/bochs/bochs_hw.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index fd454225fd19..b469624fe40d 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -121,7 +121,6 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_free_dev;
- dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
ret = bochs_load(dev);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index dce4672e3fc8..2d7380a9890e 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -110,7 +110,7 @@ int bochs_hw_load_edid(struct bochs_device *bochs)
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
unsigned long addr, size, mem, ioaddr, iosize;
u16 id;
@@ -201,7 +201,7 @@ void bochs_hw_fini(struct drm_device *dev)
release_region(VBE_DISPI_IOPORT_INDEX, 2);
if (bochs->fb_map)
iounmap(bochs->fb_map);
- pci_release_regions(dev->pdev);
+ pci_release_regions(to_pci_dev(dev->dev));
kfree(bochs->edid);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/20] drm/hibmc: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert hibmc to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 10 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657fd99c..ac5868343d0c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -203,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
struct drm_device *dev = priv->dev;
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
resource_size_t addr, size, ioaddr, iosize;
ioaddr = pci_resource_start(pdev, 1);
@@ -249,7 +249,7 @@ static int hibmc_unload(struct drm_device *dev)
if (dev->irq_enabled)
drm_irq_uninstall(dev);
- pci_disable_msi(dev->pdev);
+ pci_disable_msi(to_pci_dev(dev->dev));
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
dev->dev_private = NULL;
@@ -258,6 +258,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct hibmc_drm_private *priv;
int ret;
@@ -287,11 +288,11 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
- ret = pci_enable_msi(dev->pdev);
+ ret = pci_enable_msi(pdev);
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = drm_irq_install(dev, dev->pdev->irq);
+ ret = drm_irq_install(dev, pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
@@ -324,7 +325,6 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
return PTR_ERR(dev);
}
- dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
ret = pci_enable_device(pdev);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
index 86d712090d87..410bd019bb35 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
@@ -83,7 +83,7 @@ int hibmc_ddc_create(struct drm_device *drm_dev,
connector->adapter.owner = THIS_MODULE;
connector->adapter.class = I2C_CLASS_DDC;
snprintf(connector->adapter.name, I2C_NAME_SIZE, "HIS i2c bit bus");
- connector->adapter.dev.parent = &drm_dev->pdev->dev;
+ connector->adapter.dev.parent = drm_dev->dev;
i2c_set_adapdata(&connector->adapter, connector);
connector->adapter.algo_data = &connector->bit_data;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 602ece11bb4a..77f075075db2 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -26,9 +26,9 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc)
struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = hibmc->dev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
- vmm = drm_vram_helper_alloc_mm(dev,
- pci_resource_start(dev->pdev, 0),
+ vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(pdev, 0),
hibmc->fb_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/20] drm/cirrus: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert cirrus to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Gerd Hoffmann --- drivers/gpu/drm/tiny/cirrus.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c index 561c49d8657a..a043e602199e 100644 --- a/drivers/gpu/drm/tiny/cirrus.c +++ b/drivers/gpu/drm/tiny/cirrus.c @@ -602,7 +602,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev, drm_mode_config_reset(dev); - dev->pdev = pdev; pci_set_drvdata(pdev, dev); ret = drm_dev_register(dev, 0); if (ret) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/20] drm/nouveau: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 12 +++-
drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 11 ---
drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 --
drivers/gpu/drm/nouveau/nouveau_vga.c | 20
10 files changed, 58 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 9d4a2d97507e..1d3542d6006b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -200,16 +200,17 @@ nv04_update_arb(struct drm_device *dev, int VClk, int bpp,
int MClk = nouveau_hw_get_clock(dev, PLL_MEMORY);
int NVClk = nouveau_hw_get_clock(dev, PLL_CORE);
uint32_t cfg1 = nvif_rd32(device, NV04_PFB_CFG1);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
sim_data.pclk_khz = VClk;
sim_data.mclk_khz = MClk;
sim_data.nvclk_khz = NVClk;
sim_data.bpp = bpp;
sim_data.two_heads = nv_two_heads(dev);
- if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
- (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
+ if ((pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
+ (pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
- int domain = pci_domain_nr(dev->pdev->bus);
+ int domain = pci_domain_nr(pdev->bus);
pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
0x7c, &type);
@@ -251,11 +252,12 @@ void
nouveau_calc_arb(struct drm_device *dev, int vclk, int bpp, int *burst, int
*lwm)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_KELVIN)
nv04_update_arb(dev, vclk, bpp, burst, lwm);
- else if ((dev->pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
-(dev->pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
+ else if ((pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
+(pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
*burst = 128;
*lwm = 0x0480;
} else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 5ace5e906949..f0a24126641a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -130,7 +130,7 @@ static inline bool
nv_two_heads(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
- const int impl = dev->pdev->device & 0x0ff0;
+ const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_CELSIUS && impl
!= 0x0100 &&
impl != 0x0150 && impl != 0x01a0 && impl != 0x0200)
@@ -142,14 +142,14 @@ nv_two_heads(struct drm_device *dev)
static inline bool
nv_gf4_disp_arch(struct drm_device *dev)
{
- return nv_two_heads(dev) && (dev->pdev->device & 0x0ff0) != 0x0110;
+ return nv_two_heads(dev) && (to_pci_dev(dev->dev)->device & 0x0ff0) !=
0x0110;
}
static inline bool
nv_two_reg_pll(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
- const int impl = dev->pdev->device & 0x0ff0;
+ const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
if (impl == 0x0310 || impl == 0x0340 || drm->client.device.info.family
>= NV_DEVICE_INFO_V0_CURIE)
return true;
@@ -160,9 +160,11 @@ static inline bool
nv_match_device(struct drm_device *dev, unsigned device,
unsigned sub_vendor, unsigned sub_device)
{
- return dev->pdev->device == device &&
- dev->pdev->subsystem_vendor == sub_vendor &&
- dev->pdev->subsystem_device == sub_device;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+ return pdev->device == device &&
+ pdev->subsystem_vendor == sub_vendor &&
+ pdev->subsystem_device == sub_device;
}
#include
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b674d68ef28a..f7d35657aa64 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -214,14 +214,15 @@ nouveau_hw_pllvals_to_clk(struct nvkm_pll_vals *pv)
int
nouveau_hw_get_clock(struct
[PATCH v2 10/20] drm/i915/gt: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +++---
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d4e988b2816a..71bd2e22e7c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1228,7 +1228,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
/* Waiting to drain ELSP? */
if (execlists_active(&engine->execlists)) {
- synchronize_hardirq(engine->i915->drm.pdev->irq);
+ synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
intel_engine_flush_submission(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index cf94525be2c1..591c6a2a0a8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -760,7 +760,7 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
int ret;
@@ -830,7 +830,7 @@ static struct resource pci_resource(struct pci_dev *pdev,
int bar)
static int gen8_gmch_probe(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
@@ -974,7 +974,7 @@ static u64 iris_pte_encode(dma_addr_t addr,
static int gen6_gmch_probe(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
@@ -1037,7 +1037,7 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
phys_addr_t gmadr_base;
int ret;
- ret = intel_gmch_probe(i915->bridge_dev, i915->drm.pdev, NULL);
+ ret = intel_gmch_probe(i915->bridge_dev, to_pci_dev(i915->drm.dev),
NULL);
if (!ret) {
drm_err(&i915->drm, "failed to set up gmch\n");
return -EIO;
@@ -1077,7 +1077,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
- ggtt->vm.dma = &i915->drm.pdev->dev;
+ ggtt->vm.dma = i915->drm.dev;
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 46d9aceda64c..01b7d08532f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -301,7 +301,7 @@ void ppgtt_init(struct i915_ppgtt *ppgtt, struct intel_gt
*gt)
ppgtt->vm.gt = gt;
ppgtt->vm.i915 = i915;
- ppgtt->vm.dma = &i915->drm.pdev->dev;
+ ppgtt->vm.dma = i915->drm.dev;
ppgtt->vm.total = BIT_ULL(INTEL_INFO(i915)->ppgtt_size);
i915_address_space_init(&ppgtt->vm, VM_CLASS_PPGTT);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index d7b8e4457fc2..cce53fb9589c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -485,14 +485,14 @@ static bool rc6_supported(struct intel_rc6 *rc6)
static void rpm_get(struct intel_rc6 *rc6)
{
GEM_BUG_ON(rc6->wakeref);
- pm_runtime_get_sync(&rc6_to_i915(rc6)->drm.pdev->dev);
+ pm_runtime_get_sync(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = true;
}
static void rpm_put(struct intel_rc6 *rc6)
{
GEM_BUG_ON(!rc6->wakeref);
- pm_runtime_put(&rc6_to_i915(rc6)->drm.pdev->dev);
+ pm_runtime_put(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = false;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 3654c955e6be..a49faf4ec139 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -180,7 +180,7 @@ static int i915_do_reset(struct intel_gt *gt,
intel_engine_mask_t engine_mask,
unsigned int retry)
{
- struct pci_dev *pdev = gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev);
int err;
/* Assert reset for at least 20 usec, and wa
[PATCH v2 09/20] drm/i915: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
drivers/gpu/drm/i915/display/intel_csr.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +-
.../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++--
drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 8
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 20 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_getparam.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_pmu.c | 5 +++--
drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++--
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_region_lmem.c | 8
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
32 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4cc949b228f2..8879676372a3 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2088,7 +2088,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t size)
static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c449d28d0560..a6e13208dc50 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private
*dev_priv,
static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 hpllcc = 0;
/*
@@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private
*dev_priv,
static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, &gcfgc);
@@ -162,7 +162,7 @@ static void i915gm_get_cdclk(struct drm_i915_private
*dev_priv,
static void i945gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, &gcfgc);
@@ -256,7 +256,7 @@ static unsigned int intel_hpll_vco(struct drm_i915_private
*dev_priv)
static void g33_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
static const u8 div_3200[] = { 12, 10, 8, 7, 5, 16 };
static const u8 div_4000[] = { 14, 12, 10, 8, 6, 20 };
static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
@@ -305,7 +305,7 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_
[PATCH v2 11/20] drm/i915/gvt: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/gvt/firmware.c | 10 +-
drivers/gpu/drm/i915/gvt/gtt.c | 12 ++--
drivers/gpu/drm/i915/gvt/gvt.c | 6 +++---
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
5 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index ad86c5eb5bba..b490e3db2e38 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -374,6 +374,7 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
bool primary)
{
struct intel_gvt *gvt = vgpu->gvt;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
const struct intel_gvt_device_info *info = &gvt->device_info;
u16 *gmch_ctl;
u8 next;
@@ -407,9 +408,9 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
memset(vgpu_cfg_space(vgpu) + INTEL_GVT_PCI_OPREGION, 0, 4);
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_GTTMMIO].size =
- pci_resource_len(gvt->gt->i915->drm.pdev, 0);
+ pci_resource_len(pdev, 0);
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_APERTURE].size =
- pci_resource_len(gvt->gt->i915->drm.pdev, 2);
+ pci_resource_len(pdev, 2);
memset(vgpu_cfg_space(vgpu) + PCI_ROM_ADDRESS, 0, 4);
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index 990a181094e3..1a8274a3f4b1 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -76,7 +76,7 @@ static int mmio_snapshot_handler(struct intel_gvt *gvt, u32
offset, void *data)
static int expose_firmware_sysfs(struct intel_gvt *gvt)
{
struct intel_gvt_device_info *info = &gvt->device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
void *firmware;
void *p;
@@ -127,7 +127,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
static void clean_firmware_sysfs(struct intel_gvt *gvt)
{
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
device_remove_bin_file(&pdev->dev, &firmware_attr);
vfree(firmware_attr.private);
@@ -151,7 +151,7 @@ static int verify_firmware(struct intel_gvt *gvt,
const struct firmware *fw)
{
struct intel_gvt_device_info *info = &gvt->device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
unsigned long id, crc32_start;
const void *mem;
@@ -205,7 +205,7 @@ static int verify_firmware(struct intel_gvt *gvt,
int intel_gvt_load_firmware(struct intel_gvt *gvt)
{
struct intel_gvt_device_info *info = &gvt->device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct intel_gvt_firmware *firmware = &gvt->firmware;
struct gvt_firmware_header *h;
const struct firmware *fw;
@@ -240,7 +240,7 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
gvt_dbg_core("request hw state firmware %s...\n", path);
- ret = request_firmware(&fw, path, &gvt->gt->i915->drm.pdev->dev);
+ ret = request_firmware(&fw, path, gvt->gt->i915->drm.dev);
kfree(path);
if (ret)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 897c007ea96a..6d12a5a401f6 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -746,7 +746,7 @@ static int detach_oos_page(struct intel_vgpu *vgpu,
static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt *spt)
{
- struct device *kdev = &spt->vgpu->gvt->gt->i915->drm.pdev->dev;
+ struct device *kdev = spt->vgpu->gvt->gt->i915->drm.dev;
trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
@@ -831,7 +831,7 @@ static int reclaim_one_ppgtt_mm(struct intel_gvt *gvt);
static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
struct intel_vgpu *vgpu, enum intel_gvt_gtt_type type)
{
- struct device *kdev = &vgpu->gvt->gt->i915->drm.pdev->dev;
+ struct device *kdev = vgpu->gvt->gt->i915->drm.dev;
struct intel_vgpu_ppgtt_spt *spt = NULL;
dma_addr_t daddr;
int ret;
@@ -2402,7 +2402,7 @@ static int alloc_scratch_pages(struct intel_vgpu *vgpu,
vgpu->gvt->device_info.gtt_entry_size_shift;
void *scratch_pt;
int i;
- struct device *dev = &vgpu->gvt
[PATCH v2 07/20] drm/gma500: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert gma500 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_device.c| 22 -
drivers/gpu/drm/gma500/cdv_intel_crt.c | 3 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c| 4 +--
drivers/gpu/drm/gma500/framebuffer.c | 9 +++---
drivers/gpu/drm/gma500/gma_device.c| 3 +-
drivers/gpu/drm/gma500/gma_display.c | 4 +--
drivers/gpu/drm/gma500/gtt.c | 20 ++--
drivers/gpu/drm/gma500/intel_bios.c| 2 +-
drivers/gpu/drm/gma500/intel_gmbus.c | 4 +--
drivers/gpu/drm/gma500/intel_i2c.c | 2 +-
drivers/gpu/drm/gma500/mdfld_device.c | 4 ++-
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 8 ++---
drivers/gpu/drm/gma500/mid_bios.c | 9 --
drivers/gpu/drm/gma500/oaktrail_device.c | 3 +-
drivers/gpu/drm/gma500/oaktrail_lvds.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 2 +-
drivers/gpu/drm/gma500/opregion.c | 3 +-
drivers/gpu/drm/gma500/power.c | 13
drivers/gpu/drm/gma500/psb_drv.c | 16 +-
drivers/gpu/drm/gma500/psb_drv.h | 8 ++---
drivers/gpu/drm/gma500/psb_intel_lvds.c| 4 +--
drivers/gpu/drm/gma500/psb_intel_sdvo.c| 2 +-
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 36 +++---
23 files changed, 101 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index e0b728f246fb..19e055dbd4c2 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -95,13 +95,14 @@ static u32 cdv_get_max_backlight(struct drm_device *dev)
static int cdv_get_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 val = REG_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
if (cdv_backlight_combination_mode(dev)) {
u8 lbpc;
val &= ~1;
- pci_read_config_byte(dev->pdev, 0xF4, &lbpc);
+ pci_read_config_byte(pdev, 0xF4, &lbpc);
val *= lbpc;
}
return (val * 100)/cdv_get_max_backlight(dev);
@@ -111,6 +112,7 @@ static int cdv_get_brightness(struct backlight_device *bd)
static int cdv_set_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
int level = bd->props.brightness;
u32 blc_pwm_ctl;
@@ -128,7 +130,7 @@ static int cdv_set_brightness(struct backlight_device *bd)
lbpc = level * 0xfe / max + 1;
level /= lbpc;
- pci_write_config_byte(dev->pdev, 0xF4, lbpc);
+ pci_write_config_byte(pdev, 0xF4, lbpc);
}
blc_pwm_ctl = REG_READ(BLC_PWM_CTL) & ~BACKLIGHT_DUTY_CYCLE_MASK;
@@ -205,8 +207,9 @@ static inline void CDV_MSG_WRITE32(int domain, uint port,
uint offset,
static void cdv_init_pm(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 pwr_cnt;
- int domain = pci_domain_nr(dev->pdev->bus);
+ int domain = pci_domain_nr(pdev->bus);
int i;
dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
@@ -234,6 +237,8 @@ static void cdv_init_pm(struct drm_device *dev)
static void cdv_errata(struct drm_device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
/* Disable bonus launch.
* CPU and GPU competes for memory and display misses updates and
* flickers. Worst with dual core, dual displays.
@@ -242,7 +247,7 @@ static void cdv_errata(struct drm_device *dev)
* Bonus Launch to work around the issue, by degrading
* performance.
*/
-CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
+CDV_MSG_WRITE32(pci_domain_nr(pdev->bus), 3, 0x30, 0x08027108);
}
/**
@@ -255,12 +260,13 @@ static void cdv_errata(struct drm_device *dev)
static int cdv_save_display_registers(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct psb_save_area *regs = &dev_priv->regs;
struct drm_connector *connector;
dev_dbg(dev->dev, "Saving GPU registers.\n");
- pci_read_config_byte(dev->pdev, 0xF4, ®s->cdv.saveLBB);
+ pci_read_config_byte(pdev, 0xF4, ®s->cdv.saveLBB);
regs->cdv.saveDSPCLK_GATE_D = REG_READ(DSPCLK_GATE_D);
regs->cdv.saveRAMCLK_GATE_D = REG_READ(RAMCLK_GATE_D);
@@ -309,11 +315,12 @@ static int cdv_save_display_registers(struct drm_device
*dev)
static int cdv_restore_display_registers(struct drm_device *dev)
{
[PATCH v2 12/20] drm/mgag200: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert mgag200 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 20 +++-
drivers/gpu/drm/mgag200/mgag200_i2c.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mm.c | 10 ++
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index a977c9f49719..4e4c105f9a50 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -47,10 +47,11 @@ static const struct drm_driver mgag200_driver = {
static bool mgag200_has_sgram(struct mga_device *mdev)
{
struct drm_device *dev = &mdev->base;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 option;
int ret;
- ret = pci_read_config_dword(dev->pdev, PCI_MGA_OPTION, &option);
+ ret = pci_read_config_dword(pdev, PCI_MGA_OPTION, &option);
if (drm_WARN(dev, ret, "failed to read PCI config dword: %d\n", ret))
return false;
@@ -60,6 +61,7 @@ static bool mgag200_has_sgram(struct mga_device *mdev)
static int mgag200_regs_init(struct mga_device *mdev)
{
struct drm_device *dev = &mdev->base;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 option, option2;
u8 crtcext3;
@@ -99,13 +101,13 @@ static int mgag200_regs_init(struct mga_device *mdev)
}
if (option)
- pci_write_config_dword(dev->pdev, PCI_MGA_OPTION, option);
+ pci_write_config_dword(pdev, PCI_MGA_OPTION, option);
if (option2)
- pci_write_config_dword(dev->pdev, PCI_MGA_OPTION2, option2);
+ pci_write_config_dword(pdev, PCI_MGA_OPTION2, option2);
/* BAR 1 contains registers */
- mdev->rmmio_base = pci_resource_start(dev->pdev, 1);
- mdev->rmmio_size = pci_resource_len(dev->pdev, 1);
+ mdev->rmmio_base = pci_resource_start(pdev, 1);
+ mdev->rmmio_size = pci_resource_len(pdev, 1);
if (!devm_request_mem_region(dev->dev, mdev->rmmio_base,
mdev->rmmio_size, "mgadrmfb_mmio")) {
@@ -113,7 +115,7 @@ static int mgag200_regs_init(struct mga_device *mdev)
return -ENOMEM;
}
- mdev->rmmio = pcim_iomap(dev->pdev, 1, 0);
+ mdev->rmmio = pcim_iomap(pdev, 1, 0);
if (mdev->rmmio == NULL)
return -ENOMEM;
@@ -218,6 +220,7 @@ static void mgag200_g200_interpret_bios(struct mga_device
*mdev,
static void mgag200_g200_init_refclk(struct mga_device *mdev)
{
struct drm_device *dev = &mdev->base;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
unsigned char __iomem *rom;
unsigned char *bios;
size_t size;
@@ -226,7 +229,7 @@ static void mgag200_g200_init_refclk(struct mga_device
*mdev)
mdev->model.g200.pclk_max = 23;
mdev->model.g200.ref_clk = 27050;
- rom = pci_map_rom(dev->pdev, &size);
+ rom = pci_map_rom(pdev, &size);
if (!rom)
return;
@@ -244,7 +247,7 @@ static void mgag200_g200_init_refclk(struct mga_device
*mdev)
vfree(bios);
out:
- pci_unmap_rom(dev->pdev, rom);
+ pci_unmap_rom(pdev, rom);
}
static void mgag200_g200se_init_unique_id(struct mga_device *mdev)
@@ -301,7 +304,6 @@ mgag200_device_create(struct pci_dev *pdev, unsigned long
flags)
return mdev;
dev = &mdev->base;
- dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
ret = mgag200_device_init(mdev, flags);
diff --git a/drivers/gpu/drm/mgag200/mgag200_i2c.c
b/drivers/gpu/drm/mgag200/mgag200_i2c.c
index 09731e614e46..ac8e34eef513 100644
--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -126,7 +126,7 @@ struct mga_i2c_chan *mgag200_i2c_create(struct drm_device
*dev)
i2c->clock = clock;
i2c->adapter.owner = THIS_MODULE;
i2c->adapter.class = I2C_CLASS_DDC;
- i2c->adapter.dev.parent = &dev->pdev->dev;
+ i2c->adapter.dev.parent = dev->dev;
i2c->dev = dev;
i2c_set_adapdata(&i2c->adapter, i2c);
snprintf(i2c->adapter.name, sizeof(i2c->adapter.name), "mga i2c");
diff --git a/drivers/gpu/drm/mgag200/mgag200_mm.c
b/drivers/gpu/drm/mgag200/mgag200_mm.c
index 641f1aa992be..b667371b69a4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mm.c
@@ -78,11 +78,12 @@ static size_t mgag200_probe_vram(struct mga_device *mdev,
void __iomem *mem,
static void mgag200_mm_release(struct drm_device *dev, void *ptr)
{
struct mga_device *mdev = to_mga_device(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
mdev->vram_fb_available = 0;
iounmap(mdev->vram);
- arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
- pci
[PATCH v2 14/20] drm/qxl: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert qxl to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 3 ++-
drivers/gpu/drm/qxl/qxl_irq.c | 3 ++-
drivers/gpu/drm/qxl/qxl_kms.c | 1 -
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 6e7f16f4cec7..fb5f6a5e81d7 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -163,7 +163,7 @@ DEFINE_DRM_GEM_FOPS(qxl_fops);
static int qxl_drm_freeze(struct drm_device *dev)
{
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct qxl_device *qdev = to_qxl(dev);
int ret;
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 16e1e589508e..b6075f452b9e 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -370,13 +370,14 @@ static int qxl_clientcap_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv)
{
struct qxl_device *qdev = to_qxl(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_qxl_clientcap *param = data;
int byte, idx;
byte = param->index / 8;
idx = param->index % 8;
- if (dev->pdev->revision < 4)
+ if (pdev->revision < 4)
return -ENOSYS;
if (byte >= 58)
diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
index 1ba5a702d763..ddf6588a2a38 100644
--- a/drivers/gpu/drm/qxl/qxl_irq.c
+++ b/drivers/gpu/drm/qxl/qxl_irq.c
@@ -81,6 +81,7 @@ static void qxl_client_monitors_config_work_func(struct
work_struct *work)
int qxl_irq_init(struct qxl_device *qdev)
{
+ struct pci_dev *pdev = to_pci_dev(qdev->ddev.dev);
int ret;
init_waitqueue_head(&qdev->display_event);
@@ -93,7 +94,7 @@ int qxl_irq_init(struct qxl_device *qdev)
atomic_set(&qdev->irq_received_cursor, 0);
atomic_set(&qdev->irq_received_io_cmd, 0);
qdev->irq_received_error = 0;
- ret = drm_irq_install(&qdev->ddev, qdev->ddev.pdev->irq);
+ ret = drm_irq_install(&qdev->ddev, pdev->irq);
qdev->ram_header->int_mask = QXL_INTERRUPT_MASK;
if (unlikely(ret != 0)) {
DRM_ERROR("Failed installing irq: %d\n", ret);
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 228e2b9198f1..4a60a52ab62e 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -111,7 +111,6 @@ int qxl_device_init(struct qxl_device *qdev,
{
int r, sb;
- qdev->ddev.pdev = pdev;
pci_set_drvdata(pdev, &qdev->ddev);
mutex_init(&qdev->gem.mutex);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/20] drm/radeon: Fix trailing whitespaces
Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/radeon/r100.c | 2 +- drivers/gpu/drm/radeon/radeon_kms.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 24c8db673931..e4ae09b5294d 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -2797,7 +2797,7 @@ void r100_vram_init_sizes(struct radeon_device *rdev) rdev->mc.real_vram_size = 8192 * 1024; WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.real_vram_size); } - /* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM - + /* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM - * Novell bug 204882 + along with lots of ubuntu ones */ if (rdev->mc.aper_size > config_aper_size) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index abb3bdd9ca25..75b038740ea8 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -74,7 +74,7 @@ void radeon_driver_unload_kms(struct drm_device *dev) } radeon_acpi_fini(rdev); - + radeon_modeset_fini(rdev); radeon_device_fini(rdev); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/20] drm/radeon: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert radeon to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Alex Deucher
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/radeon/atombios_encoders.c| 6 +-
drivers/gpu/drm/radeon/r100.c | 25 +++---
drivers/gpu/drm/radeon/radeon.h | 32 +++
drivers/gpu/drm/radeon/radeon_atombios.c | 89 ++-
drivers/gpu/drm/radeon/radeon_bios.c | 6 +-
drivers/gpu/drm/radeon/radeon_combios.c | 55 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
drivers/gpu/drm/radeon/radeon_device.c| 17 ++--
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_fb.c| 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +-
drivers/gpu/drm/radeon/radeon_i2c.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 18 ++--
.../gpu/drm/radeon/radeon_legacy_encoders.c | 6 +-
drivers/gpu/drm/radeon/rs780_dpm.c| 7 +-
17 files changed, 142 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index cc5ee1b3af84..a9ae8b6c5991 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2065,9 +2065,9 @@ atombios_apply_encoder_quirks(struct drm_encoder *encoder,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
/* Funky macbooks */
- if ((dev->pdev->device == 0x71C5) &&
- (dev->pdev->subsystem_vendor == 0x106b) &&
- (dev->pdev->subsystem_device == 0x0080)) {
+ if ((rdev->pdev->device == 0x71C5) &&
+ (rdev->pdev->subsystem_vendor == 0x106b) &&
+ (rdev->pdev->subsystem_device == 0x0080)) {
if (radeon_encoder->devices & ATOM_DEVICE_LCD1_SUPPORT) {
uint32_t lvtma_bit_depth_control =
RREG32(AVIVO_LVTMA_BIT_DEPTH_CONTROL);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index e4ae09b5294d..984eeb893d76 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2611,7 +2611,6 @@ int r100_asic_reset(struct radeon_device *rdev, bool hard)
void r100_set_common_regs(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
bool force_dac2 = false;
u32 tmp;
@@ -2629,7 +2628,7 @@ void r100_set_common_regs(struct radeon_device *rdev)
* don't report it in the bios connector
* table.
*/
- switch (dev->pdev->device) {
+ switch (rdev->pdev->device) {
/* RN50 */
case 0x515e:
case 0x5969:
@@ -2639,17 +2638,17 @@ void r100_set_common_regs(struct radeon_device *rdev)
case 0x5159:
case 0x515a:
/* DELL triple head servers */
- if ((dev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
- ((dev->pdev->subsystem_device == 0x016c) ||
-(dev->pdev->subsystem_device == 0x016d) ||
-(dev->pdev->subsystem_device == 0x016e) ||
-(dev->pdev->subsystem_device == 0x016f) ||
-(dev->pdev->subsystem_device == 0x0170) ||
-(dev->pdev->subsystem_device == 0x017d) ||
-(dev->pdev->subsystem_device == 0x017e) ||
-(dev->pdev->subsystem_device == 0x0183) ||
-(dev->pdev->subsystem_device == 0x018a) ||
-(dev->pdev->subsystem_device == 0x019a)))
+ if ((rdev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
+ ((rdev->pdev->subsystem_device == 0x016c) ||
+(rdev->pdev->subsystem_device == 0x016d) ||
+(rdev->pdev->subsystem_device == 0x016e) ||
+(rdev->pdev->subsystem_device == 0x016f) ||
+(rdev->pdev->subsystem_device == 0x0170) ||
+(rdev->pdev->subsystem_device == 0x017d) ||
+(rdev->pdev->subsystem_device == 0x017e) ||
+(rdev->pdev->subsystem_device == 0x0183) ||
+(rdev->pdev->subsystem_device == 0x018a) ||
+(rdev->pdev->subsystem_device == 0x019a)))
force_dac2 = true;
break;
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 28cb8ced91b9..87ef62a7ec4e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2623,14 +2623,14 @@ void r100_pll_errata_after_index(struct radeon_device
*rdev);
(rdev->family == CHIP_RV410) || \
(rdev->family == CHIP_RS400) || \
(rdev->fami
[PATCH v2 18/20] drm/virtgpu: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 27f13bd29c13..a21dc3ad6f88 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -54,7 +54,6 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev,
struct virtio_device *vd
DRM_INFO("pci: %s detected at %s\n",
vga ? "virtio-vga" : "virtio-gpu-pci",
pname);
- dev->pdev = pdev;
if (vga)
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"virtiodrmfb");
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 19/20] drm/vmwgfx: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Acked-by: Sam Ravnborg
Cc: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +-
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 9a9fe10d829b..83a8d34704ea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -1230,7 +1230,7 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man,
/* First, try to allocate a huge chunk of DMA memory */
size = PAGE_ALIGN(size);
- man->map = dma_alloc_coherent(&dev_priv->dev->pdev->dev, size,
+ man->map = dma_alloc_coherent(dev_priv->dev->dev, size,
&man->handle, GFP_KERNEL);
if (man->map) {
man->using_mob = false;
@@ -1313,7 +1313,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct
vmw_private *dev_priv)
man->num_contexts = (dev_priv->capabilities & SVGA_CAP_HP_CMD_QUEUE) ?
2 : 1;
man->headers = dma_pool_create("vmwgfx cmdbuf",
- &dev_priv->dev->pdev->dev,
+ dev_priv->dev->dev,
sizeof(SVGACBHeader),
64, PAGE_SIZE);
if (!man->headers) {
@@ -1322,7 +1322,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct
vmw_private *dev_priv)
}
man->dheaders = dma_pool_create("vmwgfx inline cmdbuf",
- &dev_priv->dev->pdev->dev,
+ dev_priv->dev->dev,
sizeof(struct vmw_cmdbuf_dheader),
64, PAGE_SIZE);
if (!man->dheaders) {
@@ -1387,7 +1387,7 @@ void vmw_cmdbuf_remove_pool(struct vmw_cmdbuf_man *man)
ttm_bo_put(man->cmd_space);
man->cmd_space = NULL;
} else {
- dma_free_coherent(&man->dev_priv->dev->pdev->dev,
+ dma_free_coherent(man->dev_priv->dev->dev,
man->size, man->map, man->handle);
}
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 216daf93022c..e63e08f5b14f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -652,6 +652,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
enum vmw_res_type i;
bool refuse_dma = false;
char host_log[100] = {0};
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (unlikely(!dev_priv)) {
@@ -659,7 +660,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
return -ENOMEM;
}
- pci_set_master(dev->pdev);
+ pci_set_master(pdev);
dev_priv->dev = dev;
dev_priv->vmw_chipset = chipset;
@@ -688,9 +689,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
dev_priv->used_memory_size = 0;
- dev_priv->io_start = pci_resource_start(dev->pdev, 0);
- dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
- dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
+ dev_priv->io_start = pci_resource_start(pdev, 0);
+ dev_priv->vram_start = pci_resource_start(pdev, 1);
+ dev_priv->mmio_start = pci_resource_start(pdev, 2);
dev_priv->assume_16bpp = !!vmw_assume_16bpp;
@@ -840,7 +841,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
dev->dev_private = dev_priv;
- ret = pci_request_regions(dev->pdev, "vmwgfx probe");
+ ret = pci_request_regions(pdev, "vmwgfx probe");
dev_priv->stealth = (ret != 0);
if (dev_priv->stealth) {
/**
@@ -849,7 +850,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
DRM_INFO("It appears like vesafb is loaded. "
"Ignore above error if any.\n");
- ret = pci_request_region(dev->pdev, 2, "vmwgfx stealth probe");
+ ret = pci_request_region(pdev, 2, "vmwgfx stealth probe");
if (unlikely(ret != 0)) {
DRM_ERROR("Failed reserving the SVGA MMIO resource.\n");
goto out_no_device;
@@ -857,7 +858,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
}
if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
- ret = vmw_irq_install(dev, dev->pdev->irq);
+
[PATCH v2 20/20] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.
Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
code can use dev_is_pci() to test for a PCI device. This patch changes
the DRM core code and documentation accordingly. Struct drm_device.pdev
is being moved to legacy status.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/drm_agpsupport.c | 9 ++---
drivers/gpu/drm/drm_bufs.c | 4 ++--
drivers/gpu/drm/drm_edid.c | 7 ++-
drivers/gpu/drm/drm_irq.c| 12 +++-
drivers/gpu/drm/drm_pci.c| 26 +++---
drivers/gpu/drm/drm_vm.c | 2 +-
include/drm/drm_device.h | 12 +---
7 files changed, 46 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4c7ad46fdd21..a4040fe4f4ba 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -103,11 +103,13 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
*/
int drm_agp_acquire(struct drm_device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
if (!dev->agp)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
- dev->agp->bridge = agp_backend_acquire(dev->pdev);
+ dev->agp->bridge = agp_backend_acquire(pdev);
if (!dev->agp->bridge)
return -ENODEV;
dev->agp->acquired = 1;
@@ -402,14 +404,15 @@ int drm_agp_free_ioctl(struct drm_device *dev, void *data,
*/
struct drm_agp_head *drm_agp_init(struct drm_device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_agp_head *head = NULL;
head = kzalloc(sizeof(*head), GFP_KERNEL);
if (!head)
return NULL;
- head->bridge = agp_find_bridge(dev->pdev);
+ head->bridge = agp_find_bridge(pdev);
if (!head->bridge) {
- head->bridge = agp_backend_acquire(dev->pdev);
+ head->bridge = agp_backend_acquire(pdev);
if (!head->bridge) {
kfree(head);
return NULL;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index aeb1327e3077..e3d77dfefb0a 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -326,7 +326,7 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
* As we're limiting the address to 2^32-1 (or less),
* casting it down to 32 bits is no problem, but we
* need to point to a 64bit variable first. */
- map->handle = dma_alloc_coherent(&dev->pdev->dev,
+ map->handle = dma_alloc_coherent(dev->dev,
map->size,
&map->offset,
GFP_KERNEL);
@@ -556,7 +556,7 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, struct
drm_local_map *map)
case _DRM_SCATTER_GATHER:
break;
case _DRM_CONSISTENT:
- dma_free_coherent(&dev->pdev->dev,
+ dma_free_coherent(dev->dev,
map->size,
map->handle,
map->offset);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..555a04ce2179 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2075,9 +2076,13 @@ EXPORT_SYMBOL(drm_get_edid);
struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct pci_dev *pdev = connector->dev->pdev;
+ struct drm_device *dev = connector->dev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
struct edid *edid;
+ if (drm_WARN_ON_ONCE(dev, !dev_is_pci(dev->dev)))
+ return NULL;
+
vga_switcheroo_lock_ddc(pdev);
edid = drm_get_edid(connector, adapter);
vga_switcheroo_unlock_ddc(pdev);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e2e075..22986a9a593b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -122,7 +122,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
dev->driver->irq_preinstall(dev);
/* PCI devices require shared interrupts. */
- if (dev->pdev)
+ if (dev_is_pci(dev->dev))
sh_flags = IRQF_SHARED;
ret = request_irq(irq, dev->driver->irq_handler,
@@ -140,7 +140,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
[PATCH v2 17/20] drm/vboxvideo: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert vboxvideo to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 11 ++-
drivers/gpu/drm/vboxvideo/vbox_irq.c | 4 +++-
drivers/gpu/drm/vboxvideo/vbox_main.c | 8 ++--
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 7 ---
4 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index f3eac72cb46e..e534896b6cfd 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -51,7 +51,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (IS_ERR(vbox))
return PTR_ERR(vbox);
- vbox->ddev.pdev = pdev;
pci_set_drvdata(pdev, vbox);
mutex_init(&vbox->hw_mutex);
@@ -109,15 +108,16 @@ static void vbox_pci_remove(struct pci_dev *pdev)
static int vbox_pm_suspend(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
+ struct pci_dev *pdev = to_pci_dev(dev);
int error;
error = drm_mode_config_helper_suspend(&vbox->ddev);
if (error)
return error;
- pci_save_state(vbox->ddev.pdev);
- pci_disable_device(vbox->ddev.pdev);
- pci_set_power_state(vbox->ddev.pdev, PCI_D3hot);
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
return 0;
}
@@ -125,8 +125,9 @@ static int vbox_pm_suspend(struct device *dev)
static int vbox_pm_resume(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
+ struct pci_dev *pdev = to_pci_dev(dev);
- if (pci_enable_device(vbox->ddev.pdev))
+ if (pci_enable_device(pdev))
return -EIO;
return drm_mode_config_helper_resume(&vbox->ddev);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_irq.c
b/drivers/gpu/drm/vboxvideo/vbox_irq.c
index 631657fa554f..b3ded68603ba 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_irq.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_irq.c
@@ -170,10 +170,12 @@ static void vbox_hotplug_worker(struct work_struct *work)
int vbox_irq_init(struct vbox_private *vbox)
{
+ struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
+
INIT_WORK(&vbox->hotplug_work, vbox_hotplug_worker);
vbox_update_mode_hints(vbox);
- return drm_irq_install(&vbox->ddev, vbox->ddev.pdev->irq);
+ return drm_irq_install(&vbox->ddev, pdev->irq);
}
void vbox_irq_fini(struct vbox_private *vbox)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index d68d9bad7674..f28779715ccd 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -8,7 +8,9 @@
* Hans de Goede
*/
+#include
#include
+
#include
#include
#include
@@ -30,6 +32,7 @@ void vbox_report_caps(struct vbox_private *vbox)
static int vbox_accel_init(struct vbox_private *vbox)
{
+ struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
struct vbva_buffer *vbva;
unsigned int i;
@@ -41,7 +44,7 @@ static int vbox_accel_init(struct vbox_private *vbox)
/* Take a command buffer for each screen from the end of usable VRAM. */
vbox->available_vram_size -= vbox->num_crtcs * VBVA_MIN_BUFFER_SIZE;
- vbox->vbva_buffers = pci_iomap_range(vbox->ddev.pdev, 0,
+ vbox->vbva_buffers = pci_iomap_range(pdev, 0,
vbox->available_vram_size,
vbox->num_crtcs *
VBVA_MIN_BUFFER_SIZE);
@@ -106,6 +109,7 @@ bool vbox_check_supported(u16 id)
int vbox_hw_init(struct vbox_private *vbox)
{
+ struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
int ret = -ENOMEM;
vbox->full_vram_size = inl(VBE_DISPI_IOPORT_DATA);
@@ -115,7 +119,7 @@ int vbox_hw_init(struct vbox_private *vbox)
/* Map guest-heap at end of vram */
vbox->guest_heap =
- pci_iomap_range(vbox->ddev.pdev, 0, GUEST_HEAP_OFFSET(vbox),
+ pci_iomap_range(pdev, 0, GUEST_HEAP_OFFSET(vbox),
GUEST_HEAP_SIZE);
if (!vbox->guest_heap)
return -ENOMEM;
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index f5a06675da43..0066a3c1dfc9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
@@ -15,8 +15,9 @@ int vbox_mm_init(struct vbox_private *vbox)
struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = &vbox->ddev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
- vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(dev->pdev, 0),
+ vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(p
Re: [PATCH v2 01/20] drm/amdgpu: Fix trailing whitespaces
Reviewed-by: Christian König on patch #1 and #15. Acked-by: Christian König on patch #2 and #16. Regards, Christian. Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: Adhere to kernel coding style. Signed-off-by: Thomas Zimmermann Acked-by: Alex Deucher Acked-by: Sam Ravnborg Cc: Alex Deucher Cc: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5f304425c948..da23c0f21311 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4922,8 +4922,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev *pdev, pci_channel_sta case pci_channel_io_normal: return PCI_ERS_RESULT_CAN_RECOVER; /* Fatal error, prepare for slot reset */ - case pci_channel_io_frozen: - /* + case pci_channel_io_frozen: + /* * Cancel and wait for all TDRs in progress if failing to * set adev->in_gpu_reset in amdgpu_device_lock_adev * @@ -5014,7 +5014,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) goto out; } - adev->in_pci_err_recovery = true; + adev->in_pci_err_recovery = true; r = amdgpu_device_pre_asic_reset(adev, NULL, &need_full_reset); adev->in_pci_err_recovery = false; if (r) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Remove udlfb driver
On Tue, 1 Dec 2020, Thomas Zimmermann wrote: > Hi > > Am 30.11.20 um 15:31 schrieb Mikulas Patocka: > > > > > > On Mon, 30 Nov 2020, Thomas Zimmermann wrote: > > > > > Udlfb has been superseded by DRM's udl. The DRM driver is better by > > > any means and actively maintained. Remove udlfb. > > > > Hi > > > > I am using udlfb and it's definitely better than the DRM driver. The DRM > > driver will crash the kernel if you unplug the device while Xorg is > > running. The framebuffer driver doesn't crash in this case. (I have a cat > > and the cat sometimes unplugs cables and I don't want to reboot the system > > because of it :-) > > What's the exact STR here? Just open the /dev/fb* and pull the cable. > > Do I need a cat? :) When I run links -g on the DRM driver, it works at first, but after some unplug/plug I got this: [ 282.174963] general protection fault, probably for non-canonical address 0xdead00f8: [#1] PREEMPT SMP [ 282.177439] CPU: 9 PID: 3377 Comm: links Not tainted 5.10.0-rc6 #1 [ 282.178843] Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 [ 282.180325] RIP: 0010:fb_deferred_io_mkwrite+0x7c/0x100 [fb] [ 282.181865] Code: ff 83 e2 01 48 0f 44 c3 f0 48 0f ba 28 00 0f 82 83 00 00 00 49 8b 45 28 49 39 c4 48 8d 50 f8 74 5d 48 39 d3 74 1c 48 8b 4b 20 <48> 39 4a 20 77 4e 48 8b 42 08 4c 39 e0 48 8d 50 f8 74 41 48 39 d3 [ 282.185341] RSP: :888348293de8 EFLAGS: 00010216 [ 282.187166] RAX: dead0100 RBX: ea0004182980 RCX: [ 282.189071] RDX: dead00f8 RSI: 0801 RDI: a045c048 [ 282.191021] RBP: 888106af1c00 R08: 5fc6128b R09: 3626d41e [ 282.193006] R10: 0008 R11: 88a04fffc000 R12: a045c068 [ 282.195015] R13: a045c040 R14: a045c048 R15: fff03fff [ 282.197077] FS: 7fa64cbf4a00() GS:88a00fcc() knlGS: [ 282.199293] CS: 0010 DS: ES: CR0: 80050033 [ 282.201484] CR2: 7fa63f272008 CR3: 00105b2e CR4: 06e0 [ 282.203728] Call Trace: [ 282.205927] do_page_mkwrite+0x56/0xc0 [ 282.208125] ? __do_fault+0x2d/0xe0 [ 282.210257] handle_mm_fault+0xafc/0x15e0 [ 282.212350] exc_page_fault+0x1ac/0x4a0 [ 282.214408] ? asm_exc_page_fault+0x8/0x30 [ 282.216473] asm_exc_page_fault+0x1e/0x30 [ 282.218462] RIP: 0033:0x7fa64641f3a8 [ 282.220469] Code: c3 48 81 fa 00 08 00 00 77 a8 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f [ 282.224730] RSP: 002b:7ffe6da66ba8 EFLAGS: 00010206 [ 282.226881] RAX: 7fa63f272000 RBX: 7fa64cbf4990 RCX: 7fa63f272040 [ 282.229094] RDX: 003f4800 RSI: RDI: 7fa63f272000 [ 282.231339] RBP: R08: R09: [ 282.233614] R10: 0008 R11: 0246 R12: 0f00 [ 282.235927] R13: 003f4800 R14: 003f4800 R15: 0005 [ 282.238262] Modules linked in: mousedev hid_generic usbhid hid iptable_mangle ipt_REJECT nf_reject_ipv4 tun xt_MASQUERADE iptable_nat xt_tcpudp iscsi_target_mod target_core_pscsi target_core_file ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet target_core_mod cpufreq_powersave cpufreq_ondemand cpufreq_userspace configfs cpufreq_conservative autofs4 binfmt_misc bridge stp llc snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_pcm snd_timer snd soundcore dmi_sysfs nf_nat_ftp nf_conntrack_ftp nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 lm85 hwmon_vid udl drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font fbdev drm drm_panel_orientation_quirks backlight ipv6 ohci_pci amd64_edac_mod edac_mce_amd kvm_amd kvm irqbypass tg3 pcspkr ptp pps_core ehci_pci ohci_hcd ehci_hcd libphy usbcore k10temp hwmon e100 usb_common mii i2c_piix4 pata_serverworks rtc_cmos floppy acpi_cpufreq button processor spadfs evdev [ 282.257235] ---[ end trace d7968a41c1fbf717 ]--- [ 282.267115] RIP: 0010:fb_deferred_io_mkwrite+0x7c/0x100 [fb] [ 282.270350] Code: ff 83 e2 01 48 0f 44 c3 f0 48 0f ba 28 00 0f 82 83 00 00 00 49 8b 45 28 49 39 c4 48 8d 50 f8 74 5d 48 39 d3 74 1c 48 8b 4b 20 <48> 39 4a 20 77 4e 48 8b 42 08 4c 39 e0 48 8d 50 f8 74 41 48 39 d3 [ 282.276893] RSP: :888348293de8 EFLAGS: 00010216 [ 282.280202] RAX: dead0100 RBX: ea0004182980 RCX: [ 282.283564] RDX: dead00f8 RSI: 0801 RDI: a045c048 [ 282.286965] RBP: 888106af1c00 R08: 5fc6128b R09: 3626d41e [ 282.290628] R10: 0008 R11: 88a04fffc000 R12: a045c068 [ 282.294039] R13: a045c040 R14: a045c048 R15: fff03fff [ 282.297430] FS: 7fa64cbf4a00() GS:88900fd0() knlGS:
Re: GPU-side memory protection landscape
On 2020-11-30 3:07 p.m., Alexander Monakov wrote: My other concern is how easy it is to cause system instability or hangs by out-of-bounds writes from the GPU (via compute shaders or copy commands). In my experience of several years doing GPU computing with NVIDIA tech, I don't recall needing to lose time rebooting my PC after running a buggy CUDA "kernel". Heck, I could run the GCC C testsuite on the GPU without worrying about locking myself and others from the server. But now when I develop on a laptop with AMD's latest mobile SoC, every time I make a mistake in my GLSL code it more often than not forces a reboot. I hope you understand what a huge pain it is. What are the existing GPU hardware capabilities for memory protection (both in terms of preventing random accesses to system memory like with an IOMMU, and in terms of isolating different process contexts from each other), and to what extend Linux DRM drivers are taking advantage of them? Modern (or more like non-ancient at this point, basically anything which came out within the last decade) AMD GPUs have mostly perfect protection between different execution contexts (i.e. different processes normally, though it's not always a 1:1 mapping). Each context has its own virtual GPU address space and cannot access any memory which isn't mapped into that (which the kernel driver only does for memory belonging to a buffer object which the context has permission to access and has explicitly asked to be mapped into its address space). The instability you're seeing likely isn't due to lack of memory protection but due to any of a large number of other ways a GPU can end up in a hanging state, and the drivers and wider ecosystem not being very good at recovering from that yet. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb: Add interconnect path request
Am Dienstag, den 01.12.2020, 11:37 +0100 schrieb Martin Kepplinger:
> Add interconnect support to mxsfb so that it is able to request enough
> bandwidth to DDR for display output to work.
>
> Signed-off-by: Martin Kepplinger
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 33 +++
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 13
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 6faf17b6408d..b05e8e5f1e38 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
>
>
>
> #include
> #include
> @@ -311,6 +312,34 @@ static const struct of_device_id mxsfb_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, mxsfb_dt_ids);
>
> +
> +static int mxsfb_init_icc(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> + struct mxsfb_drm_private *mxsfb = drm->dev_private;
> + int ret;
> +
> + /* Optional interconnect request */
> + mxsfb->icc_path = devm_of_icc_get(&pdev->dev, "lcdif-dram");
> + if (IS_ERR(mxsfb->icc_path)) {
> + ret = PTR_ERR(mxsfb->icc_path);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + mxsfb->icc_path = NULL;
> + dev_dbg(drm->dev,
> + "No interconnect may cause display underflows!\n");
> + }
> +
> + ret = icc_set_bw(mxsfb->icc_path, 0, MBps_to_icc(700));
Shouldn't this be proportional to the current mode, instead of a fixed
value? 700MB looks like 1080p@60Hz@32bpp with a bit of headroom, but
there are many valid use-cases where significantly smaller displays are
connected to the eLCDIF. Also it doesn't cover the case where an
overlay is active, which needs additional bandwidth.
> + if (ret) {
> + dev_err(drm->dev, "%s: icc_set_bw failed: %d\n", __func__, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
[...]
> #include
> #include
> @@ -310,6 +311,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
> *crtc,
> struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
> struct drm_device *drm = mxsfb->drm;
> dma_addr_t paddr;
> + int ret;
> +
> + ret = icc_enable(mxsfb->icc_path);
> + if (ret)
> + dev_err_ratelimited(drm->dev, "%s: icc_enable failed: %d\n",
> + __func__, ret);
Why ratelimited? I wouldn't expect atomic enable/disable to be called
often enough for this to make any difference.
Regards,
Lucas
>
> pm_runtime_get_sync(drm->dev);
> mxsfb_enable_axi_clk(mxsfb);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Remove udlfb driver
On Tue, 1 Dec 2020, Thomas Zimmermann wrote: > Hi > > Am 30.11.20 um 19:39 schrieb Mikulas Patocka: > > > > > > On Mon, 30 Nov 2020, Daniel Vetter wrote: > > > > > On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote: > > > > > > > > The framebuffer driver supports programs running full-screen directly on > > > > the framebuffer console, such as web browser "links -g", image viewer > > > > "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", > > > > movie player "mplayer -vo fbdev". The DRM driver doesn't run them. > > > > > > Hm this should in general work on drm drivers. Without that it's clear the > > > switch-over isn't really ready yet. > > > > I fixed it with this patch two years ago: > > https://lists.freedesktop.org/archives/dri-devel/2018-June/179023.html > > > > But the patch never went through and the fb_defio feature was removed in > > the kernel 5.6 (commit d0c4fc5a4814e431c15272935c8dc973c18073aa). > > > > > > Without fb_defio, the only other possibility how to update the screen is > > the ioctl DRM_IOCTL_MODE_DIRTYFB. But this ioctl requires master mode, so > > user programs like "links -g" can't issue it. > > That's confusing. DIRTYFB is only for DRM. Yes, you're right. > And why can links not run as DRM master mode? If it renders to the terminal, > it should act like a composer. In that case it almost certainly wants master > status. > > Best regards > Thomas How can a userspace program acquire master mode without being suid? Is there some "Hello World!" program that shows how to use DRM? I'm not an expert in DRM, but if there were some tutorial+documentation, I could consider porting "links" to it. Mikulas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Remove udlfb driver
On Mon, 30 Nov 2020, Daniel Vetter wrote: > On Mon, Nov 30, 2020 at 01:39:17PM -0500, Mikulas Patocka wrote: > > > > > > On Mon, 30 Nov 2020, Daniel Vetter wrote: > > > > > On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote: > > > > > > > > The framebuffer driver supports programs running full-screen directly > > > > on > > > > the framebuffer console, such as web browser "links -g", image viewer > > > > "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", > > > > movie player "mplayer -vo fbdev". The DRM driver doesn't run them. > > > > > > Hm this should in general work on drm drivers. Without that it's clear the > > > switch-over isn't really ready yet. > > > > I fixed it with this patch two years ago: > > https://lists.freedesktop.org/archives/dri-devel/2018-June/179023.html > > > > But the patch never went through and the fb_defio feature was removed in > > the kernel 5.6 (commit d0c4fc5a4814e431c15272935c8dc973c18073aa). > > The generic fbdev emulation still has a defio implementation. We could try > to make it more efficient maybe, but it should be all there. The module > option disappeared since you now should always get it by default. Yes, it's there. I've tried to run links on the current DRM UDL driver and it displays correctly - except, that the page list gets sometimes corrupted and a crash happens. > > Without fb_defio, the only other possibility how to update the screen is > > the ioctl DRM_IOCTL_MODE_DIRTYFB. But this ioctl requires master mode, so > > user programs like "links -g" can't issue it. > > Now I'm confused, I thought you wanted to use fbdev /dev/fb* nodes? Those > should support defio. And if you want your applications to use drm > modesetting natively, they have to be drm master anyway. You can't use the > DIRTYFB ioctl to upload fbdev contents. So I'm a bit confused. > -Daniel Yes. I was confused about it too. You can't use DRM ioctls on /dev/fb. Mikulas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 11:34 schrieb Christian König:
[...]
In patch 6 of this series, there's ast cursor code that acquires two
BO's reservation locks and vmaps them afterwards. That's probably how
you intend to use dma_buf_vmap_local.
However, I think it's more logically to have a vmap callback that only
does the actual vmap. This is all that exporters would have to implement.
And with that, build one helper that pins before vmap and one helper
that gets the resv lock.
I don't think that this is will work nor is it a good approach.
See the ast cursor handling for example. You need to acquire two BOs
here, not just one. And this can't be done cleanly with a single vmap call.
That seems to be a misunderstanding.
I don't mentioned it explicitly, but there's of course another helper
that only vmaps and nothing else. This would be useful for cases like
the cursor code. So there would be:
dma_buf_vmap() - pin + vmap
dma_buf_vmap_local() - lock + vmap
dma_buf_vmap_locked() - only vmap; caller has set up the BOs
I did some conversion of drivers that use vram and shmem. They
occasionally update a buffer (ast cursors) or flush a BO from system
memory to HW (udl, cirrus, mgag200). In terms of these 3 interfaces: I
never needed dma_buf_vmap() because pinning was never really required
here. Almost all of the cases were handled by dma_buf_vmap_local(). And
the ast cursor code uses the equivalent of dma_buf_vmap_locked().
The driver exporting the buffer would only have to implement vmap() and
pin() interfaces. Each does only its one thing and would assume that
the caller holds the lock.
Best regards
Thomas
Regards,
Christian.
I know that it might require some work on exporting drivers. But with
your proposal, we probably need another dma-buf callback just for
vmap_local. (?) That seems even less appealing to me.
Best regards
Thomas
Trying to shovel both semantics into one interface, depending upon
which implementation we have backing the buffer, doesn't work indeed.
Also on the pin topic, I think neither interface should require
callers to explicitly pin anything. For existing users it should
happen automatically behind the scenes imo, that's what they're
expecting.
-Daniel
I think we could use what we've done for dynamic dma-buf attachment
(which also change locking rules) and just have new functions for the
new way (i.e. short term vmap protected by dma_resv lock. Maybe call
these dma_buf_vmap_local, in the spirit of the new kmap_local which
are currently under discussion. I think _local suffix is better, for
otherwise people might do something silly like
dma_resv_lock();
dma_buf_vmap_locked();
dma_resv_unlock();
/* actual access maybe even in some other thread */
dma_buf_resv_lock();
dma_buf_vunmap_unlocked();
dma_resv_unlock();
_local suffix is better at telling that the resulting pointer has very
limited use (essentially just local to the calling context, if you
don't change any locking or anything).
_local sounds good.
Best regards
Thomas
I think encouraging importers to call dma_buf_pin/unpin isn't a good
idea. Yes dynamic ones need it, but maybe we should check for that
somehow in the exporterd interface (atm only amdgpu is using it).
-Daniel
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very
sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct
dma_buf_map
*map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+ * Notes to implementors:
+ *
+ * - Implementations must expect pairs of @vmap and
@vunmap to be
+ * called frequently and should optimize for this case.
+ *
+ * - Implemenations may expect the caller to hold the GEM
object's
+ * reservation lock to protect against concurrent calls and
relocation
+ * of the GEM object.
+ *
+ * - Implementations may provide additional guarantees (e.g.,
working
+ * without holding the reservation lock).
+ *
* This callback is optional.
+ *
+ * See also drm_gem_dmabuf_vmap()
*/
int (*vmap)(struct drm_gem_object *obj, struct
dma_buf_map *map);
@@ -148,6 +162,8 @@ struct drm_gem_object_funcs {
* drm_gem_dmabuf_vunmap() helper.
*
* This callback is optional.
+ *
+ * See also @vmap.
*/
void (*vunmap)(struct drm_gem_object *obj, struct
dma_buf_map
*map);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Deve
[PATCH v1 0/1] drm/imx/dcss: Add interconnect support
This allows us to raise DRAM bandiwth to a high enough value for a stable picture on i.mx8mq. We pick a bandwidth that should be sufficient for 4k@60Hz. This was tested on a Librem 5 with the (not yet) mainline mhdp DP controller. Without that initial boot works fine but e.g. fb unblank results in a cyan screen. Modelled like mdp5_kms. Guido Günther (1): drm/imx/dcss: Add interconnect support drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++-- drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++ 2 files changed, 48 insertions(+), 2 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/imx/dcss: Add interconnect support
This allows us to raise DRAM bandiwth to a high enough value for a
stable picture on i.mx8mq. We pick a bandwidth that should be sufficient
for 4k@60Hz.
Modelled like mdp5_kms.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++--
drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index c849533ca83e..e336f03448d6 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -15,6 +15,9 @@
#include "dcss-dev.h"
#include "dcss-kms.h"
+/* sufficient for 4K at 60 Hz */
+#define DCSS_BW_MAX GBps_to_icc(2)
+
static void dcss_clocks_enable(struct dcss_dev *dcss)
{
clk_prepare_enable(dcss->axi_clk);
@@ -162,6 +165,31 @@ static void dcss_clks_release(struct dcss_dev *dcss)
devm_clk_put(dcss->dev, dcss->apb_clk);
}
+static int dcss_init_icc(struct dcss_dev *dcss)
+{
+ int ret;
+ struct icc_path *icc_path;
+
+ /* Optional interconnect request */
+ icc_path = of_icc_get(dcss->dev, NULL);
+ if (IS_ERR(icc_path)) {
+ ret = PTR_ERR(icc_path);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ /* no interconnect support is not necessarily a fatal
+* condition, the platform may simply not have an
+* interconnect driver yet. But warn about it in case
+* bootloader didn't setup bus clocks high enough for
+* scanout.
+*/
+ dev_warn(dcss->dev, "No interconnect support may cause display
underflows!\n");
+ return 0;
+ }
+ dcss->icc_path = icc_path;
+ dcss->icc_peak_bw = DCSS_BW_MAX;
+ return 0;
+}
+
struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -190,10 +218,14 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
dcss->devtype = devtype;
dcss->hdmi_output = hdmi_output;
+ ret = dcss_init_icc(dcss);
+ if (ret < 0)
+ goto err;
+
ret = dcss_clks_init(dcss);
if (ret) {
dev_err(dev, "clocks initialization failed\n");
- goto err;
+ goto icc_err;
}
dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
@@ -223,7 +255,8 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
clks_err:
dcss_clks_release(dcss);
-
+icc_err:
+ icc_put(dcss->icc_path);
err:
kfree(dcss);
@@ -243,6 +276,8 @@ void dcss_dev_destroy(struct dcss_dev *dcss)
dcss_clks_release(dcss);
+ icc_put(dcss->icc_path);
+
kfree(dcss);
}
@@ -267,6 +302,8 @@ int dcss_dev_suspend(struct device *dev)
dcss_clocks_disable(dcss);
+ icc_set_bw(dcss->icc_path, 0, 0);
+
return 0;
}
@@ -281,6 +318,8 @@ int dcss_dev_resume(struct device *dev)
return 0;
}
+ icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
+
dcss_clocks_enable(dcss);
dcss_blkctl_cfg(dcss->blkctl);
@@ -307,6 +346,8 @@ int dcss_dev_runtime_suspend(struct device *dev)
dcss_clocks_disable(dcss);
+ icc_set_bw(dcss->icc_path, 0, 0);
+
return 0;
}
@@ -314,6 +355,8 @@ int dcss_dev_runtime_resume(struct device *dev)
{
struct dcss_dev *dcss = dcss_drv_dev_to_dcss(dev);
+ icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
+
dcss_clocks_enable(dcss);
dcss_blkctl_cfg(dcss->blkctl);
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.h
b/drivers/gpu/drm/imx/dcss/dcss-dev.h
index c642ae17837f..1b35a6f0d0d4 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.h
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#define SET0x04
@@ -85,6 +86,8 @@ struct dcss_dev {
struct clk *pll_phy_ref_clk;
bool hdmi_output;
+ struct icc_path *icc_path;
+ u32 icc_peak_bw;
void (*disable_callback)(void *data);
struct completion disable_completion;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/imx/dcss: Add interconnect support
Am Dienstag, den 01.12.2020, 12:34 +0100 schrieb Guido Günther:
> This allows us to raise DRAM bandiwth to a high enough value for a
> stable picture on i.mx8mq. We pick a bandwidth that should be sufficient
> for 4k@60Hz.
>
> Modelled like mdp5_kms.
>
> Signed-off-by: Guido Günther
> ---
> drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++--
> drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
> b/drivers/gpu/drm/imx/dcss/dcss-dev.c
> index c849533ca83e..e336f03448d6 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
> @@ -15,6 +15,9 @@
> #include "dcss-dev.h"
> #include "dcss-kms.h"
>
> +/* sufficient for 4K at 60 Hz */
> +#define DCSS_BW_MAX GBps_to_icc(2)
> +
Same comment as for the similar change in mxsfb: this should not be a
static value, but should be scaled proportional to the current mode and
plane settings. With a single static value you keep the clocks way too
high for most use-cases with smaller displays, but fail to account for
the additional bandwidth requirement when more than one plane is
active.
Regards,
Lucas
> static void dcss_clocks_enable(struct dcss_dev *dcss)
> {
> clk_prepare_enable(dcss->axi_clk);
> @@ -162,6 +165,31 @@ static void dcss_clks_release(struct dcss_dev *dcss)
> devm_clk_put(dcss->dev, dcss->apb_clk);
> }
>
>
>
>
> +static int dcss_init_icc(struct dcss_dev *dcss)
> +{
> + int ret;
> + struct icc_path *icc_path;
> +
> + /* Optional interconnect request */
> + icc_path = of_icc_get(dcss->dev, NULL);
> + if (IS_ERR(icc_path)) {
> + ret = PTR_ERR(icc_path);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + /* no interconnect support is not necessarily a fatal
> + * condition, the platform may simply not have an
> + * interconnect driver yet. But warn about it in case
> + * bootloader didn't setup bus clocks high enough for
> + * scanout.
> + */
> + dev_warn(dcss->dev, "No interconnect support may cause display
> underflows!\n");
> + return 0;
> + }
> + dcss->icc_path = icc_path;
> + dcss->icc_peak_bw = DCSS_BW_MAX;
> + return 0;
> +}
> +
> struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
> {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -190,10 +218,14 @@ struct dcss_dev *dcss_dev_create(struct device *dev,
> bool hdmi_output)
> dcss->devtype = devtype;
> dcss->hdmi_output = hdmi_output;
>
>
>
>
> + ret = dcss_init_icc(dcss);
> + if (ret < 0)
> + goto err;
> +
> ret = dcss_clks_init(dcss);
> if (ret) {
> dev_err(dev, "clocks initialization failed\n");
> - goto err;
> + goto icc_err;
> }
>
>
>
>
> dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
> @@ -223,7 +255,8 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
> hdmi_output)
>
>
>
>
> clks_err:
> dcss_clks_release(dcss);
> -
> +icc_err:
> + icc_put(dcss->icc_path);
> err:
> kfree(dcss);
>
>
>
>
> @@ -243,6 +276,8 @@ void dcss_dev_destroy(struct dcss_dev *dcss)
>
>
>
>
> dcss_clks_release(dcss);
>
>
>
>
> + icc_put(dcss->icc_path);
> +
> kfree(dcss);
> }
>
>
>
>
> @@ -267,6 +302,8 @@ int dcss_dev_suspend(struct device *dev)
>
>
>
>
> dcss_clocks_disable(dcss);
>
>
>
>
> + icc_set_bw(dcss->icc_path, 0, 0);
> +
> return 0;
> }
>
>
>
>
> @@ -281,6 +318,8 @@ int dcss_dev_resume(struct device *dev)
> return 0;
> }
>
>
>
>
> + icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
> +
> dcss_clocks_enable(dcss);
>
>
>
>
> dcss_blkctl_cfg(dcss->blkctl);
> @@ -307,6 +346,8 @@ int dcss_dev_runtime_suspend(struct device *dev)
>
>
>
>
> dcss_clocks_disable(dcss);
>
>
>
>
> + icc_set_bw(dcss->icc_path, 0, 0);
> +
> return 0;
> }
>
>
>
>
> @@ -314,6 +355,8 @@ int dcss_dev_runtime_resume(struct device *dev)
> {
> struct dcss_dev *dcss = dcss_drv_dev_to_dcss(dev);
>
>
>
>
> + icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
> +
> dcss_clocks_enable(dcss);
>
>
>
>
> dcss_blkctl_cfg(dcss->blkctl);
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.h
> b/drivers/gpu/drm/imx/dcss/dcss-dev.h
> index c642ae17837f..1b35a6f0d0d4 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-dev.h
> +++ b/drivers/gpu/drm/imx/dcss/dcss-dev.h
> @@ -8,6 +8,7 @@
>
>
>
>
> #include
> #include
> +#include
> #include
>
>
>
>
> #define SET 0x04
> @@ -85,6 +86,8 @@ struct dcss_dev {
> struct clk *pll_phy_ref_clk;
>
>
>
>
> bool hdmi_output;
> + struct icc_path *icc_path;
> + u32
Re: [PATCH v5 1/6] dt-bindings: display: simple: Add EDT ETM0700G0BDH6 display
Hi Oleksij On Tue, Dec 01, 2020 at 10:27:37AM +0100, Oleksij Rempel wrote: > This display is already supported by the panel-simple driver, so add it > to the bindings documentation. > > This patch is needed to fix checkpatch warnings for the PLYM2M dts. > > Signed-off-by: Oleksij Rempel > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index edb53ab0d9eb..a011d9e44af3 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -117,6 +117,8 @@ properties: >- edt,etm0700g0dh6 > # Emerging Display Technology Corp. WVGA TFT Display with capacitive > touch > # Same as ETM0700G0DH6 but with inverted pixel clock. > + - edt,etm0700g0bdh6 > +# Emerging Display Technology Corp. WVGA TFT Display with capacitive > touch >- edt,etm070080bdh6 > # Emerging Display Technology Corp. WVGA TFT Display with capacitive > touch > # Same display as the ETM0700G0BDH6, but with changed hardware for > the The panels should be listed in alphabetic order which is not the case here. Could you fix the alphabetic order for the edt panels and then insert the new panel in the right spot? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
Hi Nanley, thanks for the review. +Ville, Chris. On Tue, Dec 01, 2020 at 02:18:26AM +0200, Chery, Nanley G wrote: > Hi Imre, > > I have a question and a couple comments: > > Is the map of the clear color address creating a new synchronization > point between the GPU and CPU? If so, I wonder how this will impact > performance. The kmap to read the clear value is not adding any sync overhead if that's what you mean. But the clear value must be in place before we read it out and that should be guaranteed by the flush we do anyway to wait for the render result (even considering the explicit L3/RT flush, depth stall the spec requires for fast clears). However now that you mention: atm the kmap/readout happens after the explicit but before the implicit fence-wait. I think it should happen after the implicit fence-wait. Ville, Chris, could you confirm the above and also that the above flush is enough to ensure the CPU read is coherent? > There was some talk of asynchronously updating the clear color > register a while back. Couldn't find anything with a quick search, do you have a pointer? Just before the flip we must wait for the render results anyway, as we do now, so not sure how it could be optimized. > We probably don't have to update the header, but we noticed in our > testing that the clear color prefers an alignment greater than 64B. > Unfortunately, I can't find any bspec note about this. As long as the > buffer creators are aware though, I think we should be fine. I don't > know if this is the best forum to bring it up, but I thought I'd > share. Yes, would be good to clarify this and get it also to the spec. Then the driver should also check the alignment of the 3rd FB plane. > Seems like the upper converted clear color is untested due to the lack > of RGBX16 support. I suppose that if there are any issues there, they > can be fixed later... Yes, a 64bpp RC-CC subtest in IGT is missing, should be easy to add that. --Imre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 11:00 schrieb Daniel Vetter:
[...]
For my POV, the current interfaces have no clear policy or semantics.
Looking through the different GEM implementations, each one seems to
have its own interpretation.
Yup, that's the problem really. In the past we've had vmap exclusively
for permanently pinned access, with no locking requirements. Now we're
trying to make this more dynamic, but in a somewhat ad-hoc fashion
(generic fbdev emulation charged ahead with making the fbdev
framebuffer evictable), and now it breaks at every seam. Adding more
ad-hoc semantics on top doesn't seem like a good idea.
That's why I think we should have 2 different interfaces:
- dma_buf_vmap, the one we currently have. Permanently pins the
buffer, mapping survives, no locking required.
I just looked at the implementation of dma_buf_vmap() and there's no
pinning happening AFAICT. Also, none of the callback's implementations
does pinning (except vram helpers). Do you mean dma_buf_attach() instead?
Best regards
Thomas
- dma_buf_vmap_local, the new interface, the one that generic fbdev
should have used (but oh well mistakes happen), requires
dma_resv_lock, the mapping is only local to the caller
Trying to shovel both semantics into one interface, depending upon
which implementation we have backing the buffer, doesn't work indeed.
Also on the pin topic, I think neither interface should require
callers to explicitly pin anything. For existing users it should
happen automatically behind the scenes imo, that's what they're
expecting.
-Daniel
I think we could use what we've done for dynamic dma-buf attachment
(which also change locking rules) and just have new functions for the
new way (i.e. short term vmap protected by dma_resv lock. Maybe call
these dma_buf_vmap_local, in the spirit of the new kmap_local which
are currently under discussion. I think _local suffix is better, for
otherwise people might do something silly like
dma_resv_lock();
dma_buf_vmap_locked();
dma_resv_unlock();
/* actual access maybe even in some other thread */
dma_buf_resv_lock();
dma_buf_vunmap_unlocked();
dma_resv_unlock();
_local suffix is better at telling that the resulting pointer has very
limited use (essentially just local to the calling context, if you
don't change any locking or anything).
_local sounds good.
Best regards
Thomas
I think encouraging importers to call dma_buf_pin/unpin isn't a good
idea. Yes dynamic ones need it, but maybe we should check for that
somehow in the exporterd interface (atm only amdgpu is using it).
-Daniel
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map
*map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+ * Notes to implementors:
+ *
+ * - Implementations must expect pairs of @vmap and @vunmap to be
+ * called frequently and should optimize for this case.
+ *
+ * - Implemenations may expect the caller to hold the GEM object's
+ * reservation lock to protect against concurrent calls and
relocation
+ * of the GEM object.
+ *
+ * - Implementations may provide additional guarantees (e.g.,
working
+ * without holding the reservation lock).
+ *
* This callback is optional.
+ *
+ * See also drm_gem_dmabuf_vmap()
*/
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
@@ -148,6 +162,8 @@ struct drm_gem_object_funcs {
* drm_gem_dmabuf_vunmap() helper.
*
* This callback is optional.
+ *
+ * See also @vmap.
*/
void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map
*map);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Am 01.12.20 um 12:30 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:34 schrieb Christian König:
[...]
In patch 6 of this series, there's ast cursor code that acquires two
BO's reservation locks and vmaps them afterwards. That's probably
how you intend to use dma_buf_vmap_local.
However, I think it's more logically to have a vmap callback that
only does the actual vmap. This is all that exporters would have to
implement.
And with that, build one helper that pins before vmap and one helper
that gets the resv lock.
I don't think that this is will work nor is it a good approach.
See the ast cursor handling for example. You need to acquire two BOs
here, not just one. And this can't be done cleanly with a single vmap
call.
That seems to be a misunderstanding.
I don't mentioned it explicitly, but there's of course another helper
that only vmaps and nothing else. This would be useful for cases like
the cursor code. So there would be:
dma_buf_vmap() - pin + vmap
dma_buf_vmap_local() - lock + vmap
dma_buf_vmap_locked() - only vmap; caller has set up the BOs
Well that zoo of helpers will certainly get a NAK from my side.
See interfaces like this should implement simple functions and not hide
what's actually needs to be done inside the drivers using this interface.
What we could do is to add a pin count to the DMA-buf and then do
WARN_ON(dma_buf->pin_count || dma_resv_lock_help(dma_buf->resv)) in the
vmap/vunmap calls.
I did some conversion of drivers that use vram and shmem. They
occasionally update a buffer (ast cursors) or flush a BO from system
memory to HW (udl, cirrus, mgag200). In terms of these 3 interfaces: I
never needed dma_buf_vmap() because pinning was never really required
here. Almost all of the cases were handled by dma_buf_vmap_local().
And the ast cursor code uses the equivalent of dma_buf_vmap_locked().
Yeah, that is kind of expected. I was already wondering as well why we
didn't used the reservation lock more extensively.
Regards,
Christian.
The driver exporting the buffer would only have to implement vmap()
and pin() interfaces. Each does only its one thing and would assume
that the caller holds the lock.
Best regards
Thomas
Regards,
Christian.
I know that it might require some work on exporting drivers. But
with your proposal, we probably need another dma-buf callback just
for vmap_local. (?) That seems even less appealing to me.
Best regards
Thomas
Trying to shovel both semantics into one interface, depending upon
which implementation we have backing the buffer, doesn't work indeed.
Also on the pin topic, I think neither interface should require
callers to explicitly pin anything. For existing users it should
happen automatically behind the scenes imo, that's what they're
expecting.
-Daniel
I think we could use what we've done for dynamic dma-buf attachment
(which also change locking rules) and just have new functions for
the
new way (i.e. short term vmap protected by dma_resv lock. Maybe call
these dma_buf_vmap_local, in the spirit of the new kmap_local which
are currently under discussion. I think _local suffix is better, for
otherwise people might do something silly like
dma_resv_lock();
dma_buf_vmap_locked();
dma_resv_unlock();
/* actual access maybe even in some other thread */
dma_buf_resv_lock();
dma_buf_vunmap_unlocked();
dma_resv_unlock();
_local suffix is better at telling that the resulting pointer has
very
limited use (essentially just local to the calling context, if you
don't change any locking or anything).
_local sounds good.
Best regards
Thomas
I think encouraging importers to call dma_buf_pin/unpin isn't a good
idea. Yes dynamic ones need it, but maybe we should check for that
somehow in the exporterd interface (atm only amdgpu is using it).
-Daniel
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very
sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct
dma_buf_map
*map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+ * Notes to implementors:
+ *
+ * - Implementations must expect pairs of @vmap and
@vunmap to be
+ * called frequently and should optimize for this case.
+ *
+ * - Implemenations may expect the caller to hold the
GEM object's
+ * reservation lock to protect against concurrent
calls and
relocation
+ * of the GEM object.
+ *
+ * - Implementations may provide additional guarantees
(e.g.,
working
+ * without holding the reservation lock).
+ *
* This callback is optional.
+ *
+ * See also drm_gem
Re: [PATCH drm/hisilicon v2 1/4] drm/hisilicon: Assgin local variable to drm_device
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to struct drm_device *dev because they are
used multiple times within a function.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 30
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 ---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = &priv->dev;
struct drm_crtc *crtc = &priv->crtc;
struct drm_plane *plane = &priv->primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..dd9fadc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
static int hibmc_kms_init(struct hibmc_drm_private *priv)
{
+ struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(priv->dev);
+ drm_mode_config_init(dev);
priv->mode_config_initialized = true;
- priv->dev->mode_config.min_width = 0;
- priv->dev->mode_config.min_height = 0;
- priv->dev->mode_config.max_width = 1920;
- priv->dev->mode_config.max_height = 1200;
+ dev->mode_config.min_width = 0;
+ dev->mode_config.min_height = 0;
+ dev->mode_config.max_width = 1920;
+ dev->mode_config.max_height = 1200;
- priv->dev->mode_config.fb_base = priv->fb_base;
- priv->dev->mode_config.preferred_depth = 32;
- priv->dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = priv->fb_base;
+ dev->mode_config.preferred_depth = 32;
+ dev->mode_config.prefer_shadow = 1;
- priv->dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
+ dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
ret = hibmc_de_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init de: %d\n", ret);
+ drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
ret = hibmc_vdac_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+ drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
static void hibmc_kms_fini(struct hibmc_drm_private *priv)
{
if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(priv->dev);
+ drm_mode_config_cleanup(&priv->dev);
priv->mode_config_initialized = false;
}
}
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = &priv->dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
@@ -258,7 +259,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
- struct hibmc_drm_private *priv;
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -267,7 +268,6 @@ static int hibmc_load(struct drm_device *dev)
return -ENOMEM;
}
dev->dev_private = priv;
- priv->dev = dev;
I'm sure this either does not build or does not work. There's a call to
drm_dev_alloc(), which initialized the DRM device. You need to assign
the returned device here. The embedding of dev only work after you
switched to devm_drm_dev_alloc() in the next patch.
For the patch at hand, just keep struct hibmc_drm_private.dev as a
pointer and you should be fine.
Best regards
Thomas
ret = hibmc_hw_init(priv);
if (ret)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index f310a83..e35353a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -37,7 +37,7 @@ struct hibmc_drm_private {
resource_size_t fb_size;
/* drm */
- struct drm_device *dev;
+ struct drm_device dev;
struct drm_
Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn
On Mon, Nov 30, 2020 at 6:28 AM Daniel Vetter wrote: > > So I guess kvm platforms that don't set KVM_ARCH_WANT_MMU_NOTIFIER exist, > and at least on powerpc they're consistent with KVM_CAP_SYNC_MMU > signalling that the guest pagetables stays in sync automatically with any > updates. So for that case I guess we could use unsafe_follow_pfn. > > But on s390 this seems different: No mmu notifier, but KVM_CAP_SYNC_MMU is > set. So I guess there's some hardware magic on s390 that I don't know > about. + Vasily + Heiko +s390 > > Not sure what to do with this now here ... > -Daniel > > > On Sat, Nov 28, 2020 at 03:10:40AM +0800, kernel test robot wrote: > > Hi Daniel, > > > > I love your patch! Yet something to improve: > > > > [auto build test ERROR on linuxtv-media/master] > > [also build test ERROR on char-misc/char-misc-testing v5.10-rc5] > > [cannot apply to hnaz-linux-mm/master next-20201127] > > [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/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 > > base: git://linuxtv.org/media_tree.git master > > config: s390-randconfig-r032-20201127 (attached as .config) > > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project > > f095ac11a9550530a4a54298debb8b04b36422be) > > 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 s390 cross compiling tool for clang build > > # apt-get install binutils-s390x-linux-gnu > > # > > https://github.com/0day-ci/linux/commit/d76a3489433ce67d45da86aa12953385427f0ac9 > > git remote add linux-review https://github.com/0day-ci/linux > > git fetch --no-tags linux-review > > Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 > > git checkout d76a3489433ce67d45da86aa12953385427f0ac9 > > # save the attached .config to linux build tree > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot > > > > All errors (new ones prefixed by >>): > > > >In file included from arch/s390/include/asm/kvm_para.h:25: > >In file included from arch/s390/include/asm/diag.h:12: > >In file included from include/linux/if_ether.h:19: > >In file included from include/linux/skbuff.h:31: > >In file included from include/linux/dma-mapping.h:10: > >In file included from include/linux/scatterlist.h:9: > >In file included from arch/s390/include/asm/io.h:80: > >include/asm-generic/io.h:490:61: warning: performing pointer arithmetic > > on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] > >val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + > > addr)); > >~~ ^ > >include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from > > macro '__le32_to_cpu' > >#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) > > ^ > >include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' > >___constant_swab32(x) : \ > > ^ > >include/uapi/linux/swab.h:21:12: note: expanded from macro > > '___constant_swab32' > >(((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ > > ^ > >In file included from arch/s390/kvm/../../../virt/kvm/kvm_main.c:18: > >In file included from include/linux/kvm_host.h:32: > >In file included from include/linux/kvm_para.h:5: > >In file included from include/uapi/linux/kvm_para.h:36: > >In file included from arch/s390/include/asm/kvm_para.h:25: > >In file included from arch/s390/include/asm/diag.h:12: > >In file included from include/linux/if_ether.h:19: > >In file included from include/linux/skbuff.h:31: > >In file included from include/linux/dma-mapping.h:10: > >In file included from include/linux/scatterlist.h:9: > >In file included from arch/s390/include/asm/io.h:80: > >include/asm-generic/io.h:490:61: warning: performing pointer arithmetic > > on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] > >val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + > > addr)); > >~~ ^ > >include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from > > macro '__le32_to_cpu' > >#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) > >
Re: [PATCH 1/8] drm/gem: Write down some rules for vmap usage
Hi
Am 01.12.20 um 13:14 schrieb Christian König:
Am 01.12.20 um 12:30 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:34 schrieb Christian König:
[...]
In patch 6 of this series, there's ast cursor code that acquires two
BO's reservation locks and vmaps them afterwards. That's probably
how you intend to use dma_buf_vmap_local.
However, I think it's more logically to have a vmap callback that
only does the actual vmap. This is all that exporters would have to
implement.
And with that, build one helper that pins before vmap and one helper
that gets the resv lock.
I don't think that this is will work nor is it a good approach.
See the ast cursor handling for example. You need to acquire two BOs
here, not just one. And this can't be done cleanly with a single vmap
call.
That seems to be a misunderstanding.
I don't mentioned it explicitly, but there's of course another helper
that only vmaps and nothing else. This would be useful for cases like
the cursor code. So there would be:
dma_buf_vmap() - pin + vmap
dma_buf_vmap_local() - lock + vmap
dma_buf_vmap_locked() - only vmap; caller has set up the BOs
Well that zoo of helpers will certainly get a NAK from my side.
See interfaces like this should implement simple functions and not hide
what's actually needs to be done inside the drivers using this interface.
If 9 of 10 invocations use the same pattern, why not put that pattern in
a helper? I see nothing wrong with that.
What we could do is to add a pin count to the DMA-buf and then do
WARN_ON(dma_buf->pin_count || dma_resv_lock_help(dma_buf->resv)) in the
vmap/vunmap calls.
Most of the vmap code is either CMA or SHMEM GEM stuff. They don't need
to pin. It's just baggage to them. The TTM stuff that does need pinning
is the minority.
I did some conversion of drivers that use vram and shmem. They
occasionally update a buffer (ast cursors) or flush a BO from system
memory to HW (udl, cirrus, mgag200). In terms of these 3 interfaces: I
never needed dma_buf_vmap() because pinning was never really required
here. Almost all of the cases were handled by dma_buf_vmap_local().
And the ast cursor code uses the equivalent of dma_buf_vmap_locked().
Yeah, that is kind of expected. I was already wondering as well why we
didn't used the reservation lock more extensively.
As a side note, I found only 6 trivial implementations of vmap outside
of drivers/gpu/drm. I cannot find a single implementation of pin there.
What am I missing?
Best regards
Thomas
Regards,
Christian.
The driver exporting the buffer would only have to implement vmap()
and pin() interfaces. Each does only its one thing and would assume
that the caller holds the lock.
Best regards
Thomas
Regards,
Christian.
I know that it might require some work on exporting drivers. But
with your proposal, we probably need another dma-buf callback just
for vmap_local. (?) That seems even less appealing to me.
Best regards
Thomas
Trying to shovel both semantics into one interface, depending upon
which implementation we have backing the buffer, doesn't work indeed.
Also on the pin topic, I think neither interface should require
callers to explicitly pin anything. For existing users it should
happen automatically behind the scenes imo, that's what they're
expecting.
-Daniel
I think we could use what we've done for dynamic dma-buf attachment
(which also change locking rules) and just have new functions for
the
new way (i.e. short term vmap protected by dma_resv lock. Maybe call
these dma_buf_vmap_local, in the spirit of the new kmap_local which
are currently under discussion. I think _local suffix is better, for
otherwise people might do something silly like
dma_resv_lock();
dma_buf_vmap_locked();
dma_resv_unlock();
/* actual access maybe even in some other thread */
dma_buf_resv_lock();
dma_buf_vunmap_unlocked();
dma_resv_unlock();
_local suffix is better at telling that the resulting pointer has
very
limited use (essentially just local to the calling context, if you
don't change any locking or anything).
_local sounds good.
Best regards
Thomas
I think encouraging importers to call dma_buf_pin/unpin isn't a good
idea. Yes dynamic ones need it, but maybe we should check for that
somehow in the exporterd interface (atm only amdgpu is using it).
-Daniel
Best regards
Thomas
Cheers,
Christian.
That's what I meant with that this approach here is very
sprawling :-/
-Daniel
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct
dma_buf_map
*map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+ * Notes to implementors:
+ *
+ * - I
Re: [PATCH drm/hisilicon v2 1/4] drm/hisilicon: Assgin local variable to drm_device
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to struct drm_device *dev because they are
used multiple times within a function.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 30
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 ---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = &priv->dev;
struct drm_crtc *crtc = &priv->crtc;
struct drm_plane *plane = &priv->primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..dd9fadc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
static int hibmc_kms_init(struct hibmc_drm_private *priv)
{
+ struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(priv->dev);
+ drm_mode_config_init(dev);
priv->mode_config_initialized = true;
- priv->dev->mode_config.min_width = 0;
- priv->dev->mode_config.min_height = 0;
- priv->dev->mode_config.max_width = 1920;
- priv->dev->mode_config.max_height = 1200;
+ dev->mode_config.min_width = 0;
+ dev->mode_config.min_height = 0;
+ dev->mode_config.max_width = 1920;
+ dev->mode_config.max_height = 1200;
- priv->dev->mode_config.fb_base = priv->fb_base;
- priv->dev->mode_config.preferred_depth = 32;
- priv->dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = priv->fb_base;
+ dev->mode_config.preferred_depth = 32;
+ dev->mode_config.prefer_shadow = 1;
- priv->dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
+ dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
ret = hibmc_de_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init de: %d\n", ret);
+ drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
ret = hibmc_vdac_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+ drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
static void hibmc_kms_fini(struct hibmc_drm_private *priv)
{
if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(priv->dev);
+ drm_mode_config_cleanup(&priv->dev);
priv->mode_config_initialized = false;
}
}
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct
hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = &priv->dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
@@ -258,7 +259,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
- struct hibmc_drm_private *priv;
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -267,7 +268,6 @@ static int hibmc_load(struct drm_device *dev)
return -ENOMEM;
}
dev->dev_private = priv;
- priv->dev = dev;
I'm sure this either does not build or does not work. There's a call
to drm_dev_alloc(), which initialized the DRM device. You need to
assign the returned device here. The embedding of dev only work after
you switched to devm_drm_dev_alloc() in the next patch.
For the patch at hand, just keep struct hibmc_drm_private.dev as a
pointer and you should be fine.
Changing drm_device *dev to drm_device dev and using devm_drm_dev_alloc
does not easily split into two patches.
The patch does not compile well on its own, but it will compile fine
with patch #2.
Can patch #1 and patch #2 be combined into a single patch,just like V1.
Most of the code in this patch does
struct drm_device *dev = &priv->dev;
to get dev as a local variable. Why don't you do
struct drm_device *dev = priv->dev;
?
That's all that's really needed.
Best regards
Thomas
Best regards
Thomas
ret = hibmc_hw_init(priv);
if (ret)
diff --git a/drivers/gpu/dr
