Re: [PATCH v4 8/9] xen/gntdev: Implement dma-buf export functionality
+
+static const struct dma_buf_ops dmabuf_exp_ops = {
+ .attach = dmabuf_exp_ops_attach,
+ .detach = dmabuf_exp_ops_detach,
+ .map_dma_buf = dmabuf_exp_ops_map_dma_buf,
+ .unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
+ .release = dmabuf_exp_ops_release,
+ .map = dmabuf_exp_ops_kmap,
+ .map_atomic = dmabuf_exp_ops_kmap_atomic,
+ .unmap = dmabuf_exp_ops_kunmap,
+ .unmap_atomic = dmabuf_exp_ops_kunmap_atomic,
+ .mmap = dmabuf_exp_ops_mmap,
+};
+
Due to upcoming API change [1] the atomic ops need to be removed before
merging into the mainline
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/include/linux/dma-buf.h?id=f664a52695429b68afb4e130a0f69cd5fd1fec86
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/9] xen: dma-buf support for grant device
Hello, Boris, Juergen! Do you think I can re-base the series (which already has all required R-b's from Xen community) onto the latest kernel with API changes to patches 5 (of_dma_configure) and 8 (dma-buf atomic ops) and we can merge it to the Xen's kernel tree? It seems like no other reviews or objections are there so this seems reasonable to me now. Thank you, Oleksandr On 06/15/2018 09:27 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. RFC for this series was published and discussed [9], comments addressed. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and increasing/decreasing memory reservation of the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any system memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first six patches are in preparation for Xen dma-buf support, but I consider those usable regardless of the dma-buf use-case, e.g. other frontend/backend kernel modules may also benefit from these for better code reuse: 0001-xen-grant-table-Export-gnttab_-alloc-free-_pages-as-.patch 0002-xen-grant-table-Make-set-clear-page-private-code-sha.patch 0003-xen-balloon-Share-common-memory-reservation-routines.patch 0004-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch 0005-xen-gntdev-Allow-mappings-for-DMA-buffers.patch 0006-xen-gntdev-Make-private-routines-structures-accessib.patch The next three patches are Xen implementation of dma-buf as part of the grant device: 0007-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch 0008-xen-gntdev-Implement-dma-buf-export-functionality.patch 0009-xen-gntdev-Implement-dma-buf-import-functionality.patch The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. Basic balloon tests on x86. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 [9] https://lkml.org/lkml/2018/5/17/215 Changes since v3: * - added r-b tags - minor fixes - removed gntdev_remove_map as it can be coded directly now - moved IOCTL co
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
Dne nedelja, 01. julij 2018 ob 15:52:55 CEST je Chen-Yu Tsai napisal(a):
> On Sun, Jul 1, 2018 at 6:41 PM, Jernej Škrabec
wrote:
> > Dne četrtek, 28. junij 2018 ob 08:51:07 CEST je Chen-Yu Tsai napisal(a):
> >> On Thu, Jun 28, 2018 at 1:15 PM, Jernej Škrabec
> >
> > wrote:
> >> > Dne četrtek, 28. junij 2018 ob 04:50:09 CEST je Chen-Yu Tsai
napisal(a):
> >> >> On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec
> >> >>
> >> >
> >> > wrote:
> >> >> > Add all entries needed for HDMI to function properly.
> >> >> >
> >> >> > Since R40 has highly configurable pipeline, both mixers and both
> >> >> > TCON
> >> >> > TVs are added. Board specific DT should then connect them together
> >> >> > trough TCON TOP muxers to best fit the purpose of the board.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec
> >> >> > ---
> >> >> >
> >> >> > arch/arm/boot/dts/sun8i-r40.dtsi | 269
> >> >> > +++
> >> >> > 1 file changed, 269 insertions(+)
> >> >> >
> >> >> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> > b/arch/arm/boot/dts/sun8i-r40.dtsi index 173dcc1652d2..a2a75fb04caf
> >> >> > 100644
> >> >> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> > @@ -42,8 +42,11 @@
> >> >> >
> >> >> > */
> >> >> >
> >> >> > #include
> >> >> >
> >> >> > +#include
> >> >> >
> >> >> > #include
> >> >> >
> >> >> > +#include
> >> >
> >> > Maxime, above line breaks compilation for build robot, sorry.
> >> >
> >> >> > #include
> >> >> >
> >> >> > +#include
> >> >> >
> >> >> > / {
> >> >> >
> >> >> > #address-cells = <1>;
> >> >> >
> >> >> > @@ -99,12 +102,76 @@
> >> >> >
> >> >> > };
> >> >> >
> >> >> > };
> >> >> >
> >> >> > + de: display-engine {
> >> >> > + compatible = "allwinner,sun8i-r40-display-engine",
> >> >> > +"allwinner,sun8i-h3-display-engine";
> >> >>
> >> >> Given that the display pipeline looks different, they should not be
> >> >> compatible.
> >> >
> >> > Ok.
> >> >
> >> >> > + allwinner,pipelines = <&mixer0>, <&mixer1>;
> >> >> > + status = "disabled";
> >> >> > + };
> >> >> > +
> >> >> >
> >> >> > soc {
> >> >> >
> >> >> > compatible = "simple-bus";
> >> >> > #address-cells = <1>;
> >> >> > #size-cells = <1>;
> >> >> > ranges;
> >> >> >
> >> >> > + display_clocks: clock@100 {
> >> >> > + compatible = "allwinner,sun8i-r40-de2-clk",
> >> >> > +"allwinner,sun8i-h3-de2-clk";
> >> >> > + reg = <0x0100 0x10>;
> >> >> > + clocks = <&ccu CLK_DE>,
> >> >> > +<&ccu CLK_BUS_DE>;
> >> >> > + clock-names = "mod",
> >> >> > + "bus";
> >> >> > + resets = <&ccu RST_BUS_DE>;
> >> >> > + #clock-cells = <1>;
> >> >> > + #reset-cells = <1>;
> >> >> > + };
> >> >> > +
> >> >> > + mixer0: mixer@110 {
> >> >> > + compatible =
> >> >> > "allwinner,sun8i-r40-de2-mixer-0";
> >> >> > + reg = <0x0110 0x10>;
> >> >> > + clocks = <&display_clocks CLK_BUS_MIXER0>,
> >> >> > +<&display_clocks CLK_MIXER0>;
> >> >> > + clock-names = "bus",
> >> >> > + "mod";
> >> >> > + resets = <&display_clocks RST_MIXER0>;
> >> >> > +
> >> >> > + ports {
> >> >> > + #address-cells = <1>;
> >> >> > + #size-cells = <0>;
> >> >> > +
> >> >> > + mixer0_out: port@1 {
> >> >> > + reg = <1>;
> >> >> > + mixer0_out_tcon_top:
> >> >> > endpoint {
> >> >> > + remote-endpoint =
> >> >> > <&tcon_top_mixer0_in_mixer0>; +
> >> >> > };
> >> >> > + };
> >> >> > + };
> >> >> > + };
> >> >> > +
> >> >> > + mixer1: mixer@120 {
> >> >> > + compatible =
> >> >> > "allwinner,sun8i-r40-de2-mixer-1";
> >> >> > + reg = <0x0120 0x10>;
> >> >> > + clocks = <&display_clocks CLK_BUS_MIXER1>,
> >> >> > +<&display_clocks CLK_MIXER1>;
> >> >> > + clock-names = "bus",
> >> >> > + "mod";
> >> >> > + resets = <&display_clocks RST_WB>;
> >> >> > +
> >> >> > + ports {
> >> >> >
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
Dne nedelja, 01. julij 2018 ob 17:35:28 CEST je Chen-Yu Tsai napisal(a):
> On Sun, Jul 1, 2018 at 11:13 PM, Jernej Škrabec
wrote:
> > Dne nedelja, 01. julij 2018 ob 15:52:55 CEST je Chen-Yu Tsai napisal(a):
> >> On Sun, Jul 1, 2018 at 6:41 PM, Jernej Škrabec
> >
> > wrote:
> >> > Dne četrtek, 28. junij 2018 ob 08:51:07 CEST je Chen-Yu Tsai
napisal(a):
> >> >> On Thu, Jun 28, 2018 at 1:15 PM, Jernej Škrabec
> >> >>
> >> >
> >> > wrote:
> >> >> > Dne četrtek, 28. junij 2018 ob 04:50:09 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> >> >> On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec
> >> >> >>
> >> >> >
> >> >> > wrote:
> >> >> >> > Add all entries needed for HDMI to function properly.
> >> >> >> >
> >> >> >> > Since R40 has highly configurable pipeline, both mixers and both
> >> >> >> > TCON
> >> >> >> > TVs are added. Board specific DT should then connect them
> >> >> >> > together
> >> >> >> > trough TCON TOP muxers to best fit the purpose of the board.
> >> >> >> >
> >> >> >> > Signed-off-by: Jernej Skrabec
> >> >> >> > ---
> >> >> >> >
> >> >> >> > arch/arm/boot/dts/sun8i-r40.dtsi | 269
> >> >> >> > +++
> >> >> >> > 1 file changed, 269 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> >> > b/arch/arm/boot/dts/sun8i-r40.dtsi index
> >> >> >> > 173dcc1652d2..a2a75fb04caf
> >> >> >> > 100644
> >> >> >> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> >> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> >> >> >> > @@ -42,8 +42,11 @@
> >> >> >> >
> >> >> >> > */
> >> >> >> >
> >> >> >> > #include
> >> >> >> >
> >> >> >> > +#include
> >> >> >> >
> >> >> >> > #include
> >> >> >> >
> >> >> >> > +#include
> >> >> >
> >> >> > Maxime, above line breaks compilation for build robot, sorry.
> >> >> >
> >> >> >> > #include
> >> >> >> >
> >> >> >> > +#include
> >> >> >> >
> >> >> >> > / {
> >> >> >> >
> >> >> >> > #address-cells = <1>;
> >> >> >> >
> >> >> >> > @@ -99,12 +102,76 @@
> >> >> >> >
> >> >> >> > };
> >> >> >> >
> >> >> >> > };
> >> >> >> >
> >> >> >> > + de: display-engine {
> >> >> >> > + compatible =
> >> >> >> > "allwinner,sun8i-r40-display-engine",
> >> >> >> > +"allwinner,sun8i-h3-display-engine";
> >> >> >>
> >> >> >> Given that the display pipeline looks different, they should not be
> >> >> >> compatible.
> >> >> >
> >> >> > Ok.
> >> >> >
> >> >> >> > + allwinner,pipelines = <&mixer0>, <&mixer1>;
> >> >> >> > + status = "disabled";
> >> >> >> > + };
> >> >> >> > +
> >> >> >> >
> >> >> >> > soc {
> >> >> >> >
> >> >> >> > compatible = "simple-bus";
> >> >> >> > #address-cells = <1>;
> >> >> >> > #size-cells = <1>;
> >> >> >> > ranges;
> >> >> >> >
> >> >> >> > + display_clocks: clock@100 {
> >> >> >> > + compatible =
> >> >> >> > "allwinner,sun8i-r40-de2-clk",
> >> >> >> > +
> >> >> >> > "allwinner,sun8i-h3-de2-clk";
> >> >> >> > + reg = <0x0100 0x10>;
> >> >> >> > + clocks = <&ccu CLK_DE>,
> >> >> >> > +<&ccu CLK_BUS_DE>;
> >> >> >> > + clock-names = "mod",
> >> >> >> > + "bus";
> >> >> >> > + resets = <&ccu RST_BUS_DE>;
> >> >> >> > + #clock-cells = <1>;
> >> >> >> > + #reset-cells = <1>;
> >> >> >> > + };
> >> >> >> > +
> >> >> >> > + mixer0: mixer@110 {
> >> >> >> > + compatible =
> >> >> >> > "allwinner,sun8i-r40-de2-mixer-0";
> >> >> >> > + reg = <0x0110 0x10>;
> >> >> >> > + clocks = <&display_clocks
> >> >> >> > CLK_BUS_MIXER0>,
> >> >> >> > +<&display_clocks CLK_MIXER0>;
> >> >> >> > + clock-names = "bus",
> >> >> >> > + "mod";
> >> >> >> > + resets = <&display_clocks RST_MIXER0>;
> >> >> >> > +
> >> >> >> > + ports {
> >> >> >> > + #address-cells = <1>;
> >> >> >> > + #size-cells = <0>;
> >> >> >> > +
> >> >> >> > + mixer0_out: port@1 {
> >> >> >> > + reg = <1>;
> >> >> >> > + mixer0_out_tcon_top:
> >> >> >> > endpoint {
> >> >> >> > + remote-endpoint =
> >> >> >> > <&tcon_top_mixer0_in_mixer0>; +
> >> >> >> > };
> >> >> >> > + };
> >> >> >> > + };
> >> >> >> > + };
> >> >> >> > +
> >> >> >>
Re: [linux-sunxi] Re: [PATCH v3 10/24] drm/sun4i: tcon: Generalize engine search algorithm
Dne petek, 29. junij 2018 ob 21:06:09 CEST je Jernej Škrabec napisal(a):
> Dne četrtek, 28. junij 2018 ob 20:25:43 CEST je Maxime Ripard napisal(a):
> > On Thu, Jun 28, 2018 at 06:48:50AM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 28. junij 2018 ob 04:06:52 CEST je Chen-Yu Tsai napisal(a):
> > > > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> > > >
> > >
> > > wrote:
> > > > > Current "old" method to find engine worked pretty well for DE2.
> > > > > However,
> > > > > it doesn't work when TCON TOP is between mixer (engine) and TCON.
> > > > > TCON
> > > > > TOP has multiple input ports, but current engine search algorithm
> > > > > expects only one.
> > > > >
> > > > > This can be fixed by first looking for output port id and selecting
> > > > > matching input by subtracting 1 for the next round. This work even
> > > > > if
> > > > > there is only one input and output.
> > > > >
> > > > > Signed-off-by: Jernej Skrabec
> > > > > ---
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++
> > > > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > > > > 08747fc3ee71..264bcc43da11
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -791,12 +791,14 @@ static int sun4i_tcon_init_regmap(struct
> > > > > device
> > > > > *dev,
> > > > >
> > > > > */
> > > > >
> > > > > static struct sunxi_engine *
> > > > > sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
> > > > >
> > > > > - struct device_node *node)
> > > > > + struct device_node *node,
> > > > > + u32 port_id)
> > > > >
> > > > > {
> > > > >
> > > > > struct device_node *port, *ep, *remote;
> > > > > struct sunxi_engine *engine = ERR_PTR(-EINVAL);
> > > > >
> > > > > + u32 reg = 0;
> > > > >
> > > > > - port = of_graph_get_port_by_id(node, 0);
> > > > > + port = of_graph_get_port_by_id(node, port_id);
> > > > >
> > > > > if (!port)
> > > > >
> > > > > return ERR_PTR(-EINVAL);
> > > > >
> > > > > @@ -826,8 +828,20 @@ sun4i_tcon_find_engine_traverse(struct
> > > > > sun4i_drv
> > > > > *drv,
> > > > >
> > > > > if (remote == engine->node)
> > > > >
> > > > > goto out_put_remote;
> > > > >
> > > > > + /*
> > > > > +* According to device tree binding input ports have even id
> > > > > +* number and output ports have odd id. Since component with
> > > > > +* more than one input and one output (TCON TOP) exits,
> > > > > correct
> > > > > +* remote input id has to be calculated by subtracting 1
> > > > > from
> > > > > +* remote output id. If this for some reason can't be done,
> > > > > 0
> > > > > +* is used as input port id.
> > > > > +*/
> > > >
> > > > You need to call
> > > >
> > > > of_node_put(port);
> > > >
> > > > to drop the reference to the original port.
> > >
> > > Thanks for noticing it. I guess I should send fix patch, since patches
> > > from
> > > drm-misc-next can't be dropped.
> >
> > Yeah, please send additional patches for all the issues pointed out by
> > Chen-Yu.
>
> Of course. I hope this can be resolved till the end of the next week. After
> that, I will be away from PC for 2 weeks. Feel free to drop DT patches if
> you think that it will come too close to merge window.
Actually, can you drop it anyway? It needs a lot of changes and keeping HDMI
working would need some effort.
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plane transitional helper prototypes mismatch their methods
Ping. On Mon, Jun 25, 2018 at 04:52:16PM +0100, Russell King - ARM Linux wrote: > Hi, > > Currently, the transitional plane helpers have prototypes that > do not have the drm_modeset_acquire_ctx argument: > > int drm_plane_helper_update(struct drm_plane *plane, struct drm_crtc *crtc, > struct drm_framebuffer *fb, > int crtc_x, int crtc_y, > unsigned int crtc_w, unsigned int crtc_h, > uint32_t src_x, uint32_t src_y, > uint32_t src_w, uint32_t src_h); > int drm_plane_helper_disable(struct drm_plane *plane); > > However, the helper methods have this as the last argument: > > int (*update_plane)(struct drm_plane *plane, > struct drm_crtc *crtc, struct drm_framebuffer *fb, > int crtc_x, int crtc_y, > unsigned int crtc_w, unsigned int crtc_h, > uint32_t src_x, uint32_t src_y, > uint32_t src_w, uint32_t src_h, > struct drm_modeset_acquire_ctx *ctx); > int (*disable_plane)(struct drm_plane *plane, > struct drm_modeset_acquire_ctx *ctx); > > Are these transitional helpers supposed to be plugged into these > methods directly? Looking back in the history, the following commit > to i915 seems to suggest that they were designed to be plugged > directly into these methods: > > commit ea2c67bb4affa84080c616920f3899f123786e56 > Author: Matt Roper > Date: Tue Dec 23 10:41:52 2014 -0800 > > drm/i915: Move to atomic plane helpers (v9) > > It seems easy to add this argument to drm_plane_helper_update() as > it has no current users, but the drm_plane_helper_disable() > transitional helper seems to be used extensively by what are > otherwise fully atomic modeset drivers, despite being described as > only a transitional helper. > > drivers/gpu/drm/arm/hdlcd_crtc.c: drm_plane_helper_disable(plane); > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c: drm_plane_helper_disable(plane); > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c: drm_plane_helper_disable(plane); > drivers/gpu/drm/arc/arcpgu_crtc.c: drm_plane_helper_disable(plane); > drivers/gpu/drm/sti/sti_hqvdp.c:drm_plane_helper_disable(drm_plane); > drivers/gpu/drm/sti/sti_gdp.c: drm_plane_helper_disable(drm_plane); > drivers/gpu/drm/sti/sti_cursor.c: drm_plane_helper_disable(drm_plane); > drivers/gpu/drm/vc4/vc4_plane.c:drm_plane_helper_disable(plane); > drivers/gpu/drm/zte/zx_plane.c: drm_plane_helper_disable(plane); > > Are these drivers buggy using the transitional helper, which won't do > anything but change the state of that single plane, leaving the CRTC, > encoders, bridges, etc all active? > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: introduce for_each_registered_fb() helper
On Fri, Jun 29, 2018 at 07:20:13PM +0300, Andy Shevchenko wrote:
> On Fri, 2018-06-29 at 00:20 +0800, Yisheng Xie wrote:
> > Following pattern is often used:
> >
> > for (i = 0; i < FB_MAX; i++) {
> > if (registered_fb[i]) {
> > ...
> > }
> > }
> >
> > Therefore, as Andy's suggestion, for_each_registered_fb() helper can
>
> Suggested-by then ?
>
> > be introduced to make the code easier to read and write by reducing
> > indentation level. It also saves few lines of code in each occurrence.
> >
> > This patch convert all part here at the same time.
>
> LGTM except macro implementation. That's why I have mentioned
> for_each_pci_bridge() to look at.
>
> > +#define for_each_registered_fb(i) \
> > + for (i = 0; i < FB_MAX; i++)\
> > + if (registered_fb[i])
> > +
>
> This needs to be protected against nested conditionals.
> Otherwise compiler issues a warning and even may generate wrong code.
See for_each_if() in include/drm/drmP.h ... we should probably lift that
into a general header. The for_each_if() is used all over drm in iterator
macros, exactly to avoid surprises.
-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 1/2] drm/panel: Augment the TPO TPG110 bindings
On 01.07.2018 21:01, Linus Walleij wrote: > On Wed, Jun 27, 2018 at 7:21 PM Rob Herring wrote: >> On Thu, Jun 21, 2018 at 08:49:41PM +0200, Linus Walleij wrote: >>> +This panel driver can driver a variety of panels. It requires >> s/can driver/can drive/ >> >> Though what a driver supports is irrelevant to the binding... > It it not a software driver the text is referring to. It is a > electrical interface to a panel. Like how a TTL circuit connected > to a LED is referred to as a "LED driver", it's simply what the > industry calls these things. > > So there are two things: the panel driver and the panel, the > same panel driver is used with several panels. What the > electronics engineer will do is put a panel driver like this > into his design and then connect some panel s/he finds > in the right quantity in the streets of Shenzhen. > >> If you remove timings, how does it drive a variety of panels? Just by >> compatible? > Yes. > > Like we did for > Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt > which is similar to this. > > In fact I think many panel drivers are just sloppily slipping in > under the radar as "panels" in our bindings. > >> That would mean "tpo,tpg110" alone is not valid nor useful >> as a fallback. > Actually it is. The hardware is wired up to the desired > resolution with hardware straps, which appear in > the registers the (software) driver can read out so > this is ideally self-describing hardware. > > But for the event that something needs tweaking in the > future, like we overspecify say SoCs, I include the > exact system on which it is deployd as a separate > compatible string. > >>> +a few GPIO lines for control of its reset line and custom serial >>> +protocol. >>> >>> Required properties: >>> -- compatible : "tpo,tpg110" >>> +- compatible : one of: >>> + "ste,nomadik-nhk15-display", "tpo,tpg110" >>> + "tpo,tpg110" >>> - grestb-gpios : panel reset GPIO >>> - scen-gpios : serial control enable GPIO >>> - scl-gpios : serial control clock line GPIO >>> - sda-gpios : serial control data line GPIO >> I2C? That should be done differently... > It is not I2C, the lines are just named confusingly > similar. None of the I2C (-like) protocols apply. > I was similarly confused when I first implemented it. > > (Maybe I should add a comment to explain this.) I have grepped Internet, out of curiosity, and it seems it is so-called 3-wire spi [1]. [1]: http://aitendo3.sakura.ne.jp/aitendo_data/product_img/lcd/tft/T43P00/TPG110%20Customer%20Spec_0.6.pdf Regards Andrzej > > Yours, > Linus Walleij > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/i915: Filter out modes that don't match the fixed mode vrefresh
On Thu, Jun 28, 2018 at 10:43:01PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We only ever drive the panel with the fixed mode, hence we don't
> want to advertize any modes that have a different vertical refresh rate.
>
> We tried to allow a second lower clocked mode to used for eDP but
> that was reverted in commit d93fa1b47b8f ("Revert "drm/i915/edp:
> Allow alternate fixed mode for eDP if available.""). To do that properly
> I think we should probably just keep all (or just some?) of the probed
> modes around (presumably all of them actually work if the panel
> advertizes them), and we'd just pick the closest match based on the
> user mode.
>
> For now we don't have any of that so we shouldn't lie to the user
> that they can drive the panel at different refresh rate. Note that
> we still don't reject any user mode with bad refresh rate. That's
> going to be step two.
>
> TODO: Should we allow for a larger error margin?
>
> Signed-off-by: Ville Syrjälä
Not sure the current vrefresh is any good, since it's HZ resolution only.
That's not precise enough for the video aficionados, who insist on that
entire 1001/1000 business.
I did look around a bit with a quick git grep, and most places only use
->vrefresh for debug printing. Then there's a few that use it as an index
(e.g. i915 DRRS code), and then there's the totally misguided code in
adv7511 which thinks vrefresh is in kHz.
There's also quite a pile of mode->vrefresh ? mode->vrefresh :
drm_mode_vrefresh(mode) around, which really doesn't inspire confidence
that we'll ever catch them all. It feels like those "recompute vrefresh"
things have been cargo-culted for ages.
I think we need to clean this up harder:
- switch everyone over to drm_mode_vrefresh()
- nuke drm_display_mode->vrefresh
- add a new drm_mode_vrefresh_mHz (for milli-Hz, i.e. fixed point math
ftw)
- use that new function in the mode filtering, with a bit of fudge that
keeps the 1001/1000 modes separate, but papers over rounding errors. I
think we could even do a drm_mode_compare_vrefresh for that, we're
probably not the only ones who'd like to have such a function.
Probably a bit more work to type (but cocci might help here), definitely
less painful to make sure it stays correct I think. Thoughts?
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +++
> drivers/gpu/drm/i915/intel_dsi.c | 2 ++
> drivers/gpu/drm/i915/intel_dvo.c | 2 ++
> drivers/gpu/drm/i915/intel_lvds.c | 2 ++
> drivers/gpu/drm/i915/intel_sdvo.c | 2 ++
> 5 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5be07e1d816d..22feb0b144f6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -446,6 +446,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
>
> + if (mode->vrefresh != fixed_mode->vrefresh)
> + return MODE_PANEL;
> +
> target_clock = fixed_mode->clock;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 3b7acb5a70b3..3d0758cec85a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1277,6 +1277,8 @@ intel_dsi_mode_valid(struct drm_connector *connector,
> return MODE_PANEL;
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
> + if (mode->vrefresh != fixed_mode->vrefresh)
> + return MODE_PANEL;
> if (fixed_mode->clock > max_dotclk)
> return MODE_CLOCK_HIGH;
> }
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 4e142ff49708..078bb848a49a 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -225,6 +225,8 @@ intel_dvo_mode_valid(struct drm_connector *connector,
> return MODE_PANEL;
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
> + if (mode->vrefresh != fixed_mode->vrefresh)
> + return MODE_PANEL;
>
> target_clock = fixed_mode->clock;
> }
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index bb06744d28a4..d312a8911b89 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -384,6 +384,8 @@ intel_lvds_mode_valid(struct drm_connector *connector,
> return MODE_PANEL;
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
> + if (mode->vrefresh != fixed_mode->vrefresh)
> + return MODE_PANEL;
> if (fixed_mode->clock > max_pixclk)
> return MODE_CLOCK_HIGH;
>
> diff --git a/drivers/gpu/drm/i915/intel_sdv
Re: [PATCH v2 1/8] drm/atomic: Avoid connector to writeback_connector casts
On Fri, Jun 29, 2018 at 01:17:14PM +0200, Boris Brezillon wrote:
> Use container_of() instead of type casting so that it keeps working
> even if base is moved inside the drm_writeback_connector struct.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 4 +++-
> include/drm/drm_writeback.h | 6 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 178842380f75..6ea20d5dee66 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2423,6 +2423,7 @@ static int prepare_signaling(struct drm_device *dev,
> }
>
> for_each_new_connector_in_state(state, conn, conn_state, i) {
> + struct drm_writeback_connector *wb_conn;
> struct drm_writeback_job *job;
> struct drm_out_fence_state *f;
> struct dma_fence *fence;
> @@ -2446,7 +2447,8 @@ static int prepare_signaling(struct drm_device *dev,
> f[*num_fences].out_fence_ptr = fence_ptr;
> *fence_state = f;
>
> - fence = drm_writeback_get_out_fence((struct
> drm_writeback_connector *)conn);
> + wb_conn = drm_connector_to_writeback(conn);
> + fence = drm_writeback_get_out_fence(wb_conn);
> if (!fence)
> return -ENOMEM;
>
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index a10fe556dfd4..23df9d463003 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -110,6 +110,12 @@ struct drm_writeback_job {
> struct dma_fence *out_fence;
> };
>
> +static inline struct drm_writeback_connector *
> +drm_connector_to_writeback(struct drm_connector *connector)
> +{
> + return container_of(connector, struct drm_writeback_connector, base);
> +}
> +
> int drm_writeback_connector_init(struct drm_device *dev,
>struct drm_writeback_connector *wb_connector,
>const struct drm_connector_funcs *con_funcs,
> --
> 2.14.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/connector: Pass a drm_connector_state to ->atomic_commit()
On Fri, Jun 29, 2018 at 12:37:10PM +0100, Liviu Dudau wrote:
> On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> > Other atomic hooks are passed state objects, let's change this one to
> > be consistent.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> > include/drm/drm_modeset_helper_vtables.h | 4 +++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 17baf5057132..69063bcf2334 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1187,7 +1187,7 @@ static void
> > drm_atomic_helper_commit_writebacks(struct drm_device *dev,
> >
> > if (new_conn_state->writeback_job &&
> > new_conn_state->writeback_job->fb) {
> > WARN_ON(connector->connector_type !=
> > DRM_MODE_CONNECTOR_WRITEBACK);
> > - funcs->atomic_commit(connector,
> > new_conn_state->writeback_job);
> > + funcs->atomic_commit(connector, new_conn_state);
>
> Forgot to add: I think it is worth adding a check here that the hook has
> been implemented by the driver, AFAIK it is not a mandatory hook, even
> for writeback enabled drivers.
Either way this should be documented in the hook (atm it says nothing
about whether it's mandatory/optional and for whom).
>
> Let me know what you plan to do with this patch as I will have to update
> the malidp patches as well, otherwise linux-next is going to flag me.
Probably simplest if you send a pull to Dave right away with the current
malidp code, then we backmerge that into drm-misc-next, and Boris rebases.
There's no point in hanging onto pull requests until right before the
feature freeze, just makes things more complicated.
Patch itself lgtm.
Reviewed-by: Daniel Vetter
>
> Best regards,
> Liviu
>
> > }
> > }
> > }
> > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 3b289773297c..fb841f44949c 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -980,11 +980,13 @@ struct drm_connector_helper_funcs {
> > *
> > * This hook is to be used by drivers implementing writeback connectors
> > * that need a point when to commit the writeback job to the hardware.
> > +* The writeback_job to commit is available in
> > +* &drm_connector_state.writeback_job.
> > *
> > * This callback is used by the atomic modeset helpers.
> > */
> > void (*atomic_commit)(struct drm_connector *connector,
> > - struct drm_writeback_job *writeback_job);
> > + struct drm_connector_state *state);
> > };
> >
> > /**
> > --
> > 2.14.1
> >
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
--
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 5/8] drm/atomic: Call drm_atomic_helper_fake_vblank() from the generic commit_tail() helpers
On Fri, Jun 29, 2018 at 01:17:18PM +0200, Boris Brezillon wrote: > Now that we have a way to fake VBLANK events when requested by the CRTC > hook it up to the generic commit_tail() helpers. > > Signed-off-by: Boris Brezillon I really don't like this. We've had epic amounts of bugs with atomic drivers failing to send out vblank events when they should, and I added a bunch of debug checks to make sure that doesn't happen anymore. Now there's no way anymore for drivers to spot this until they have misrenderings on wayland and no idea why. Imo this should only be used by specific drivers, with a comment why exactly they need it. -Daniel > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index ca586993c2a2..1a088462bc42 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1448,6 +1448,8 @@ void drm_atomic_helper_commit_tail(struct > drm_atomic_state *old_state) > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > + drm_atomic_helper_fake_vblank(old_state); > + > drm_atomic_helper_commit_hw_done(old_state); > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > @@ -1477,6 +1479,8 @@ void drm_atomic_helper_commit_tail_rpm(struct > drm_atomic_state *old_state) > drm_atomic_helper_commit_planes(dev, old_state, > DRM_PLANE_COMMIT_ACTIVE_ONLY); > > + drm_atomic_helper_fake_vblank(old_state); > + > drm_atomic_helper_commit_hw_done(old_state); > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > -- > 2.14.1 > -- 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 5/8] drm/atomic: Call drm_atomic_helper_fake_vblank() from the generic commit_tail() helpers
On Mon, Jul 02, 2018 at 09:54:32AM +0200, Daniel Vetter wrote: > On Fri, Jun 29, 2018 at 01:17:18PM +0200, Boris Brezillon wrote: > > Now that we have a way to fake VBLANK events when requested by the CRTC > > hook it up to the generic commit_tail() helpers. > > > > Signed-off-by: Boris Brezillon > > I really don't like this. We've had epic amounts of bugs with atomic > drivers failing to send out vblank events when they should, and I added a > bunch of debug checks to make sure that doesn't happen anymore. > > Now there's no way anymore for drivers to spot this until they have > misrenderings on wayland and no idea why. Imo this should only be used by > specific drivers, with a comment why exactly they need it. Meh I retract, you have the special no_vblank state flag to control this. Looks all good to me. Reviewed-by: Daniel Vetter > -Daniel > > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index ca586993c2a2..1a088462bc42 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1448,6 +1448,8 @@ void drm_atomic_helper_commit_tail(struct > > drm_atomic_state *old_state) > > > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > > > + drm_atomic_helper_fake_vblank(old_state); > > + > > drm_atomic_helper_commit_hw_done(old_state); > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > @@ -1477,6 +1479,8 @@ void drm_atomic_helper_commit_tail_rpm(struct > > drm_atomic_state *old_state) > > drm_atomic_helper_commit_planes(dev, old_state, > > DRM_PLANE_COMMIT_ACTIVE_ONLY); > > > > + drm_atomic_helper_fake_vblank(old_state); > > + > > drm_atomic_helper_commit_hw_done(old_state); > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > -- > > 2.14.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- 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 5/8] drm/atomic: Call drm_atomic_helper_fake_vblank() from the generic commit_tail() helpers
On Mon, 2 Jul 2018 09:54:32 +0200 Daniel Vetter wrote: > On Fri, Jun 29, 2018 at 01:17:18PM +0200, Boris Brezillon wrote: > > Now that we have a way to fake VBLANK events when requested by the CRTC > > hook it up to the generic commit_tail() helpers. > > > > Signed-off-by: Boris Brezillon > > I really don't like this. We've had epic amounts of bugs with atomic > drivers failing to send out vblank events when they should, and I added a > bunch of debug checks to make sure that doesn't happen anymore. > > Now there's no way anymore for drivers to spot this until they have > misrenderings on wayland and no idea why. Imo this should only be used by > specific drivers, with a comment why exactly they need it. Hm, that's not entirely true. Drivers have to explicitly set ->no_vblank to true for drm_atomic_helper_fake_vblank() to actually do something, and I seriously hope drivers won't set that field randomly. So, on all existing drivers but VC4 after the TXP patch, the behavior will be unchanged, and the core will spot misbehaving drivers just like before. > -Daniel > > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index ca586993c2a2..1a088462bc42 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -1448,6 +1448,8 @@ void drm_atomic_helper_commit_tail(struct > > drm_atomic_state *old_state) > > > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > > > + drm_atomic_helper_fake_vblank(old_state); > > + > > drm_atomic_helper_commit_hw_done(old_state); > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > @@ -1477,6 +1479,8 @@ void drm_atomic_helper_commit_tail_rpm(struct > > drm_atomic_state *old_state) > > drm_atomic_helper_commit_planes(dev, old_state, > > DRM_PLANE_COMMIT_ACTIVE_ONLY); > > > > + drm_atomic_helper_fake_vblank(old_state); > > + > > drm_atomic_helper_commit_hw_done(old_state); > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > -- > > 2.14.1 > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/atomic: Call drm_atomic_helper_fake_vblank() from the generic commit_tail() helpers
On Mon, 2 Jul 2018 09:57:30 +0200 Daniel Vetter wrote: > On Mon, Jul 02, 2018 at 09:54:32AM +0200, Daniel Vetter wrote: > > On Fri, Jun 29, 2018 at 01:17:18PM +0200, Boris Brezillon wrote: > > > Now that we have a way to fake VBLANK events when requested by the CRTC > > > hook it up to the generic commit_tail() helpers. > > > > > > Signed-off-by: Boris Brezillon > > > > I really don't like this. We've had epic amounts of bugs with atomic > > drivers failing to send out vblank events when they should, and I added a > > bunch of debug checks to make sure that doesn't happen anymore. > > > > Now there's no way anymore for drivers to spot this until they have > > misrenderings on wayland and no idea why. Imo this should only be used by > > specific drivers, with a comment why exactly they need it. > > Meh I retract, you have the special no_vblank state flag to control this. > Looks all good to me. Hehe, just replied to your other email :-). > > Reviewed-by: Daniel Vetter > > > -Daniel > > > > > --- > > > drivers/gpu/drm/drm_atomic_helper.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > b/drivers/gpu/drm/drm_atomic_helper.c > > > index ca586993c2a2..1a088462bc42 100644 > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > @@ -1448,6 +1448,8 @@ void drm_atomic_helper_commit_tail(struct > > > drm_atomic_state *old_state) > > > > > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > > > > > + drm_atomic_helper_fake_vblank(old_state); > > > + > > > drm_atomic_helper_commit_hw_done(old_state); > > > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > > @@ -1477,6 +1479,8 @@ void drm_atomic_helper_commit_tail_rpm(struct > > > drm_atomic_state *old_state) > > > drm_atomic_helper_commit_planes(dev, old_state, > > > DRM_PLANE_COMMIT_ACTIVE_ONLY); > > > > > > + drm_atomic_helper_fake_vblank(old_state); > > > + > > > drm_atomic_helper_commit_hw_done(old_state); > > > > > > drm_atomic_helper_wait_for_vblanks(dev, old_state); > > > -- > > > 2.14.1 > > > > > > > -- > > 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 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> In some cases CRTCs are active but are not able to generating events, at
> least not at every frame at it's expected to.
> This is typically the case when the CRTC is feeding a writeback connector
> that has no job queued. In this situation the CRTC is usually stopped
> until a new job is queued, and this can lead to timeouts when part of
> the pipeline is updated but no new jobs are queued to the active
> writeback connector.
>
> In order to solve that, we add a ->no_vblank flag to drm_crtc_state
> and ask the CRTC drivers to set it to true when they know they're not
> able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
> helper can then be used to fake VBLANKs at commit time.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 40
> +
> include/drm/drm_atomic_helper.h | 1 +
> include/drm/drm_crtc.h | 15 ++
> 3 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 69063bcf2334..ca586993c2a2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2051,6 +2051,46 @@ void drm_atomic_helper_wait_for_dependencies(struct
> drm_atomic_state *old_state)
> }
> EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
>
> +/**
> + * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
> + * @old_state: atomic state object with old state structures
> + *
> + * This function walks all CRTCs and fake VBLANK events on those with
> + * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event != NULL.
> + * The primary use of this function is writeback connectors working in
> oneshot
> + * mode and faking VBLANK events. In this case they only fake the VBLANK
> event
> + * when a job is queued, and any change to the pipeline that does not touch
> the
> + * connector is leading to timeouts when calling
> + * drm_atomic_helper_wait_for_vblanks() or
> + * drm_atomic_helper_wait_for_flip_done().
> + *
> + * This is part of the atomic helper support for nonblocking commits, see
> + * drm_atomic_helper_setup_commit() for an overview.
> + */
> +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
> +{
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + unsigned long flags;
> +
> + if (!new_crtc_state->no_vblank && !old_crtc_state->no_vblank)
Uh, this essentially makes it impossible to reset no_vblank. For control
flow state bits we only check the new state for it (see e.g. the various
*_changed or plane_bits or whatever).
> + continue;
> +
> + spin_lock_irqsave(&old_state->dev->event_lock, flags);
> + if (new_crtc_state->event) {
> + drm_crtc_send_vblank_event(crtc,
> +new_crtc_state->event);
> + new_crtc_state->event = NULL;
> + }
> + spin_unlock_irqrestore(&old_state->dev->event_lock, flags);
> + }
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> +
> /**
> * drm_atomic_helper_commit_hw_done - setup possible nonblocking commit
> * @old_state: atomic state object with old state structures
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 26aaba58d6ce..99e2a5297c69 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -100,6 +100,7 @@ int __must_check drm_atomic_helper_swap_state(struct
> drm_atomic_state *state,
> int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
> bool nonblock);
> void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state *state);
> +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *state);
> void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *state);
> void drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 23eddbccab10..7435dc66c08a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -87,6 +87,20 @@ struct drm_plane_helper_funcs;
> * @zpos_changed: zpos values of planes on this crtc have been updated
> * @color_mgmt_changed: color management properties have changed (degamma or
> * gamma LUT or CSC matrix)
> + * @no_vblank: reflects the ability of a CRTC to send VBLANK events. This
> state
> + * usually depends on the pipeline configuration, and the main usuage is
> + * CRTCs feeding a writeback connector operating in oneshot mode. In this
> + * case the VBLANK event is only generated
[Bug 107072] 4k hdmi monitor stays black on kaveri [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=107072 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #6 from Michel Dänzer --- Does amdgpu.dc=0 avoid the problem? DC will be disabled by default again for Kaveri. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Use kvzalloc for allocating blob property memory
On Fri, Jun 29, 2018 at 07:38:32PM +0300, Ville Syrjälä wrote: > On Fri, Jun 29, 2018 at 06:27:28PM +0200, Michel Dänzer wrote: > > On 2018-06-29 06:12 PM, Ville Syrjälä wrote: > > > On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote: > > >> From: Michel Dänzer > > >> > > >> The property size may be controlled by userspace, can be large (I've > > >> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be > > >> physically contiguous. > > > > > > I wonder if we should enforce some kind of reasonable limit > > > on the blob size. Looks like we allow anything up to > > > ULONG_MAX currently. We can't tell at createblob time how > > > the thing is going to be used, so can't have any kind > > > of property specific limit unfortunately. > > > > The failure I was seeing was for a gamma LUT, so a size limit alone > > cannot solve the issue. > > Sure. I was just thinking that maybe we shouldn't allow someone to > allocate unlimited amounts of kernel memory via this interface. But > to do that effectively we'd also need to limit the total amount used > by all blobs. People with drm master rights are allowed to pin enormous amounts of memory (through pinning of display buffers) ... I think simply requiring DRM_MASTER for the ioctl would be good enough. Atm anyone can abuse createblob to waste memory, which is a bit much. We haven't marked it with DRM_RENDER_ALLOW, so I think this is just an oversight really. I'll type a patch. -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] drm: Make sure that encoder_type for drm_encoder_init() is in the list
On Fri, Jun 29, 2018 at 03:47:43PM -0600, Jordan Crouse wrote: > If a encoder name isn't specified for drm_encoder_init() it will try > to construct one based on the incoming encoder_type identifier. If the > caller passes an invalid encoder_type value the lookup could walk right > past the end of the table. > > [v2: Use a WARN() at the top of the function as suggested by Daniel > Vetter] > > Signed-off-by: Jordan Crouse Reviewed-by: Daniel Vetter Aside: Want drm-misc commit rights so you can push patches like these yourself? Might also be useful in case the group maintainership thing with msm happens, just as prep. -Daniel > --- > drivers/gpu/drm/drm_encoder.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c > index 273e1c59c54a..6228c2cee5f0 100644 > --- a/drivers/gpu/drm/drm_encoder.c > +++ b/drivers/gpu/drm/drm_encoder.c > @@ -114,6 +114,10 @@ int drm_encoder_init(struct drm_device *dev, > if (WARN_ON(dev->mode_config.num_encoder >= 32)) > return -EINVAL; > > + /* Make sure that the requested encoder type is in the list */ > + if (WARN_ON(encoder_type >= ARRAY_SIZE(drm_encoder_enum_list))) > + return -EINVAL; > + > ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER); > if (ret) > return ret; > -- > 2.17.1 > -- 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
[PATCH] drm: Limite blob creation to drm master
This interface allows pretty much unlimited kernel memory allocations,
which isn't all that great. But we allow that anyway for any drm
master client (through pinning display buffers and stuff, at least for
UMA gpus), so just limiting it to the active master seems like a
reasonable stopgap measure.
Fixes: e2f5d2ea479b ("drm/mode: Add user blob-creation ioctl")
Cc: Daniel Stone
Cc: Ville Syrjälä
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index c148eb3be8c2..dc740c381f9e 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -656,8 +656,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR2, drm_mode_cursor2_ioctl,
DRM_MASTER|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl,
DRM_MASTER|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
drm_mode_destroyblob_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
drm_mode_destroyblob_ioctl, DRM_MASTER|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_CREATE, drm_syncobj_create_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
On Mon, 2 Jul 2018 10:02:52 +0200
Daniel Vetter wrote:
> On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> > In some cases CRTCs are active but are not able to generating events, at
> > least not at every frame at it's expected to.
> > This is typically the case when the CRTC is feeding a writeback connector
> > that has no job queued. In this situation the CRTC is usually stopped
> > until a new job is queued, and this can lead to timeouts when part of
> > the pipeline is updated but no new jobs are queued to the active
> > writeback connector.
> >
> > In order to solve that, we add a ->no_vblank flag to drm_crtc_state
> > and ask the CRTC drivers to set it to true when they know they're not
> > able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
> > helper can then be used to fake VBLANKs at commit time.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 40
> > +
> > include/drm/drm_atomic_helper.h | 1 +
> > include/drm/drm_crtc.h | 15 ++
> > 3 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 69063bcf2334..ca586993c2a2 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2051,6 +2051,46 @@ void drm_atomic_helper_wait_for_dependencies(struct
> > drm_atomic_state *old_state)
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
> >
> > +/**
> > + * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
> > + * @old_state: atomic state object with old state structures
> > + *
> > + * This function walks all CRTCs and fake VBLANK events on those with
> > + * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event != NULL.
> > + * The primary use of this function is writeback connectors working in
> > oneshot
> > + * mode and faking VBLANK events. In this case they only fake the VBLANK
> > event
> > + * when a job is queued, and any change to the pipeline that does not
> > touch the
> > + * connector is leading to timeouts when calling
> > + * drm_atomic_helper_wait_for_vblanks() or
> > + * drm_atomic_helper_wait_for_flip_done().
> > + *
> > + * This is part of the atomic helper support for nonblocking commits, see
> > + * drm_atomic_helper_setup_commit() for an overview.
> > + */
> > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
> > +{
> > + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > + struct drm_crtc *crtc;
> > + int i;
> > +
> > + for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > + new_crtc_state, i) {
> > + unsigned long flags;
> > +
> > + if (!new_crtc_state->no_vblank && !old_crtc_state->no_vblank)
>
> Uh, this essentially makes it impossible to reset no_vblank.
I don't want ->no_vblank to be reset by the core. It's up to the CRTC
driver to clear/set it when something changes in the pipeline.
> For control
> flow state bits we only check the new state for it (see e.g. the various
> *_changed or plane_bits or whatever).
I tried with !new_crtc_state->no_vblank only, but then it does not
handle the case where the CRTC and connector are being disabled, and I
end up with a timeout.
>
> > + continue;
> > +
> > + spin_lock_irqsave(&old_state->dev->event_lock, flags);
> > + if (new_crtc_state->event) {
> > + drm_crtc_send_vblank_event(crtc,
> > + new_crtc_state->event);
> > + new_crtc_state->event = NULL;
> > + }
> > + spin_unlock_irqrestore(&old_state->dev->event_lock, flags);
> > + }
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > +
> > /**
> > * drm_atomic_helper_commit_hw_done - setup possible nonblocking commit
> > * @old_state: atomic state object with old state structures
> > diff --git a/include/drm/drm_atomic_helper.h
> > b/include/drm/drm_atomic_helper.h
> > index 26aaba58d6ce..99e2a5297c69 100644
> > --- a/include/drm/drm_atomic_helper.h
> > +++ b/include/drm/drm_atomic_helper.h
> > @@ -100,6 +100,7 @@ int __must_check drm_atomic_helper_swap_state(struct
> > drm_atomic_state *state,
> > int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
> >bool nonblock);
> > void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state
> > *state);
> > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *state);
> > void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *state);
> > void drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state);
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 23eddbccab10..7435dc66c08a 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_cr
Re: [PATCH 04/15] dma-fence: Make ->wait callback optional
On Fri, May 04, 2018 at 03:47:59PM +0200, Daniel Vetter wrote: > On Fri, May 04, 2018 at 03:17:08PM +0200, Christian König wrote: > > Am 04.05.2018 um 11:25 schrieb Daniel Vetter: > > > On Fri, May 4, 2018 at 11:16 AM, Chris Wilson > > > wrote: > > > > Quoting Daniel Vetter (2018-05-04 09:57:59) > > > > > On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote: > > > > > > Quoting Daniel Vetter (2018-05-04 09:23:01) > > > > > > > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote: > > > > > > > > On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote: > > > > > > > > > Quoting Daniel Vetter (2018-05-03 15:25:52) > > > > > > > > > > Almost everyone uses dma_fence_default_wait. > > > > > > > > > > > > > > > > > > > > v2: Also remove the BUG_ON(!ops->wait) (Chris). > > > > > > > > > I just don't get the rationale for implicit over explicit. > > > > > > > > Closer approximation of dwim semantics. There's been tons of > > > > > > > > patch series > > > > > > > > all over drm and related places to get there, once we have a > > > > > > > > big pile of > > > > > > > > implementations and know what the dwim semantics should be. > > > > > > > > Individually > > > > > > > > they're all not much, in aggregate they substantially simplify > > > > > > > > simple > > > > > > > > drivers. > > > > > > > I also think clearer separation between optional optimization > > > > > > > hooks and > > > > > > > mandatory core parts is useful in itself. > > > > > > A new spelling of midlayer ;) I don't see the contradiction with a > > > > > > driver saying use the default and simplicity. (I know which one the > > > > > > compiler thinks is simpler ;) > > > > > If the compiler overhead is real then I guess it would makes to be > > > > > explicit. I don't expect that to be a problem though for a blocking > > > > > function. > > > > > > > > > > I disagree on this being a midlayer - you can still overwrite > > > > > everything > > > > > you please to. What it does help is people doing less copypasting (and > > > > > assorted bugs), at least in the grand scheme of things. And we do > > > > > have a > > > > > _lot_ more random small drivers than just a few years ago. Reducing > > > > > the > > > > > amount of explicit typing just to get default bahaviour has been an > > > > > ongoing theme for a few years now, and your objection here is about > > > > > the > > > > > first that this is not a good idea. So I'm somewhat confused. > > > > I'm just saying I don't see any rationale for this patch. > > > > > > > > "Almost everyone uses dma_fence_default_wait." > > > > > > > > Why change? > > > > > > > > Making it look simpler on the surface, so that you don't have to think > > > > about things straight away? I understand the appeal, but I do worry > > > > about it just being an illusion. (Cutting and pasting a line saying > > > > .wait = default_wait, doesn't feel that onerous, as you likely cut and > > > > paste the ops anyway, and at the very least you are reminded about some > > > > of the interactions. You could even have default initializers and/or > > > > magic macros to hide the cut and paste; maybe a simple_dma_fence [now > > > > that's a midlayer!] but I haven't looked.) > > > In really monolithic vtables like drm_driver we do use default > > > function macros, so you type 1 line, get them all. But dma_fence_ops > > > is pretty small, and most drivers only implement a few callbacks. Also > > > note that e.g. the ->release callback already works like that, so this > > > pattern is there already. I simply extended it to ->wait and > > > ->enable_signaling. Also note that I leave the EXPORT_SYMBOL in place, > > > you can still wrap dma_fence_default_wait if you wish to do so. > > > > > > But I just realized that I didn't clean out the optional release > > > hooks, I guess I should do that too (for the few cases it's not yet > > > done) and respin. > > > > I kind of agree with Chris here, but also see the practical problem to copy > > the default function in all the implementations. > > > > We had the same problem in TTM and I also don't really like the result to > > always have that "if (some_callback) default(); else some_callback();". > > > > Might be that the run time overhead is negligible, but it doesn't feels > > right from the coding style perspective. > > Hm, maybe I've seen too much bad code, but modeset helpers is choke full > of exactly that pattern. It's imo also a trade-off. If you have a fairly > specialized library like ttm that's used by relatively few things, doing > everything explicitly is probably better. It's also where kms started out > from. > > But if you have a huge pile of fairly simple drivers, imo the balance > starts to tip the other way, and a bit of additional logic in the shared > code to make all the implementations a notch simpler is good. If we > wouldn't have acquired quite a pile of dma_fence implementations I > wouldn't have bothered with all this. So
Re: [PATCH v2 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
On Mon, Jul 02, 2018 at 10:14:51AM +0200, Boris Brezillon wrote:
> On Mon, 2 Jul 2018 10:02:52 +0200
> Daniel Vetter wrote:
>
> > On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> > > In some cases CRTCs are active but are not able to generating events, at
> > > least not at every frame at it's expected to.
> > > This is typically the case when the CRTC is feeding a writeback connector
> > > that has no job queued. In this situation the CRTC is usually stopped
> > > until a new job is queued, and this can lead to timeouts when part of
> > > the pipeline is updated but no new jobs are queued to the active
> > > writeback connector.
> > >
> > > In order to solve that, we add a ->no_vblank flag to drm_crtc_state
> > > and ask the CRTC drivers to set it to true when they know they're not
> > > able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
> > > helper can then be used to fake VBLANKs at commit time.
> > >
> > > Signed-off-by: Boris Brezillon
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 40
> > > +
> > > include/drm/drm_atomic_helper.h | 1 +
> > > include/drm/drm_crtc.h | 15 ++
> > > 3 files changed, 56 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 69063bcf2334..ca586993c2a2 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2051,6 +2051,46 @@ void
> > > drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state
> > > *old_state)
> > > }
> > > EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
> > >
> > > +/**
> > > + * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
> > > + * @old_state: atomic state object with old state structures
> > > + *
> > > + * This function walks all CRTCs and fake VBLANK events on those with
> > > + * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event !=
> > > NULL.
> > > + * The primary use of this function is writeback connectors working in
> > > oneshot
> > > + * mode and faking VBLANK events. In this case they only fake the VBLANK
> > > event
> > > + * when a job is queued, and any change to the pipeline that does not
> > > touch the
> > > + * connector is leading to timeouts when calling
> > > + * drm_atomic_helper_wait_for_vblanks() or
> > > + * drm_atomic_helper_wait_for_flip_done().
> > > + *
> > > + * This is part of the atomic helper support for nonblocking commits, see
> > > + * drm_atomic_helper_setup_commit() for an overview.
> > > + */
> > > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
> > > +{
> > > + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > + struct drm_crtc *crtc;
> > > + int i;
> > > +
> > > + for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > > + new_crtc_state, i) {
> > > + unsigned long flags;
> > > +
> > > + if (!new_crtc_state->no_vblank && !old_crtc_state->no_vblank)
> >
> > Uh, this essentially makes it impossible to reset no_vblank.
>
> I don't want ->no_vblank to be reset by the core. It's up to the CRTC
> driver to clear/set it when something changes in the pipeline.
>
> > For control
> > flow state bits we only check the new state for it (see e.g. the various
> > *_changed or plane_bits or whatever).
>
> I tried with !new_crtc_state->no_vblank only, but then it does not
> handle the case where the CRTC and connector are being disabled, and I
> end up with a timeout.
Why that? You should have a new_crtc_state even when you disable the crtc,
and you can set the ->no_vblank on that one too. With your current code
it's essentially impossible to reset ->no_vblank, since it will only have
effect for the _next_ atomic update, not the one you're doing right now.
That doesn't make sense.
E.g. try to do the same logic of checking both old&new state for e.g.
needs_modeset and watch how all the logic totally falls to pieces.
-Daniel
>
> >
> > > + continue;
> > > +
> > > + spin_lock_irqsave(&old_state->dev->event_lock, flags);
> > > + if (new_crtc_state->event) {
> > > + drm_crtc_send_vblank_event(crtc,
> > > +new_crtc_state->event);
> > > + new_crtc_state->event = NULL;
> > > + }
> > > + spin_unlock_irqrestore(&old_state->dev->event_lock, flags);
> > > + }
> > > +}
> > > +EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > > +
> > > /**
> > > * drm_atomic_helper_commit_hw_done - setup possible nonblocking commit
> > > * @old_state: atomic state object with old state structures
> > > diff --git a/include/drm/drm_atomic_helper.h
> > > b/include/drm/drm_atomic_helper.h
> > > index 26aaba58d6ce..99e2a5297c69 100644
> > > --- a/include/drm/drm_atomic_helper.h
> > > +++ b/include/drm/drm_atomic_helper.h
> > > @@
Re: [PATCH] drm/msm/adreno: Remove VLA usage
> @@ -91,12 +93,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu,
> const char *fwname)
> ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
> mem_region, mem_phys, mem_size, NULL);
> } else {
> - char newname[strlen("qcom/") + strlen(fwname) + 1];
> + char *newname;
>
> - sprintf(newname, "qcom/%s", fwname);
> + newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
>
> ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
> mem_region, mem_phys, mem_size, NULL);
I have taken another look also at this update suggestion.
Now I wonder why the return value is not checked for the added name construction
in the way as it is specified for the function “adreno_request_fw”.
Will another condition check make sense at this place?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
Forgot to address your other comments.
On Mon, Jul 02, 2018 at 10:14:51AM +0200, Boris Brezillon wrote:
> On Mon, 2 Jul 2018 10:02:52 +0200
> Daniel Vetter wrote:
> > On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> > > In some cases CRTCs are active but are not able to generating events, at
> > > least not at every frame at it's expected to.
> > > This is typically the case when the CRTC is feeding a writeback connector
> > > that has no job queued. In this situation the CRTC is usually stopped
> > > until a new job is queued, and this can lead to timeouts when part of
> > > the pipeline is updated but no new jobs are queued to the active
> > > writeback connector.
> > >
> > > In order to solve that, we add a ->no_vblank flag to drm_crtc_state
> > > and ask the CRTC drivers to set it to true when they know they're not
> > > able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
> > > helper can then be used to fake VBLANKs at commit time.
> > >
> > > Signed-off-by: Boris Brezillon
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 40
> > > +
> > > include/drm/drm_atomic_helper.h | 1 +
> > > include/drm/drm_crtc.h | 15 ++
> > > 3 files changed, 56 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 69063bcf2334..ca586993c2a2 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2051,6 +2051,46 @@ void
> > > drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state
> > > *old_state)
> > > }
> > > EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
> > >
> > > +/**
> > > + * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
> > > + * @old_state: atomic state object with old state structures
> > > + *
> > > + * This function walks all CRTCs and fake VBLANK events on those with
> > > + * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event !=
> > > NULL.
> > > + * The primary use of this function is writeback connectors working in
> > > oneshot
> > > + * mode and faking VBLANK events. In this case they only fake the VBLANK
> > > event
> > > + * when a job is queued, and any change to the pipeline that does not
> > > touch the
> > > + * connector is leading to timeouts when calling
> > > + * drm_atomic_helper_wait_for_vblanks() or
> > > + * drm_atomic_helper_wait_for_flip_done().
> > > + *
> > > + * This is part of the atomic helper support for nonblocking commits, see
> > > + * drm_atomic_helper_setup_commit() for an overview.
> > > + */
> > > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
> > > +{
> > > + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > + struct drm_crtc *crtc;
> > > + int i;
> > > +
> > > + for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > > + new_crtc_state, i) {
> > > + unsigned long flags;
> > > +
> > > + if (!new_crtc_state->no_vblank && !old_crtc_state->no_vblank)
> >
> > Uh, this essentially makes it impossible to reset no_vblank.
>
> I don't want ->no_vblank to be reset by the core. It's up to the CRTC
> driver to clear/set it when something changes in the pipeline.
>
> > For control
> > flow state bits we only check the new state for it (see e.g. the various
> > *_changed or plane_bits or whatever).
>
> I tried with !new_crtc_state->no_vblank only, but then it does not
> handle the case where the CRTC and connector are being disabled, and I
> end up with a timeout.
>
> >
> > > + continue;
> > > +
> > > + spin_lock_irqsave(&old_state->dev->event_lock, flags);
> > > + if (new_crtc_state->event) {
> > > + drm_crtc_send_vblank_event(crtc,
> > > +new_crtc_state->event);
> > > + new_crtc_state->event = NULL;
> > > + }
> > > + spin_unlock_irqrestore(&old_state->dev->event_lock, flags);
> > > + }
> > > +}
> > > +EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > > +
> > > /**
> > > * drm_atomic_helper_commit_hw_done - setup possible nonblocking commit
> > > * @old_state: atomic state object with old state structures
> > > diff --git a/include/drm/drm_atomic_helper.h
> > > b/include/drm/drm_atomic_helper.h
> > > index 26aaba58d6ce..99e2a5297c69 100644
> > > --- a/include/drm/drm_atomic_helper.h
> > > +++ b/include/drm/drm_atomic_helper.h
> > > @@ -100,6 +100,7 @@ int __must_check drm_atomic_helper_swap_state(struct
> > > drm_atomic_state *state,
> > > int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
> > > bool nonblock);
> > > void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state
> > > *state);
> > > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *state);
> > > void drm_atomic_helper_commi
Re: [PATCH v2 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
On Mon, 2 Jul 2018 10:40:54 +0200 Daniel Vetter wrote: > > > > > > > + * Note that, even when no_blank is set to true, the CRTC driver > > > > can still > > > > + * steal the &drm_crtc_state.event object and send the event on > > > > its own. > > > > + * That's usually what happens when a job is queued to the > > > > writeback > > > > + * connector. > > > > > > The last sentence is confusing imo. Just drop it? > > > > Yes, I know, but it's also important to state that the ->no_blank + > > event == NULL is a valid combination, and just means that the driver > > decided to generate the event (that happens when a new WB job is > > queued). > > Then make it more explicit, as-is I had no idea what you meant exactly. > What about Your suggestion is missing :P. > > > > > > > > Please use the inline comment style for struct members, and then also > > > polish the formatting a bit (e.g. paragraph breaks, which are only > > > possible with the inline style). > > > > I considered that, but the other fields were already documented in the > > single block above the struct, so I thought keeping things consistent > > was better. Should I just add this field doc inline and keep the other > > ones where they are, or should I add a patch moving all docs inline? > > There's _lots_ of inline comments already, and all new ones should be > inline. The only reason I haven't done the conversion to all of them is > that it would be a nice opportunity to update/clean up the comments > (often there's a lot more to say than what's captured in the single line), > which is why it didn't happen yet. Just moving the comments without > updating them seems less useful imo. > > I'd just do the inline comment for this, that's what everyone else is > doing too. Okay, will do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Plane transitional helper prototypes mismatch their methods
On Sun, Jul 01, 2018 at 04:34:02PM +0100, Russell King - ARM Linux wrote: > Ping. > > On Mon, Jun 25, 2018 at 04:52:16PM +0100, Russell King - ARM Linux wrote: > > Hi, > > > > Currently, the transitional plane helpers have prototypes that > > do not have the drm_modeset_acquire_ctx argument: > > > > int drm_plane_helper_update(struct drm_plane *plane, struct drm_crtc *crtc, > > struct drm_framebuffer *fb, > > int crtc_x, int crtc_y, > > unsigned int crtc_w, unsigned int crtc_h, > > uint32_t src_x, uint32_t src_y, > > uint32_t src_w, uint32_t src_h); > > int drm_plane_helper_disable(struct drm_plane *plane); > > > > However, the helper methods have this as the last argument: > > > > int (*update_plane)(struct drm_plane *plane, > > struct drm_crtc *crtc, struct drm_framebuffer > > *fb, > > int crtc_x, int crtc_y, > > unsigned int crtc_w, unsigned int crtc_h, > > uint32_t src_x, uint32_t src_y, > > uint32_t src_w, uint32_t src_h, > > struct drm_modeset_acquire_ctx *ctx); > > int (*disable_plane)(struct drm_plane *plane, > > struct drm_modeset_acquire_ctx *ctx); > > > > Are these transitional helpers supposed to be plugged into these > > methods directly? Looking back in the history, the following commit > > to i915 seems to suggest that they were designed to be plugged > > directly into these methods: > > > > commit ea2c67bb4affa84080c616920f3899f123786e56 > > Author: Matt Roper > > Date: Tue Dec 23 10:41:52 2014 -0800 > > > > drm/i915: Move to atomic plane helpers (v9) > > > > It seems easy to add this argument to drm_plane_helper_update() as > > it has no current users, but the drm_plane_helper_disable() > > transitional helper seems to be used extensively by what are > > otherwise fully atomic modeset drivers, despite being described as > > only a transitional helper. Yes, I forgotten to add the acquire_ctx to them to make them match up again. Upfront Acked-by: Daniel Vetter on the patch to re-add that. > > drivers/gpu/drm/arm/hdlcd_crtc.c: drm_plane_helper_disable(plane); > > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c: drm_plane_helper_disable(plane); > > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c: drm_plane_helper_disable(plane); > > drivers/gpu/drm/arc/arcpgu_crtc.c: drm_plane_helper_disable(plane); > > drivers/gpu/drm/sti/sti_hqvdp.c:drm_plane_helper_disable(drm_plane); > > drivers/gpu/drm/sti/sti_gdp.c: drm_plane_helper_disable(drm_plane); > > drivers/gpu/drm/sti/sti_cursor.c: drm_plane_helper_disable(drm_plane); > > drivers/gpu/drm/vc4/vc4_plane.c:drm_plane_helper_disable(plane); > > drivers/gpu/drm/zte/zx_plane.c: drm_plane_helper_disable(plane); > > > > Are these drivers buggy using the transitional helper, which won't do > > anything but change the state of that single plane, leaving the CRTC, > > encoders, bridges, etc all active? Yes that's all buggy usage. I've started sprinkling WARN_ON(drm_drv_uses_adomit_modeset) on such legacy functions, but drm_plane_helper_disable() is used a bit too much really. It's all the same cargo-cult though in the plane->destroy hook. What drivers should do instead is: - Shut down the hw before cleaning up their modeset objects using something like drm_atomic_helper_shutdown(). - Remove the drm_plane_helper_disable(). But for your patch to add the ctx argument everywhere I think just passing NULL is ok too. It's not going to make things worse :-) Since that patch needs to touch a bunch of drivers probably best if we get it landed through drm-misc-next. -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 04/15] dma-fence: Make ->wait callback optional
Am 02.07.2018 um 10:23 schrieb Daniel Vetter: On Fri, May 04, 2018 at 03:47:59PM +0200, Daniel Vetter wrote: On Fri, May 04, 2018 at 03:17:08PM +0200, Christian König wrote: Am 04.05.2018 um 11:25 schrieb Daniel Vetter: On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:57:59) On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:23:01) On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote: On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-03 15:25:52) Almost everyone uses dma_fence_default_wait. v2: Also remove the BUG_ON(!ops->wait) (Chris). I just don't get the rationale for implicit over explicit. Closer approximation of dwim semantics. There's been tons of patch series all over drm and related places to get there, once we have a big pile of implementations and know what the dwim semantics should be. Individually they're all not much, in aggregate they substantially simplify simple drivers. I also think clearer separation between optional optimization hooks and mandatory core parts is useful in itself. A new spelling of midlayer ;) I don't see the contradiction with a driver saying use the default and simplicity. (I know which one the compiler thinks is simpler ;) If the compiler overhead is real then I guess it would makes to be explicit. I don't expect that to be a problem though for a blocking function. I disagree on this being a midlayer - you can still overwrite everything you please to. What it does help is people doing less copypasting (and assorted bugs), at least in the grand scheme of things. And we do have a _lot_ more random small drivers than just a few years ago. Reducing the amount of explicit typing just to get default bahaviour has been an ongoing theme for a few years now, and your objection here is about the first that this is not a good idea. So I'm somewhat confused. I'm just saying I don't see any rationale for this patch. "Almost everyone uses dma_fence_default_wait." Why change? Making it look simpler on the surface, so that you don't have to think about things straight away? I understand the appeal, but I do worry about it just being an illusion. (Cutting and pasting a line saying .wait = default_wait, doesn't feel that onerous, as you likely cut and paste the ops anyway, and at the very least you are reminded about some of the interactions. You could even have default initializers and/or magic macros to hide the cut and paste; maybe a simple_dma_fence [now that's a midlayer!] but I haven't looked.) In really monolithic vtables like drm_driver we do use default function macros, so you type 1 line, get them all. But dma_fence_ops is pretty small, and most drivers only implement a few callbacks. Also note that e.g. the ->release callback already works like that, so this pattern is there already. I simply extended it to ->wait and ->enable_signaling. Also note that I leave the EXPORT_SYMBOL in place, you can still wrap dma_fence_default_wait if you wish to do so. But I just realized that I didn't clean out the optional release hooks, I guess I should do that too (for the few cases it's not yet done) and respin. I kind of agree with Chris here, but also see the practical problem to copy the default function in all the implementations. We had the same problem in TTM and I also don't really like the result to always have that "if (some_callback) default(); else some_callback();". Might be that the run time overhead is negligible, but it doesn't feels right from the coding style perspective. Hm, maybe I've seen too much bad code, but modeset helpers is choke full of exactly that pattern. It's imo also a trade-off. If you have a fairly specialized library like ttm that's used by relatively few things, doing everything explicitly is probably better. It's also where kms started out from. But if you have a huge pile of fairly simple drivers, imo the balance starts to tip the other way, and a bit of additional logic in the shared code to make all the implementations a notch simpler is good. If we wouldn't have acquired quite a pile of dma_fence implementations I wouldn't have bothered with all this. So ack/nack on this (i.e. do you retract your original r-b or not)? It's kinda holding up all the cleanup patches below ... Feel free to add my Acked-by for now, but I still have a kind of a gut feeling that we might want to revisit this decision at some time. Christian. I went ahead and applied the first three patches of this series meanwhile. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 10/24] drm/sun4i: tcon: Generalize engine search algorithm
On Sun, Jul 01, 2018 at 09:09:47PM +0200, Jernej Škrabec wrote:
> Dne petek, 29. junij 2018 ob 21:06:09 CEST je Jernej Škrabec napisal(a):
> > Dne četrtek, 28. junij 2018 ob 20:25:43 CEST je Maxime Ripard napisal(a):
> > > On Thu, Jun 28, 2018 at 06:48:50AM +0200, Jernej Škrabec wrote:
> > > > Dne četrtek, 28. junij 2018 ob 04:06:52 CEST je Chen-Yu Tsai napisal(a):
> > > > > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> > > > >
> > > >
> > > > wrote:
> > > > > > Current "old" method to find engine worked pretty well for DE2.
> > > > > > However,
> > > > > > it doesn't work when TCON TOP is between mixer (engine) and TCON.
> > > > > > TCON
> > > > > > TOP has multiple input ports, but current engine search algorithm
> > > > > > expects only one.
> > > > > >
> > > > > > This can be fixed by first looking for output port id and selecting
> > > > > > matching input by subtracting 1 for the next round. This work even
> > > > > > if
> > > > > > there is only one input and output.
> > > > > >
> > > > > > Signed-off-by: Jernej Skrabec
> > > > > > ---
> > > > > >
> > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++
> > > > > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > > > > > 08747fc3ee71..264bcc43da11
> > > > > > 100644
> > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > @@ -791,12 +791,14 @@ static int sun4i_tcon_init_regmap(struct
> > > > > > device
> > > > > > *dev,
> > > > > >
> > > > > > */
> > > > > >
> > > > > > static struct sunxi_engine *
> > > > > > sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
> > > > > >
> > > > > > - struct device_node *node)
> > > > > > + struct device_node *node,
> > > > > > + u32 port_id)
> > > > > >
> > > > > > {
> > > > > >
> > > > > > struct device_node *port, *ep, *remote;
> > > > > > struct sunxi_engine *engine = ERR_PTR(-EINVAL);
> > > > > >
> > > > > > + u32 reg = 0;
> > > > > >
> > > > > > - port = of_graph_get_port_by_id(node, 0);
> > > > > > + port = of_graph_get_port_by_id(node, port_id);
> > > > > >
> > > > > > if (!port)
> > > > > >
> > > > > > return ERR_PTR(-EINVAL);
> > > > > >
> > > > > > @@ -826,8 +828,20 @@ sun4i_tcon_find_engine_traverse(struct
> > > > > > sun4i_drv
> > > > > > *drv,
> > > > > >
> > > > > > if (remote == engine->node)
> > > > > >
> > > > > > goto out_put_remote;
> > > > > >
> > > > > > + /*
> > > > > > +* According to device tree binding input ports have even id
> > > > > > +* number and output ports have odd id. Since component with
> > > > > > +* more than one input and one output (TCON TOP) exits,
> > > > > > correct
> > > > > > +* remote input id has to be calculated by subtracting 1
> > > > > > from
> > > > > > +* remote output id. If this for some reason can't be done,
> > > > > > 0
> > > > > > +* is used as input port id.
> > > > > > +*/
> > > > >
> > > > > You need to call
> > > > >
> > > > > of_node_put(port);
> > > > >
> > > > > to drop the reference to the original port.
> > > >
> > > > Thanks for noticing it. I guess I should send fix patch, since patches
> > > > from
> > > > drm-misc-next can't be dropped.
> > >
> > > Yeah, please send additional patches for all the issues pointed out by
> > > Chen-Yu.
> >
> > Of course. I hope this can be resolved till the end of the next week. After
> > that, I will be away from PC for 2 weeks. Feel free to drop DT patches if
> > you think that it will come too close to merge window.
>
> Actually, can you drop it anyway? It needs a lot of changes and keeping HDMI
> working would need some effort.
No, we can't drop it, unfortunately.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] drm/crtc: Add a generic infrastructure to fake VBLANK events
On Mon, 2 Jul 2018 10:37:22 +0200
Daniel Vetter wrote:
> On Mon, Jul 02, 2018 at 10:14:51AM +0200, Boris Brezillon wrote:
> > On Mon, 2 Jul 2018 10:02:52 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> > > > In some cases CRTCs are active but are not able to generating events, at
> > > > least not at every frame at it's expected to.
> > > > This is typically the case when the CRTC is feeding a writeback
> > > > connector
> > > > that has no job queued. In this situation the CRTC is usually stopped
> > > > until a new job is queued, and this can lead to timeouts when part of
> > > > the pipeline is updated but no new jobs are queued to the active
> > > > writeback connector.
> > > >
> > > > In order to solve that, we add a ->no_vblank flag to drm_crtc_state
> > > > and ask the CRTC drivers to set it to true when they know they're not
> > > > able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
> > > > helper can then be used to fake VBLANKs at commit time.
> > > >
> > > > Signed-off-by: Boris Brezillon
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_helper.c | 40
> > > > +
> > > > include/drm/drm_atomic_helper.h | 1 +
> > > > include/drm/drm_crtc.h | 15 ++
> > > > 3 files changed, 56 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 69063bcf2334..ca586993c2a2 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -2051,6 +2051,46 @@ void
> > > > drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state
> > > > *old_state)
> > > > }
> > > > EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
> > > >
> > > > +/**
> > > > + * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
> > > > + * @old_state: atomic state object with old state structures
> > > > + *
> > > > + * This function walks all CRTCs and fake VBLANK events on those with
> > > > + * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event !=
> > > > NULL.
> > > > + * The primary use of this function is writeback connectors working in
> > > > oneshot
> > > > + * mode and faking VBLANK events. In this case they only fake the
> > > > VBLANK event
> > > > + * when a job is queued, and any change to the pipeline that does not
> > > > touch the
> > > > + * connector is leading to timeouts when calling
> > > > + * drm_atomic_helper_wait_for_vblanks() or
> > > > + * drm_atomic_helper_wait_for_flip_done().
> > > > + *
> > > > + * This is part of the atomic helper support for nonblocking commits,
> > > > see
> > > > + * drm_atomic_helper_setup_commit() for an overview.
> > > > + */
> > > > +void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
> > > > +{
> > > > + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > > + struct drm_crtc *crtc;
> > > > + int i;
> > > > +
> > > > + for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > > > + new_crtc_state, i) {
> > > > + unsigned long flags;
> > > > +
> > > > + if (!new_crtc_state->no_vblank &&
> > > > !old_crtc_state->no_vblank)
> > >
> > > Uh, this essentially makes it impossible to reset no_vblank.
> >
> > I don't want ->no_vblank to be reset by the core. It's up to the CRTC
> > driver to clear/set it when something changes in the pipeline.
> >
> > > For control
> > > flow state bits we only check the new state for it (see e.g. the various
> > > *_changed or plane_bits or whatever).
> >
> > I tried with !new_crtc_state->no_vblank only, but then it does not
> > handle the case where the CRTC and connector are being disabled, and I
> > end up with a timeout.
>
> Why that? You should have a new_crtc_state even when you disable the crtc,
> and you can set the ->no_vblank on that one too.
Hm, right. I'll have to check why I didn't have ->no_blank set to true
when I disable the CRTC. Probably a problem in vc4_crtc.c.
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/3] dt-bindings: display: dw_hdmi.txt: add cec-disable property
On 29/06/18 09:17, Neil Armstrong wrote: > Hi Hans, > > On 03/04/2018 10:27, Hans Verkuil wrote: >> On 27/03/18 00:25, Rob Herring wrote: >>> On Fri, Mar 23, 2018 at 01:59:13PM +0100, Hans Verkuil wrote: From: Hans Verkuil Some boards have both a DesignWare and their own CEC controller. The CEC pin is only hooked up to their own CEC controller and not to the DW controller. Add the cec-disable property to disable the DW CEC controller. This particular situation happens on Amlogic boards that have their own meson CEC controller. >>> >>> Seems like we could avoid this by describing how the CEC line is hooked >>> up which could be needed for other reasons. >> >> So there are three situations: >> >> 1) The cec pin is connected to the DW HDMI TX. That's already supported. >> 2) The cec pin is not connected at all, but the CEC IP is instantiated. >>We need the cec-disable property for that. This simply states that the >>CEC pin is not connected. >> 3) The cec pin is connected to an HDMI RX. We do not support this at the >>moment. If we want to support this, then we need a 'hdmi-rx' phandle >>that points to the HDMI receiver that the CEC pin is associated with. >>This will be similar to the already existing 'hdmi-phandle' property >>used to associate a CEC driver with an HDMI transmitter. In hindsight >>it would have been better if 'hdmi-phandle' was named 'hdmi-tx' :-( >> >> I can make a binding proposal for 3, but I have no hardware to test it, >> so I think it is better to add this only when someone has hardware. It >> will require quite a few changes to the driver and likely also the CEC core. > > Can't we simply add a property to override the HW config fields in this case ? > It will be then usable with any feature the is enabled by reading the config > bits like AHB Audio, I2c, CEC, ... and maybe many more in the future. Yes, we can do that as well. But is that a proper description of the hardware? The HW *does* support CEC, but in this case the CEC line is just not hooked up to anything. So overriding the HW config field doesn't really sound right to me. I still believe that the cec-disable property in order to describe situation 2 in the list above is the right approach. Perhaps giving it a different name (cec-not-connected?) helps overcome Rob's objections? Rob? Sorry for not following up on this earlier. Regards, Hans > > Neil > >> >> Regards, >> >> Hans >> >>> Signed-off-by: Hans Verkuil Acked-by: Neil Armstrong --- Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++ 1 file changed, 3 insertions(+) >> > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107084] WebGL shader freezes X server
https://bugs.freedesktop.org/show_bug.cgi?id=107084 Bug ID: 107084 Summary: WebGL shader freezes X server Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: network...@rkmail.ru QA Contact: dri-devel@lists.freedesktop.org A webgl page freezes entire desktop, with no way to gracefully recover. Just open this link in chromium (with webgl enabled): https://www.shadertoy.com/view/XstBzM RX480 + Mesa git + LLVM 7.0 + linux 4.17, but other users report same happens with stable software versions -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix hdmi connector content type property docs
Apparently didn't get carefully checked.
Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
Cc: Hans Verkuil
Cc: Daniel Vetter
Cc: Stanislav Lisovskiy
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 2 +-
drivers/gpu/drm/drm_connector.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 4f6f113a7f5d..514939433004 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -527,7 +527,7 @@ Standard Connector Properties
:doc: standard connector properties
HDMI Specific Connector Properties
--
+--
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: HDMI connector properties
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2f9ebddd178e..b09b3a3e4024 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1033,9 +1033,7 @@ EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
*
* Drivers can set up this property by calling
* drm_connector_attach_content_type_property(). Decoding to
- * infoframe values is done through
- * drm_hdmi_get_content_type_from_property() and
- * drm_hdmi_get_itc_bit_from_property().
+ * infoframe values is done through drm_hdmi_avi_infoframe_content_type().
*/
/**
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107084] WebGL shader freezes X server
https://bugs.freedesktop.org/show_bug.cgi?id=107084 network...@rkmail.ru changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. Thanks, Christian. --- From ec9a7241bf422b908532c4c33953b0da2655ad05 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Wed, 20 Jun 2018 15:03:20 +0200 Subject: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom victim with blockable mmu notifiers as done after a short sleep. That can result in selecting a new oom victim prematurely because the previous one still hasn't torn its memory down yet. We can do much better though. Even if mmu notifiers use sleepable locks there is no reason to automatically assume those locks are held. Moreover majority of notifiers only care about a portion of the address space and there is absolutely zero reason to fail when we are unmapping an unrelated range. Many notifiers do really block and wait for HW which is harder to handle and we have to bail out though. This patch handles the low hanging fruid. __mmu_notifier_invalidate_range_start gets a blockable flag and callbacks are not allowed to sleep if the flag is set to false. This is achieved by using trylock instead of the sleepable lock for most callbacks and continue as long as we do not block down the call chain. I think we can improve that even further because there is a common pattern to do a range lookup first and then do something about that. The first part can be done without a sleeping lock in most cases AFAICS. The oom_reaper end then simply retries if there is at least one notifier which couldn't make any progress in !blockable mode. A retry loop is already implemented to wait for the mmap_sem and this is basically the same thing. Changes since rfc v1 - gpu notifiers can sleep while waiting for HW (evict_process_queues_cpsch on a lock and amdgpu_mn_invalidate_node on unbound timeout) make sure we bail out when we have an intersecting range for starter - note that a notifier failed to the log for easier debugging - back off early in ib_umem_notifier_invalidate_range_start if the callback is called - mn_invl_range_start waits for completion down the unmap_grant_pages path so we have to back off early on overlapping ranges Cc: "David (ChunMing) Zhou" Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Mike Marciniszyn Cc: Dennis Dalessandro Cc: Sudeep Dutt Cc: Ashutosh Dixit Cc: Dimitri Sivanich Cc: Boris Ostrovsky Cc: Juergen Gross Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: Felix Kuehling Cc: k...@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)) Cc: linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)) Cc: amd-...@lists.freedesktop.org (open list:RADEON and AMDGPU DRM DRIVERS) Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS) Cc: intel-...@lists.freedesktop.org (open list:INTEL DRM DRIVERS (excluding Poulsbo, Moorestow...) Cc: linux-r...@vger.kernel.org (open list:INFINIBAND SUBSYSTEM) Cc: xen-de...@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE) Cc: linux...@kvack.org (open list:HMM - Heterogeneous Memory Management) Reported-by: David Rientjes Signed-off-by: Michal Hocko --- arch/x86/kvm/x86.c | 7 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 43 +++- drivers/gpu/drm/i915/i915_gem_userptr.c | 13 ++-- drivers/gpu/drm/radeon/radeon_mn.c | 22 +++-- drivers/infiniband/core/umem_odp.c | 33 +++ drivers/infiniband/hw/hfi1/mmu_rb.c | 11 --- drivers/infiniband/hw/mlx5/odp.c| 2 +- drivers/misc/mic/scif/scif_dma.c| 7 ++-- drivers/misc/sgi-gru/grutlbpurge.c | 7 ++-- drivers/xen/gntdev.c| 44 - include/linux/kvm_host.h| 4 +-- include/linux/mmu_notifier.h| 35 +++- include/linux/oom.h | 2 +- include/rdma/ib_umem_odp.h | 3 +-
Re: [amdgpu][tahiti xt] cursor motion smoothness
On 2018-07-01 02:52 PM, sylvain.bertr...@gmail.com wrote: > Hi, > > I noticed that when my monitor runs at 60Hz, the cursor motion is really not > smooth, even at low speed (it starts to be smooth at low speed when my monitor > runs at 120/144Hz). Is there a way to improve this at the hardware level or is > this a xserver issue? > (I run everything git no older than 1/2 week/s). If you have DC enabled, does disabling it (amdgpu.dc=0) help? -- Earthling Michel Dänzer | http://www.amd.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: [amdgpu][tahiti xt] cursor motion smoothness
On 2018-07-02 11:24 AM, Michel Dänzer wrote: > On 2018-07-01 02:52 PM, sylvain.bertr...@gmail.com wrote: >> Hi, >> >> I noticed that when my monitor runs at 60Hz, the cursor motion is really not >> smooth, even at low speed (it starts to be smooth at low speed when my >> monitor >> runs at 120/144Hz). Is there a way to improve this at the hardware level or >> is >> this a xserver issue? >> (I run everything git no older than 1/2 week/s). > > If you have DC enabled, does disabling it (amdgpu.dc=0) help? Never mind, I missed that it's about Tahiti, which DC doesn't support. Please share the corresponding Xorg log file. What exactly does "not smooth" mean? -- Earthling Michel Dänzer | http://www.amd.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 v2 2/8] drm/connector: Pass a drm_connector_state to ->atomic_commit()
On Mon, 2 Jul 2018 09:51:46 +0200
Daniel Vetter wrote:
> On Fri, Jun 29, 2018 at 12:37:10PM +0100, Liviu Dudau wrote:
> > On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> > > Other atomic hooks are passed state objects, let's change this one to
> > > be consistent.
> > >
> > > Signed-off-by: Boris Brezillon
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> > > include/drm/drm_modeset_helper_vtables.h | 4 +++-
> > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 17baf5057132..69063bcf2334 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -1187,7 +1187,7 @@ static void
> > > drm_atomic_helper_commit_writebacks(struct drm_device *dev,
> > >
> > > if (new_conn_state->writeback_job &&
> > > new_conn_state->writeback_job->fb) {
> > > WARN_ON(connector->connector_type !=
> > > DRM_MODE_CONNECTOR_WRITEBACK);
> > > - funcs->atomic_commit(connector,
> > > new_conn_state->writeback_job);
> > > + funcs->atomic_commit(connector, new_conn_state);
> >
> > Forgot to add: I think it is worth adding a check here that the hook has
> > been implemented by the driver, AFAIK it is not a mandatory hook, even
> > for writeback enabled drivers.
I'm just curious, from where do you queue the writeback job if you don't
have a connector->atomic_commit() hook implemented? AFAICT, the
encoder->enable() method is only called when the encoder is being
enabled, and not every time you update the FB_ID prop of the writeback
connector. Am I missing something?
>
> Either way this should be documented in the hook (atm it says nothing
> about whether it's mandatory/optional and for whom).
I'm fine making this hook optional. I'll update the code and the doc in
a separate commit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/i915: Filter out modes that don't match the fixed mode vrefresh
On Mon, Jul 02, 2018 at 09:46:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 28, 2018 at 10:43:01PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We only ever drive the panel with the fixed mode, hence we don't
> > want to advertize any modes that have a different vertical refresh rate.
> >
> > We tried to allow a second lower clocked mode to used for eDP but
> > that was reverted in commit d93fa1b47b8f ("Revert "drm/i915/edp:
> > Allow alternate fixed mode for eDP if available.""). To do that properly
> > I think we should probably just keep all (or just some?) of the probed
> > modes around (presumably all of them actually work if the panel
> > advertizes them), and we'd just pick the closest match based on the
> > user mode.
> >
> > For now we don't have any of that so we shouldn't lie to the user
> > that they can drive the panel at different refresh rate. Note that
> > we still don't reject any user mode with bad refresh rate. That's
> > going to be step two.
> >
> > TODO: Should we allow for a larger error margin?
> >
> > Signed-off-by: Ville Syrjälä
>
> Not sure the current vrefresh is any good, since it's HZ resolution only.
> That's not precise enough for the video aficionados, who insist on that
> entire 1001/1000 business.
>
> I did look around a bit with a quick git grep, and most places only use
> ->vrefresh for debug printing. Then there's a few that use it as an index
> (e.g. i915 DRRS code), and then there's the totally misguided code in
> adv7511 which thinks vrefresh is in kHz.
>
> There's also quite a pile of mode->vrefresh ? mode->vrefresh :
> drm_mode_vrefresh(mode) around, which really doesn't inspire confidence
> that we'll ever catch them all. It feels like those "recompute vrefresh"
> things have been cargo-culted for ages.
>
> I think we need to clean this up harder:
> - switch everyone over to drm_mode_vrefresh()
> - nuke drm_display_mode->vrefresh
> - add a new drm_mode_vrefresh_mHz (for milli-Hz, i.e. fixed point math
> ftw)
> - use that new function in the mode filtering, with a bit of fudge that
> keeps the 1001/1000 modes separate, but papers over rounding errors. I
> think we could even do a drm_mode_compare_vrefresh for that, we're
> probably not the only ones who'd like to have such a function.
>
> Probably a bit more work to type (but cocci might help here), definitely
> less painful to make sure it stays correct I think. Thoughts?
Yeah, would probably make sense. But apart from the "make sure this
don't break" angle it doesn't matter for this case unless we want
to make the filtering even more strict than the 1 Hz resolution.
>
> Cheers, Daniel
>
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 3 +++
> > drivers/gpu/drm/i915/intel_dsi.c | 2 ++
> > drivers/gpu/drm/i915/intel_dvo.c | 2 ++
> > drivers/gpu/drm/i915/intel_lvds.c | 2 ++
> > drivers/gpu/drm/i915/intel_sdvo.c | 2 ++
> > 5 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 5be07e1d816d..22feb0b144f6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -446,6 +446,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > if (mode->vdisplay > fixed_mode->vdisplay)
> > return MODE_PANEL;
> >
> > + if (mode->vrefresh != fixed_mode->vrefresh)
> > + return MODE_PANEL;
> > +
> > target_clock = fixed_mode->clock;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 3b7acb5a70b3..3d0758cec85a 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -1277,6 +1277,8 @@ intel_dsi_mode_valid(struct drm_connector *connector,
> > return MODE_PANEL;
> > if (mode->vdisplay > fixed_mode->vdisplay)
> > return MODE_PANEL;
> > + if (mode->vrefresh != fixed_mode->vrefresh)
> > + return MODE_PANEL;
> > if (fixed_mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_dvo.c
> > b/drivers/gpu/drm/i915/intel_dvo.c
> > index 4e142ff49708..078bb848a49a 100644
> > --- a/drivers/gpu/drm/i915/intel_dvo.c
> > +++ b/drivers/gpu/drm/i915/intel_dvo.c
> > @@ -225,6 +225,8 @@ intel_dvo_mode_valid(struct drm_connector *connector,
> > return MODE_PANEL;
> > if (mode->vdisplay > fixed_mode->vdisplay)
> > return MODE_PANEL;
> > + if (mode->vrefresh != fixed_mode->vrefresh)
> > + return MODE_PANEL;
> >
> > target_clock = fixed_mode->clock;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index bb06744d28a4..d312a8911b89 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/g
Re: [PATCH] drm: Fix hdmi connector content type property docs
On Mon, 2018-07-02 at 11:10 +0200, Daniel Vetter wrote:
> Apparently didn't get carefully checked.
>
> Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
> Cc: Hans Verkuil
> Cc: Daniel Vetter
> Cc: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 2 +-
> drivers/gpu/drm/drm_connector.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> kms.rst
> index 4f6f113a7f5d..514939433004 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -527,7 +527,7 @@ Standard Connector Properties
> :doc: standard connector properties
>
> HDMI Specific Connector Properties
> --
> +--
>
> .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: HDMI connector properties
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 2f9ebddd178e..b09b3a3e4024 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1033,9 +1033,7 @@
> EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
> *
> * Drivers can set up this property by calling
> * drm_connector_attach_content_type_property(). Decoding to
> - * infoframe values is done through
> - * drm_hdmi_get_content_type_from_property() and
> - * drm_hdmi_get_itc_bit_from_property().
> + * infoframe values is done through
> drm_hdmi_avi_infoframe_content_type().
> */
All right, thank you very much for spotting, there were so much
last
minute changes that I probably got confused.
Reviewed-by: Stanislav Lisovskiy
>
> /**
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #2 from Michel Dänzer (mic...@daenzer.net) --- Also, please attach the output of free and of top after pressing shift-M, both captured while RAM usage is high. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/8] drm/vc4: Add support for the transposer block
Hi Eric,
On Fri, 29 Jun 2018 13:35:04 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Boris Brezillon
> >
> > The transposer block is providing support for mem-to-mem composition,
> > which is exposed as a drm_writeback connector in DRM.
> >
> > Add a driver to support this feature.
> >
> > Signed-off-by: Boris Brezillon
>
> > +static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> > + struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> > + struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> > + bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
> > + bool debug_dump_regs = false;
> > +
> > + if (debug_dump_regs) {
> > + DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
> > + vc4_crtc_dump_regs(vc4_crtc);
> > + }
> > +
> > + if (vc4_crtc->channel == 2) {
> > + u32 dispctrl;
> > + u32 dsp3_mux;
> > +
> > + /*
> > +* SCALER_DISPCTRL_DSP3 = X, where X < 2 means 'connect DSP3 to
> > +* FIFO X'.
> > +* SCALER_DISPCTRL_DSP3 = 3 means 'disable DSP 3'.
> > +*
> > +* DSP3 is connected to FIFO2 unless the transposer is
> > +* enabled. In this case, FIFO 2 is directly accessed by the
> > +* TXP IP, and we need to prevent disable the
>
> s/prevent //
>
> > +* FIFO2 -> pixelvalve1 route.
> > +*/
> > + if (vc4_state->feed_txp)
> > + dsp3_mux = VC4_SET_FIELD(3, SCALER_DISPCTRL_DSP3_MUX);
> > + else
> > + dsp3_mux = VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX);
> > +
> > + /* Reconfigure the DSP3 mux if required. */
> > + dispctrl = HVS_READ(SCALER_DISPCTRL);
> > + if ((dispctrl & SCALER_DISPCTRL_DSP3_MUX_MASK) != dsp3_mux) {
> > + dispctrl &= ~SCALER_DISPCTRL_DSP3_MUX_MASK;
> > + HVS_WRITE(SCALER_DISPCTRL, dispctrl | dsp3_mux);
> > + }
>
> This is fine, but you could also skip the matching mux check here -- the
> read is the expensive part.
>
> > + }
> > +
> > + if (!vc4_state->feed_txp)
> > + vc4_crtc_config_pv(crtc);
> >
> > HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
> > SCALER_DISPBKGND_AUTOHS |
> > @@ -499,6 +539,13 @@ static void vc4_crtc_atomic_disable(struct drm_crtc
> > *crtc,
> > }
> > }
> >
> > +void vc4_crtc_txp_armed(struct drm_crtc_state *state)
> > +{
> > + struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(state);
> > +
> > + vc4_state->txp_armed = true;
> > +}
> > +
> > static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->dev;
> > @@ -514,8 +561,11 @@ static void vc4_crtc_update_dlist(struct drm_crtc
> > *crtc)
> > WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> >
> > spin_lock_irqsave(&dev->event_lock, flags);
> > - vc4_crtc->event = crtc->state->event;
> > - crtc->state->event = NULL;
> > +
> > + if (!vc4_state->feed_txp || vc4_state->txp_armed) {
> > + vc4_crtc->event = crtc->state->event;
> > + crtc->state->event = NULL;
> > + }
> >
> > HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> > vc4_state->mm.start);
> > @@ -533,8 +583,8 @@ static void vc4_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> > struct drm_device *dev = crtc->dev;
> > struct vc4_dev *vc4 = to_vc4_dev(dev);
> > struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> > - struct drm_crtc_state *state = crtc->state;
> > - struct drm_display_mode *mode = &state->adjusted_mode;
> > + struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> > + struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> >
> > require_hvs_enabled(dev);
> >
> > @@ -546,15 +596,21 @@ static void vc4_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> >
> > /* Turn on the scaler, which will wait for vstart to start
> > * compositing.
> > +* When feeding the transposer, we should operate in oneshot
> > +* mode.
> > */
> > HVS_WRITE(SCALER_DISPCTRLX(vc4_crtc->channel),
> > VC4_SET_FIELD(mode->hdisplay, SCALER_DISPCTRLX_WIDTH) |
> > VC4_SET_FIELD(mode->vdisplay, SCALER_DISPCTRLX_HEIGHT) |
> > - SCALER_DISPCTRLX_ENABLE);
> > + SCALER_DISPCTRLX_ENABLE |
> > + (vc4_state->feed_txp ? SCALER_DISPCTRLX_ONESHOT : 0));
> >
> > - /* Turn on the pixel valve, which will emit the vstart signal. */
> > - CRTC_WRITE(PV_V_CONTROL,
> > - CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
> > + /* When feeding the composer block the pixelvalve is unneeded and
>
> "transposer block"
Re: [PATCH v2 0/8] drm/vc4: Add support for the transposer IP
On Fri, 29 Jun 2018 12:40:45 +0100 Liviu Dudau wrote: > On Fri, Jun 29, 2018 at 01:17:22PM +0200, Boris Brezillon wrote: > > Hello, > > > > This is the second version of this series adding writeback support > > to the VC4 display engine. > > > > This version is based on drm-misc-next and include a bunch of > > modifications to core that I had to add to make it work on VC4. > > > > Feel free to comment on those modifications. > > > > On the driver side, no much has changed except I modified a bit > > the implementation to adjust the latest revision of the writeback > > interface. > > This is a duplicate of the cover letter. Yep, I forgot to clean the directory I used to generate my patches :-/ > > I've reviewed / checked patches 1-5 and 8, so you can add my Reviewed-by > tag from me if you want. Thanks for your review. Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Limite blob creation to drm master
On Mon, Jul 02, 2018 at 10:12:21AM +0200, Daniel Vetter wrote:
> This interface allows pretty much unlimited kernel memory allocations,
> which isn't all that great. But we allow that anyway for any drm
> master client (through pinning display buffers and stuff, at least for
> UMA gpus),
At least on i915 memory used by pinned display buffers has some kind
of upper bound based on the number of planes+max fb size and/or ggtt
size.
Anyways, patch makes sense so
Reviewed-by: Ville Syrjälä
> so just limiting it to the active master seems like a
> reasonable stopgap measure.
>
> Fixes: e2f5d2ea479b ("drm/mode: Add user blob-creation ioctl")
> Cc: Daniel Stone
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index c148eb3be8c2..dc740c381f9e 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -656,8 +656,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
> drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_UNLOCKED),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR2, drm_mode_cursor2_ioctl,
> DRM_MASTER|DRM_UNLOCKED),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl,
> DRM_MASTER|DRM_UNLOCKED),
> - DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
> drm_mode_destroyblob_ioctl, DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
> DRM_MASTER|DRM_UNLOCKED),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
> drm_mode_destroyblob_ioctl, DRM_MASTER|DRM_UNLOCKED),
>
> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_CREATE, drm_syncobj_create_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/4] drm/panel: p079zca: refactor panel driver to support multiple panels
From: huang lin
Refactor Innolux P079ZCA panel driver, let it support
multi panels from Innolux that share similar power sequences.
Panels may require different power supplies so use regulator bulk
interfaces and define per panel supply-names.
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel,
support P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry
Changes in v5:
- use regulator_bulk to handle different supply number
Signed-off-by: Lin Huang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 143 --
1 file changed, 100 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index bb53e0850764..840ad4a6a6a6 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,12 +20,29 @@
#include
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size;
+
+ unsigned long flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+ const char * const *supply_names;
+ unsigned int num_supplies;
+};
+
struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
struct backlight_device *backlight;
- struct regulator *supply;
+ struct regulator_bulk_data *supplies;
+ unsigned int num_supplies;
struct gpio_desc *enable_gpio;
bool prepared;
@@ -77,9 +94,7 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
/* T8: 80ms - 1000ms */
msleep(80);
- err = regulator_disable(innolux->supply);
- if (err < 0)
- return err;
+ regulator_bulk_disable(innolux->desc->num_supplies, innolux->supplies);
innolux->prepared = false;
@@ -89,14 +104,15 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
static int innolux_panel_prepare(struct drm_panel *panel)
{
struct innolux_panel *innolux = to_innolux_panel(panel);
- int err, regulator_err;
+ int err;
if (innolux->prepared)
return 0;
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
- err = regulator_enable(innolux->supply);
+ err = regulator_bulk_enable(innolux->desc->num_supplies,
+ innolux->supplies);
if (err < 0)
return err;
@@ -133,12 +149,9 @@ static int innolux_panel_prepare(struct drm_panel *panel)
return 0;
poweroff:
- regulator_err = regulator_disable(innolux->supply);
- if (regulator_err)
- DRM_DEV_ERROR(panel->dev, "failed to disable regulator: %d\n",
- regulator_err);
-
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+ regulator_bulk_disable(innolux->desc->num_supplies, innolux->supplies);
+
return err;
}
@@ -162,7 +175,11 @@ static int innolux_panel_enable(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const char * const innolux_p079zca_supply_names[] = {
+ "power",
+};
+
+static const struct drm_display_mode innolux_p079zca_mode = {
.clock = 56900,
.hdisplay = 768,
.hsync_start = 768 + 40,
@@ -175,15 +192,31 @@ static const struct drm_display_mode default_mode = {
.vrefresh = 60,
};
+static const struct panel_desc innolux_p079zca_panel_desc = {
+ .modes = &innolux_p079zca_mode,
+ .bpc = 8,
+ .size = {
+ .width = 120,
+ .height = 160,
+ },
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+ .lanes = 4,
+ .supply_names = innolux_p079zca_supply_names,
+ .num_supplies = ARRAY_SIZE(innolux_p079zca_supply_names),
+};
+
static int innolux_panel_get_modes(struct drm_panel *panel)
{
struct drm_display_mode *mode;
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ const struct drm_display_mode *m = innolux->desc->modes;
- mode = drm_mode_duplicate(panel->drm, &default_mode);
+ mode = drm_mode_duplicate(panel->drm, m);
if (!mode) {
DRM_DEV_ERROR(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ m->hdisplay, m->vdisplay, m->vrefresh);
return -ENOMEM;
}
@@ -191,9 +224,11 @@ static int innolux_panel_get_modes(struct drm_panel *panel)
[PATCH v5 3/4] dt-bindings: Add Innolux P097PFG panel bindings
From: huang lin
The Innolux P097PFG panel is 9.7" panel with 1536X2048
resolution, it reuse P079ZCA panel driver, so improve
p079ZCA dt-binding to support P097PFG.
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- use separate file for binding
- keep power supplies as required
Signed-off-by: Lin Huang
Signed-off-by: Heiko Stuebner
---
.../display/panel/innolux,p097pfg.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
new file mode 100644
index ..595d9dfeffd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
@@ -0,0 +1,24 @@
+Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p097pfg"
+- reg: DSI virtual channel of the peripheral
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ &mipi_dsi {
+ panel {
+ compatible = "innolux,p079zca";
+ reg = <0>;
+ avdd-supply = <...>;
+ avee-supply = <...>;
+ backlight = <&backlight>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/4] drm/panel: p079zca: support Innolux P097PFG panel
From: Lin Huang
Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
the Innolux P079ZCA panel driver.
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- Document source of init-commands
- 4 lanes per DSI interface
Signed-off-by: Lin Huang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 200 +-
1 file changed, 196 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 630b0c2549ef..8d25b87bfbd6 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -20,6 +20,15 @@
#include
+struct panel_init_cmd {
+ int len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
struct panel_desc {
const struct drm_display_mode *modes;
unsigned int bpc;
@@ -30,6 +39,7 @@ struct panel_desc {
unsigned long flags;
enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
unsigned int lanes;
const char * const *supply_names;
unsigned int num_supplies;
@@ -121,13 +131,43 @@ static int innolux_panel_prepare(struct drm_panel *panel)
if (err < 0)
return err;
- /* T2: 15ms - 1000ms */
- usleep_range(15000, 16000);
+ /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
+ usleep_range(2, 21000);
gpiod_set_value_cansleep(innolux->enable_gpio, 1);
- /* T4: 15ms - 1000ms */
- usleep_range(15000, 16000);
+ /* p079zca: t4, p097pfg: t5 */
+ usleep_range(2, 21000);
+
+ if (innolux->desc->init_cmds) {
+ const struct panel_init_cmd *cmds =
+ innolux->desc->init_cmds;
+ int i;
+
+ for (i = 0; cmds[i].len != 0; i++) {
+ const struct panel_init_cmd *cmd = &cmds[i];
+
+ err = mipi_dsi_generic_write(innolux->link, cmd->data,
+cmd->len);
+ if (err < 0) {
+ dev_err(panel->dev,
+ "failed to write command %d\n", i);
+ goto poweroff;
+ }
+
+ /*
+* Included by random guessing, because without this
+* (or at least, some delay), the panel sometimes
+* didn't appear to pick up the command sequence.
+*/
+ err = mipi_dsi_dcs_nop(innolux->link);
+ if (err < 0) {
+ dev_err(panel->dev,
+ "failed to send DCS nop: %d\n", err);
+ goto poweroff;
+ }
+ }
+ }
err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
if (err < 0) {
@@ -213,6 +253,155 @@ static const struct panel_desc innolux_p079zca_panel_desc
= {
.power_down_delay = 80, /* T8: 80ms - 1000ms */
};
+static const char * const innolux_p097pfg_supply_names[] = {
+ "avdd",
+ "avee",
+};
+
+static const struct drm_display_mode innolux_p097pfg_mode = {
+ .clock = 229000,
+ .hdisplay = 1536,
+ .hsync_start = 1536 + 100,
+ .hsync_end = 1536 + 100 + 24,
+ .htotal = 1536 + 100 + 24 + 100,
+ .vdisplay = 2048,
+ .vsync_start = 2048 + 100,
+ .vsync_end = 2048 + 100 + 2,
+ .vtotal = 2048 + 100 + 2 + 18,
+ .vrefresh = 60,
+};
+
+/*
+ * Display manufacturer failed to provide init sequencing according to
+ *
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/892065/
+ * so the init sequence stems from a register dump of a working panel.
+ */
+static const struct panel_init_cmd innolux_p097pfg_init_cmds[] = {
+ /* page 0 */
+ _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x00),
+ _INIT_CMD(0xB1, 0xE8, 0x11),
+ _INIT_CMD(0xB2, 0x25, 0x02),
+ _INIT_CMD(0xB5, 0x08, 0x00),
+ _INIT_CMD(0xBC, 0x0F, 0x00),
+ _INIT_CMD(0xB8, 0x03, 0x06, 0x00, 0x00),
+ _INIT_CMD(0xBD, 0x01, 0x90, 0x14, 0x14),
+ _INIT_CMD(0x6F, 0x01),
+ _INIT_CMD(0xC0, 0x03),
+ _INIT_CMD(0x6F, 0x02),
+ _INIT_CMD(0xC1, 0x0D),
+ _INIT_CMD(0xD9, 0x01, 0x09, 0x70),
+ _INIT_CMD(0xC5, 0x12, 0x21, 0x00),
+ _INIT_CMD(0xBB, 0x93, 0x93),
+
+ /* page 1 */
+ _INIT_CMD(0xF0, 0x55, 0xAA, 0x52, 0x08, 0x01),
+ _INIT_CMD(0xB3, 0x3C, 0x3C),
+ _INIT_CMD(0xB4, 0x0F, 0x0F),
+ _INIT_CMD(0xB9, 0x45, 0x45),
+ _INIT_CMD(0xBA, 0x14, 0x14),
+ _INIT_CMD(0xCA, 0x02),
+ _INIT_CMD(0xCE, 0x04),
+ _INIT_CMD(0xC3
[PATCH v5 0/4] Innolux P097PFG panel
The Innolux p097pfg is one of two possible panels used in the gru-scarlet ChromeOS devices. This v5 mainly addresses the very valuable comments from Emil regarding power-supply and delay handling as well as documenting the (unsatisfying) source of the init commands. Individual changelogs inside the specific patches. Tested with the recently resurrected Rockchip dual-dsi patches on a gru-scarlet. Lin Huang (2): drm/panel: p079zca: add variable unprepare_delay properties drm/panel: p079zca: support Innolux P097PFG panel huang lin (2): drm/panel: p079zca: refactor panel driver to support multiple panels dt-bindings: Add Innolux P097PFG panel bindings .../display/panel/innolux,p097pfg.txt | 24 ++ drivers/gpu/drm/panel/panel-innolux-p079zca.c | 353 +++--- 2 files changed, 328 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/4] drm/panel: p079zca: add variable unprepare_delay properties
From: Lin Huang
When panel power down, p079zca need delay between reset and disable
power supply, but p097pfg does not need it. Similarly p097zca needs
a delay after entering panel sleep mode. So add two delay properties,
so we can meet these two panel power down sequence.
Signed-off-by: Lin Huang
[add sleep-mode delay]
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 840ad4a6a6a6..630b0c2549ef 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -33,6 +33,8 @@ struct panel_desc {
unsigned int lanes;
const char * const *supply_names;
unsigned int num_supplies;
+ unsigned int sleep_mode_delay;
+ unsigned int power_down_delay;
};
struct innolux_panel {
@@ -89,10 +91,13 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
return err;
}
+ if (innolux->desc->sleep_mode_delay)
+ msleep(innolux->desc->sleep_mode_delay);
+
gpiod_set_value_cansleep(innolux->enable_gpio, 0);
- /* T8: 80ms - 1000ms */
- msleep(80);
+ if (innolux->desc->power_down_delay)
+ msleep(innolux->desc->power_down_delay);
regulator_bulk_disable(innolux->desc->num_supplies, innolux->supplies);
@@ -205,6 +210,7 @@ static const struct panel_desc innolux_p079zca_panel_desc =
{
.lanes = 4,
.supply_names = innolux_p079zca_supply_names,
.num_supplies = ARRAY_SIZE(innolux_p079zca_supply_names),
+ .power_down_delay = 80, /* T8: 80ms - 1000ms */
};
static int innolux_panel_get_modes(struct drm_panel *panel)
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/panel: add Kingdisplay kd097d04 panel driver
From: Nickey Yang
Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
it is a MIPI dual-DSI panel.
v2:
- update timing + cmds from chromeos kernel
- new backlight API including switch to devm_of_find_backlight
- fix most of Sean Paul's comments
enable/prepare tracking seems something all panels do
- document origins of the init sequence
- lanes per dsi interface to 4 (two interfaces). Matches how tegra
and pending rockchip dual-dsi handle (dual-)dsi lanes
- spdx header instead of license boilerplate
Signed-off-by: Nickey Yang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-kingdisplay-kd097d04.c| 469 ++
3 files changed, 481 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff3449a..9a0061f7fed7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,17 @@ config DRM_PANEL_JDI_LT070ME05000
The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
24 bit per pixel.
+config DRM_PANEL_KINGDISPLAY_KD097D04
+ tristate "Kingdisplay kd097d04 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Kingdisplay kd097d04
+ TFT-LCD modules. The panel has a 1536x2048 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc11d746..314b272f1e14 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
new file mode 100644
index ..9fc6b06fffee
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
@@ -0,0 +1,469 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct kingdisplay_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct backlight_device *backlight;
+ struct regulator *supply;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+struct kingdisplay_panel_cmd {
+ char cmd;
+ char data;
+};
+
+/*
+ * According to the discussion on
+ * https://review.coreboot.org/#/c/coreboot/+/22472/
+ * the panel init array is not part of the panels datasheet but instead
+ * just came in this form from the panel vendor.
+ */
+static const struct kingdisplay_panel_cmd init_code[] = {
+ /* voltage setting */
+ { 0xB0, 0x00 },
+ { 0xB2, 0x02 },
+ { 0xB3, 0x11 },
+ { 0xB4, 0x00 },
+ { 0xB6, 0x80 },
+ /* VCOM disable */
+ { 0xB7, 0x02 },
+ { 0xB8, 0x80 },
+ { 0xBA, 0x43 },
+ /* VCOM setting */
+ { 0xBB, 0x53 },
+ /* VSP setting */
+ { 0xBC, 0x0A },
+ /* VSN setting */
+ { 0xBD, 0x4A },
+ /* VGH setting */
+ { 0xBE, 0x2F },
+ /* VGL setting */
+ { 0xBF, 0x1A },
+ { 0xF0, 0x39 },
+ { 0xF1, 0x22 },
+ /* Gamma setting */
+ { 0xB0, 0x02 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x01 },
+ { 0xC2, 0x0B },
+ { 0xC3, 0x15 },
+ { 0xC4, 0x22 },
+ { 0xC5, 0x11 },
+ { 0xC6, 0x15 },
+ { 0xC7, 0x19 },
+ { 0xC8, 0x1A },
+ { 0xC9, 0x16 },
+ { 0xCA, 0x18 },
+ { 0xCB, 0x13 },
+ { 0xCC, 0x18 },
+ { 0xCD, 0x13 },
+ { 0xCE, 0x1C },
+ { 0xCF, 0x19 },
+ { 0xD0, 0x21 },
+ { 0xD1, 0x2C },
+ { 0xD2, 0x2F },
+ { 0xD3, 0x30 },
+ { 0xD4, 0x19 },
+ { 0xD5, 0x1F },
+ { 0xD6, 0x00 },
+ { 0xD7, 0x01 },
+ { 0xD8, 0x0B },
+ { 0xD9, 0x15 },
+ { 0xDA, 0x22 },
+ { 0xDB, 0x11 },
+ { 0xDC, 0x15 },
+ { 0xDD, 0x19 },
+ { 0xDE, 0x1A },
+
[PATCH v2 1/3] dt-bindings: Add vendor prefix for kingdisplay
From: Nickey Yang Kingdisplay Technology Co., Ltd, established in China Shenzhen in 2006, is a national high-tech enterprise specializing in the R&D, manufacturing and marketing of TFT-LCM and touch panel. Signed-off-by: Nickey Yang Acked-by: Rob Herring Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 7cad066191ee..5a379c462e07 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -188,6 +188,7 @@ keymile Keymile GmbH khadas Khadas kiebackpeterKieback & Peter GmbH kinetic Kinetic Technologies +kingdisplayKing & Display Technology Co., Ltd. kingnovel Kingnovel Technology Co., Ltd. koeKaohsiung Opto-Electronics Inc. kosagi Sutajio Ko-Usagi PTE Ltd. -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: Add KINGDISPLAY KD097D04 panel bindings
From: Nickey Yang
The KINGDISPLAY KD097D04 is a 9.7" panel with a 1536x2048
resolution and connected to DSI using 8 lanes.
Signed-off-by: Nickey Yang
Acked-by: Rob Herring
Signed-off-by: Heiko Stuebner
---
.../display/panel/kingdisplay,kd097d04.txt| 22 +++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
new file mode 100644
index ..164a5fa236da
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
@@ -0,0 +1,22 @@
+Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
+
+Required properties:
+- compatible: should be "kingdisplay,kd097d04"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ &mipi_dsi {
+ panel {
+ compatible = "kingdisplay,kd097d04";
+ reg = <0>;
+ power-supply = <...>;
+ backlight = <&backlight>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] Kingdisplay-kd097d04-panel
The Innolux p097pfg is one of two possible panels used in the gru-scarlet ChromeOS devices. This v2 updates the driver with changes from the ChromeOS side and tries to address most of the comments received from Sean Paul. Nickey Yang (3): dt-bindings: Add vendor prefix for kingdisplay dt-bindings: Add KINGDISPLAY KD097D04 panel bindings drm/panel: add Kingdisplay kd097d04 panel driver .../display/panel/kingdisplay,kd097d04.txt| 22 + .../devicetree/bindings/vendor-prefixes.txt | 1 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + .../drm/panel/panel-kingdisplay-kd097d04.c| 469 ++ 5 files changed, 504 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #3 from phoenix (fe...@feldspaten.org) --- Yeah, I'll post the mentioned things today after I got home. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107065] "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921
https://bugs.freedesktop.org/show_bug.cgi?id=107065 --- Comment #11 from Christian König --- (In reply to Andrey Grodzovsky from comment #10) > Created attachment 140418 [details] [review] > drm/amdgpu: Verify root PD is mapped into kernel address space. > > dwagner, please try this patch. Fixes the issue for me and I observed no > suspend/resume issues. > > Christian, please take a look at the patch, problem was that in > amdgpu_vm_update_directories the parent BO didn't have a kernel mapping and > so later inside amdgpu_vm_cpu_set_ptes > pe += (unsigned long)amdgpu_bo_kptr(bo); would equal to 2000 > since > parent amdgpu_bo_kptr woudld return NULL. The parent was the root PD. > > This was still working in 67b8d5c Linus Torvalds 7 weeks agoLinux > 4.17-rc5 (tag: v4.17-rc5) but I wasn't able to exactly pinpoint which > change broke it. I am not sure my fix is the right one so please advise. No idea when that broke either, CPU based updates is not something we usually test. Anyway it's a good catch, but I would rather add that to amdgpu_vm_bo_base_init() (with the appropriate checks). That would also allow us to remove the duplicated code from amdgpu_vm_alloc_levels(). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/10] drm: crc: Introduce get_crc_sources callback
This patch introduce a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
Changes Since V1: (Daniel)
- return const pointer to an array of crc sources list
- do validation of sources in CRC-core
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
include/drm/drm_crtc.h| 16
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index c6a725b79ac6..f4d76528d24c 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -67,9 +67,27 @@
static int crc_control_show(struct seq_file *m, void *data)
{
struct drm_crtc *crtc = m->private;
+ size_t count;
+
+ if (crtc->funcs->get_crc_sources) {
+ const char *const *sources = crtc->funcs->get_crc_sources(crtc,
+ &count);
+ size_t values_cnt;
+ int i;
+
+ if (count <= 0 || !sources)
+ goto out;
+
+ seq_puts(m, "[");
+ for (i = 0; i < count; i++)
+ if (!crtc->funcs->verify_crc_source(crtc, sources[i],
+ &values_cnt))
+ seq_printf(m, "%s ", sources[i]);
+ seq_puts(m, "] ");
+ }
+out:
seq_printf(m, "%s\n", crtc->crc.source);
-
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a6dcbf91744..ffaec138aeee 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,22 @@ struct drm_crtc_funcs {
*/
int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @get_crc_sources:
+*
+* Driver callback for getting a list of all the available sources for
+* CRC generation.
+*
+* This callback is optional if the driver does not support exporting of
+* possible CRC sources list. CRC-core does the verification of sources.
+*
+* RETURNS:
+*
+* a constant character pointer to the list of all the available CRC
+* sources
+*/
+ const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
+ size_t *count);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] drm/rockchip/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Changes since V1:
- simplify the verification (Jani N)
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index effecbed2d11..77e91b15ddb4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1138,12 +1138,31 @@ static int vop_crtc_set_crc_source(struct drm_crtc
*crtc,
return ret;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ if (source_name && strcmp(source_name, "auto") != 0)
+ return -EINVAL;
+
+ *values_cnt = 3;
+ return 0;
+}
+
#else
static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name, size_t *values_cnt)
{
return -ENODEV;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ return -ENODEV;
+}
#endif
static const struct drm_crtc_funcs vop_crtc_funcs = {
@@ -1156,6 +1175,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
.set_crc_source = vop_crtc_set_crc_source,
+ .verify_crc_source = vop_crtc_verify_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 66bd3cc3e387..dd97cbca0527 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2563,6 +2563,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs =
{
.atomic_duplicate_state = dm_crtc_duplicate_state,
.atomic_destroy_state = dm_crtc_destroy_state,
.set_crc_source = amdgpu_dm_crtc_set_crc_source,
+ .verify_crc_source = amdgpu_dm_crtc_verify_crc_source,
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index a29dc35954c9..e43ed064dc46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
#ifdef CONFIG_DEBUG_FS
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt);
+int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *src_name,
+size_t *values_cnt);
void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc);
#else
#define amdgpu_dm_crtc_set_crc_source NULL
+#define amdgpu_dm_crtc_verify_crc_source NULL
#define amdgpu_dm_crtc_handle_crc_irq(x)
#endif
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 52f2c01349e3..dfcca594d52a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source
dm_parse_crc_source(const char *source)
return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID;
}
+int
+amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name,
+size_t *values_cnt)
+{
+ enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name);
+
+ if (source < 0) {
+ DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n",
+src_name, crtc->index);
+ return -EINVAL;
+ }
+
+ *values_cnt = 3;
+ return 0;
+}
+
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt)
{
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/i915/crc: implement verify_crc_source callback
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 108 ++
3 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 56818a45181c..977ee4c7ef7b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12893,6 +12893,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
+ .verify_crc_source = intel_crtc_verify_crc_source,
};
struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6ff2600a3a0..764b53dfe7de 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2156,10 +2156,13 @@ int intel_pipe_crc_create(struct drm_minor *minor);
#ifdef CONFIG_DEBUG_FS
int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
size_t *values_cnt);
+int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *source_name, size_t *values_cnt);
void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
#else
#define intel_crtc_set_crc_source NULL
+#define intel_crtc_verify_crc_source NULL
static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
{
}
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 39a4e4edda07..a37521380f94 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -913,6 +913,114 @@ int intel_pipe_crc_create(struct drm_minor *minor)
return 0;
}
+static int i8xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int i9xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_TV:
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ case INTEL_PIPE_CRC_SOURCE_DP_D:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int vlv_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ case INTEL_PIPE_CRC_SOURCE_DP_D:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ilk_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ivb_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ case INTEL_PIPE_CRC_SOURCE_PF:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int
+intel_is_valid_crc_source(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ if (IS_GEN2(dev_priv))
+ return i8xx_crc_source_valid(dev_priv, source);
+ else if (INTEL_GEN(dev_priv) < 5)
+ return i9xx_crc_source_valid(dev_priv, source);
+ else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ return vlv_crc_source_valid(dev_priv, source);
+ else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
+ return ilk_crc_source_valid(dev_priv, source);
+ else
+ return ivb_crc_source_valid(d
[PATCH 07/10] drm/i915/crc: implement get_crc_sources callback
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Changes since V1:
- Return array of crc sources
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pipe_crc.c | 7 +++
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 977ee4c7ef7b..6918c5127473 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12894,6 +12894,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
.verify_crc_source = intel_crtc_verify_crc_source,
+ .get_crc_sources = intel_crtc_get_crc_sources,
};
struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 764b53dfe7de..99e3b6477d39 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2158,11 +2158,14 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name,
size_t *values_cnt);
int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *source_name, size_t *values_cnt);
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count);
void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
#else
#define intel_crtc_set_crc_source NULL
#define intel_crtc_verify_crc_source NULL
+#define intel_crtc_get_crc_sources NULL
static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
{
}
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index a37521380f94..1dffc346f1bc 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -1001,6 +1001,13 @@ intel_is_valid_crc_source(struct drm_i915_private
*dev_priv,
return ivb_crc_source_valid(dev_priv, source);
}
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count)
+{
+ *count = ARRAY_SIZE(pipe_crc_sources);
+ return pipe_crc_sources;
+}
+
int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char
*source_name,
size_t *values_cnt)
{
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] drm: crc: Introduce pre_crc_read function
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_debugfs_crc.c | 8
include/drm/drm_crtc.h| 14 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index add35b77165b..7aeed89f934a 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -272,6 +272,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
__user *user_buf,
return 0;
}
+ if (crtc->funcs->pre_crc_read) {
+ ret = crtc->funcs->pre_crc_read(crtc);
+ if (ret) {
+ spin_unlock_irq(&crc->lock);
+ return ret;
+ }
+ }
+
/* Nothing to read? */
while (crtc_crc_data_count(crc) == 0) {
if (filep->f_flags & O_NONBLOCK) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 81780325f36f..7e2eab9c2f52 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -691,6 +691,20 @@ struct drm_crtc_funcs {
*/
const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
size_t *count);
+ /**
+* @pre_crc_read:
+*
+* Driver callback for performing any preparation work required by
+* driver before reading CRC
+*
+* This callback is optional if the driver does not support CRC
+* generation or no prework is required before reading the crc
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*pre_crc_read)(struct drm_crtc *crtc);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] drm/rcar-du/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15dc9caa128b..24eeaa7e14d7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -756,6 +756,45 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc
*crtc)
rcrtc->vblank_enable = false;
}
+static int rcar_du_crtc_verify_crc_source(struct drm_crtc *crtc,
+ const char *source_name,
+ size_t *values_cnt)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ unsigned int index = 0;
+ unsigned int i;
+ int ret;
+
+ /*
+* Parse the source name. Supported values are "plane%u" to compute the
+* CRC on an input plane (%u is the plane ID), and "auto" to compute the
+* CRC on the composer (VSP) output.
+*/
+ if (!source_name || !strcmp(source_name, "auto")) {
+ goto out;
+ } else if (strstarts(source_name, "plane")) {
+ ret = kstrtouint(source_name + strlen("plane"), 10, &index);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
+ if (index == rcrtc->vsp->planes[i].plane.base.id) {
+ index = i;
+ break;
+ }
+ }
+
+ if (i >= rcrtc->vsp->num_planes)
+ return -EINVAL;
+ } else {
+ return -EINVAL;
+ }
+
+out:
+ *values_cnt = 1;
+ return 0;
+}
+
static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name,
size_t *values_cnt)
@@ -861,6 +900,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.enable_vblank = rcar_du_crtc_enable_vblank,
.disable_vblank = rcar_du_crtc_disable_vblank,
.set_crc_source = rcar_du_crtc_set_crc_source,
+ .verify_crc_source = rcar_du_crtc_verify_crc_source,
};
/*
-
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] Revert "drm: crc: Wait for a frame before returning from open()"
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. Don't wait for first CRC during crtc_crc_open. It avoids one frame wait during open. If application want to wait after read call, it can use poll/read blocking read() call. Suggested-by: Ville Syrjälä Signed-off-by: Mahesh Kumar Cc: dri-devel@lists.freedesktop.org Cc: Tomeu Vizoso --- drivers/gpu/drm/drm_debugfs_crc.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 739a813b4b09..add35b77165b 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -226,24 +226,8 @@ static int crtc_crc_open(struct inode *inode, struct file *filep) if (ret) goto err; - spin_lock_irq(&crc->lock); - /* -* Only return once we got a first frame, so userspace doesn't have to -* guess when this particular piece of HW will be ready to start -* generating CRCs. -*/ - ret = wait_event_interruptible_lock_irq(crc->wq, - crtc_crc_data_count(crc), - crc->lock); - spin_unlock_irq(&crc->lock); - - if (ret) - goto err_disable; - return 0; -err_disable: - crtc->funcs->set_crc_source(crtc, NULL); err: spin_lock_irq(&crc->lock); crtc_crc_cleanup(crc); -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] drm/crc: Cleanup crtc_crc_open function
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4 +-
drivers/gpu/drm/drm_debugfs_crc.c | 52 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pipe_crc.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +--
include/drm/drm_crtc.h | 3 +-
8 files changed, 30 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index e43ed064dc46..54056d180003 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -258,8 +258,7 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
/* amdgpu_dm_crc.c */
#ifdef CONFIG_DEBUG_FS
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt);
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *src_name,
size_t *values_cnt);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index dfcca594d52a..e7ad528f5853 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -62,8 +62,7 @@ amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const
char *src_name,
return 0;
}
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt)
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
struct dm_crtc_state *crtc_state = to_dm_crtc_state(crtc->state);
struct dc_stream_state *stream_state = crtc_state->stream;
@@ -99,7 +98,6 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc,
const char *src_name,
return -EINVAL;
}
- *values_cnt = 3;
/* Reset crc_skipped on dm state */
crtc_state->crc_skip_count = 0;
return 0;
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index f4d76528d24c..739a813b4b09 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -124,11 +124,9 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
+ if (ret)
+ return ret;
spin_lock_irq(&crc->lock);
@@ -193,12 +191,15 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
return ret;
}
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, crc->source,
-&values_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source, &values_cnt);
+ if (ret)
+ return ret;
+
+ if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
+ return -EINVAL;
+
+ if (WARN_ON(values_cnt == 0))
+ return -EINVAL;
spin_lock_irq(&crc->lock);
if (!crc->opened)
@@ -210,30 +211,22 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
if (ret)
return ret;
- ret = crtc->funcs->set_crc_source(crtc, crc->source, &values_cnt);
- if (ret)
- goto err;
-
- if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
- if (WARN_ON(values_cnt == 0)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
if (!entries) {
ret = -ENOMEM;
- goto err_disable;
+ goto err;
}
spin_lock_irq(&crc->lock);
[PATCH 01/10] drm: crc: Introduce verify_crc_source callback
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
include/drm/drm_crtc.h| 15 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 9f8312137cad..c6a725b79ac6 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
struct drm_crtc *crtc = m->private;
struct drm_crtc_crc *crc = &crtc->crc;
char *source;
+ size_t values_cnt;
+ int ret = 0;
if (len == 0)
return 0;
@@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(&crc->lock);
if (crc->opened) {
@@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
return ret;
}
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source,
+&values_cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(&crc->lock);
if (!crc->opened)
crc->opened = true;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 23eddbccab10..1a6dcbf91744 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -661,6 +661,21 @@ struct drm_crtc_funcs {
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @verify_crc_source:
+*
+* verifies the source of CRC checksums of frames before setting the
+* source for CRC and during crc open.
+*
+* This callback is optional if the driver does not support any CRC
+* generation functionality.
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
+size_t *values_cnt);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] Improve crc-core driver interface
This series improves crc-core <-> driver interface. This series adds following functionality in the crc-core - Now control node will print all the available sources if implemented by driver along with current source. - Setting of sorce will fail if provided source is not supported - cleanup of crtc_crc_open function first allocate memory before enabling CRC generation - Don't block open() call instead wait in crc read call. Following IGT will fail due to crc-core <-> driver interface change igt@kms_pipe_crc_basic@bad-source ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence In nonblocking crc tests we'll get lesser crc's due to skipping crc AMD/Rockchip/rcar code path is not validated and need inputs Changes: - Add dri-devel in Cc Changes rev2: - now get_crc_sources returns a constant pointer to an array of source list and crc-core does the verification Changes rev3: - reorg patches to push non r-b patches to the last - add r-b tag Cc: dri-devel@lists.freedesktop.org Mahesh Kumar (10): drm: crc: Introduce verify_crc_source callback drm: crc: Introduce get_crc_sources callback drm/rockchip/crc: Implement verify_crc_source callback drm/amdgpu_dm/crc: Implement verify_crc_source callback drm/rcar-du/crc: Implement verify_crc_source callback drm/i915/crc: implement verify_crc_source callback drm/i915/crc: implement get_crc_sources callback drm/crc: Cleanup crtc_crc_open function Revert "drm: crc: Wait for a frame before returning from open()" drm: crc: Introduce pre_crc_read function drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +++- drivers/gpu/drm/drm_debugfs_crc.c | 79 -- drivers/gpu/drm/i915/intel_display.c | 2 + drivers/gpu/drm/i915/intel_drv.h | 9 +- drivers/gpu/drm/i915/intel_pipe_crc.c | 119 - drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 45 +++- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 26 - include/drm/drm_crtc.h | 48 - 10 files changed, 305 insertions(+), 51 deletions(-) -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107084] WebGL shader freezes X server
https://bugs.freedesktop.org/show_bug.cgi?id=107084 --- Comment #1 from Dieter Nützel --- I can second this with RX580 + Mesa git + LLVM 7.0 git + amd-staging-drm-next The gfx fans spin up (big load on it) but no logs so far. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/connector: Pass a drm_connector_state to ->atomic_commit()
On Mon, Jul 02, 2018 at 11:49:11AM +0200, Boris Brezillon wrote:
> On Mon, 2 Jul 2018 09:51:46 +0200
> Daniel Vetter wrote:
>
> > On Fri, Jun 29, 2018 at 12:37:10PM +0100, Liviu Dudau wrote:
> > > On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> > > > Other atomic hooks are passed state objects, let's change this one to
> > > > be consistent.
> > > >
> > > > Signed-off-by: Boris Brezillon
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> > > > include/drm/drm_modeset_helper_vtables.h | 4 +++-
> > > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 17baf5057132..69063bcf2334 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -1187,7 +1187,7 @@ static void
> > > > drm_atomic_helper_commit_writebacks(struct drm_device *dev,
> > > >
> > > > if (new_conn_state->writeback_job &&
> > > > new_conn_state->writeback_job->fb) {
> > > > WARN_ON(connector->connector_type !=
> > > > DRM_MODE_CONNECTOR_WRITEBACK);
> > > > - funcs->atomic_commit(connector,
> > > > new_conn_state->writeback_job);
> > > > + funcs->atomic_commit(connector,
> > > > new_conn_state);
> > >
> > > Forgot to add: I think it is worth adding a check here that the hook has
> > > been implemented by the driver, AFAIK it is not a mandatory hook, even
> > > for writeback enabled drivers.
>
> I'm just curious, from where do you queue the writeback job if you don't
> have a connector->atomic_commit() hook implemented? AFAICT, the
> encoder->enable() method is only called when the encoder is being
> enabled, and not every time you update the FB_ID prop of the writeback
> connector. Am I missing something?
In malidp_drv.c:malidp_atomic_commit_tail() we call
malidp_mw_atomic_commit() after drm_atomic_helper_commit_planes(drm,
state, DRM_PLANE_COMMIT_ACTIVE_ONLY).
malidp_mw_atomic_commit() then checks the writeback job and if it has an
fb associated with it then it calls drm_writeback_queue_job() before
enabling the memwrite hardware bits.
You can see it all in action here:
https://github.com/ARM-software/linux/commit/f7a88ca52530958703bcfc30adc302841ac89989
Best regards,
Liviu
>
> >
> > Either way this should be documented in the hook (atm it says nothing
> > about whether it's mandatory/optional and for whom).
>
> I'm fine making this hook optional. I'll update the code and the doc in
> a separate commit.
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size
Bartlomiej,
Now that the fbcon deferred console takeover patches have been
merged I believe this series can be merged too ?
Note the first patch has an ack from Ard for merging the
1 line efi change through the fbdev tree.
Regards,
Hans
On 18-06-18 17:13, Hans de Goede wrote:
bgrt_image_size is necessary to (optionally) show the boot graphics from
the efifb code. The efifb driver is a platform driver, using a normal
driver probe() driver callback. So even though it is always builtin it
cannot reference __initdata.
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/efi-bgrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
index 50793fda7819..b22ccfb0c991 100644
--- a/drivers/firmware/efi/efi-bgrt.c
+++ b/drivers/firmware/efi/efi-bgrt.c
@@ -20,7 +20,7 @@
#include
struct acpi_table_bgrt bgrt_tab;
-size_t __initdata bgrt_image_size;
+size_t bgrt_image_size;
struct bmp_header {
u16 id;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
On Wed, May 30, 2018 at 04:06:24PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Instead of setting the DMA ops pointer to NULL, set the correct,
> non-IOMMU ops depending on the device's coherency setting.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v4:
> - new patch to fix existing arm_iommu_detach_device() to do what we need
>
> arch/arm/mm/dma-mapping.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Christoph, Russell,
could either of you provide an Acked-by for this? I think it makes the
most sense for Ben to pick this up into the Nouveau tree along with
patch 2/2.
Thierry
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index af27f1c22d93..87a0037574e4 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask)
> return __dma_supported(dev, mask, false);
> }
>
> +static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> +{
> + return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> +}
> +
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
>
> static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long
> attrs)
> @@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev)
> iommu_detach_device(mapping->domain, dev);
> kref_put(&mapping->kref, release_iommu_mapping);
> to_dma_iommu_mapping(dev) = NULL;
> - set_dma_ops(dev, NULL);
> + set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
>
> pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
> }
> @@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device
> *dev) { }
>
> #endif /* CONFIG_ARM_DMA_USE_IOMMU */
>
> -static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> -{
> - return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> -}
> -
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
> --
> 2.17.0
>
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 11:14:58, Christian König wrote: > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no idea how. > > > > Any further feedback is highly appreciated of course. > > That sounds like it should work and at least the amdgpu changes now look > good to me on first glance. > > Can you split that up further in the usual way? E.g. adding the blockable > flag in one patch and fixing all implementations of the MMU notifier in > follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. > This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd > changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size
On Monday, July 02, 2018 01:46:09 PM Ard Biesheuvel wrote:
> On 2 July 2018 at 13:26, Hans de Goede wrote:
> > Bartlomiej,
> >
> > Now that the fbcon deferred console takeover patches have been
> > merged I believe this series can be merged too ?
> >
> > Note the first patch has an ack from Ard for merging the
> > 1 line efi change through the fbdev tree.
> >
>
> ... or I could take everything through the efi tree instead, as
> already discussed between Bartlomiej and me in the context of another
> patch series that touches both the fbdev and efi trees.
>
> Bartlomiej, that would require your ack on patch
>
> [PATCH v2 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
>
> https://marc.info/?l=linux-fbdev&m=152933484616993&w=2
>
> so if you're ok with that, I will queue both of these for v4.19
I would really prefer to merge this patchset through fbdev tree
as efi tree doesn't have fbcon deferred console takeover patches
(which are required by efifb changes under discussion).
> > On 18-06-18 17:13, Hans de Goede wrote:
> >>
> >> bgrt_image_size is necessary to (optionally) show the boot graphics from
> >> the efifb code. The efifb driver is a platform driver, using a normal
> >> driver probe() driver callback. So even though it is always builtin it
> >> cannot reference __initdata.
> >>
> >> Acked-by: Ard Biesheuvel
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/firmware/efi/efi-bgrt.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/firmware/efi/efi-bgrt.c
> >> b/drivers/firmware/efi/efi-bgrt.c
> >> index 50793fda7819..b22ccfb0c991 100644
> >> --- a/drivers/firmware/efi/efi-bgrt.c
> >> +++ b/drivers/firmware/efi/efi-bgrt.c
> >> @@ -20,7 +20,7 @@
> >> #include
> >> struct acpi_table_bgrt bgrt_tab;
> >> -size_t __initdata bgrt_image_size;
> >> +size_t bgrt_image_size;
> >> struct bmp_header {
> >> u16 id;
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/connector: Pass a drm_connector_state to ->atomic_commit()
On Mon, 2 Jul 2018 12:14:20 +0100
Liviu Dudau wrote:
> On Mon, Jul 02, 2018 at 11:49:11AM +0200, Boris Brezillon wrote:
> > On Mon, 2 Jul 2018 09:51:46 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, Jun 29, 2018 at 12:37:10PM +0100, Liviu Dudau wrote:
> > > > On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> > > > > Other atomic hooks are passed state objects, let's change this one to
> > > > > be consistent.
> > > > >
> > > > > Signed-off-by: Boris Brezillon
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> > > > > include/drm/drm_modeset_helper_vtables.h | 4 +++-
> > > > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 17baf5057132..69063bcf2334 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -1187,7 +1187,7 @@ static void
> > > > > drm_atomic_helper_commit_writebacks(struct drm_device *dev,
> > > > >
> > > > > if (new_conn_state->writeback_job &&
> > > > > new_conn_state->writeback_job->fb) {
> > > > > WARN_ON(connector->connector_type !=
> > > > > DRM_MODE_CONNECTOR_WRITEBACK);
> > > > > - funcs->atomic_commit(connector,
> > > > > new_conn_state->writeback_job);
> > > > > + funcs->atomic_commit(connector,
> > > > > new_conn_state);
> > > >
> > > > Forgot to add: I think it is worth adding a check here that the hook has
> > > > been implemented by the driver, AFAIK it is not a mandatory hook, even
> > > > for writeback enabled drivers.
> >
> > I'm just curious, from where do you queue the writeback job if you don't
> > have a connector->atomic_commit() hook implemented? AFAICT, the
> > encoder->enable() method is only called when the encoder is being
> > enabled, and not every time you update the FB_ID prop of the writeback
> > connector. Am I missing something?
>
> In malidp_drv.c:malidp_atomic_commit_tail() we call
> malidp_mw_atomic_commit() after drm_atomic_helper_commit_planes(drm,
> state, DRM_PLANE_COMMIT_ACTIVE_ONLY).
>
> malidp_mw_atomic_commit() then checks the writeback job and if it has an
> fb associated with it then it calls drm_writeback_queue_job() before
> enabling the memwrite hardware bits.
Okay. That's a good reason to make it optional.
Thanks,
Boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107084] WebGL shader freezes X server
https://bugs.freedesktop.org/show_bug.cgi?id=107084 --- Comment #2 from Dieter Nützel --- (In reply to Dieter Nützel from comment #1) > I can second this with > > RX580 + Mesa git + LLVM 7.0 git + amd-staging-drm-next > > The gfx fans spin up (big load on it) but no logs so far. Ups, browser... Konqueror Version 5.0.97 KDE Plasma Version 5.13.1 KDE Frameworks 5.47.0 Qt 5.11.1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/i915/crc: implement verify_crc_source callback
Op 02-07-18 om 13:07 schreef Mahesh Kumar: > This patch implements verify_crc_source callback function introduced > earlier in this series. > > Signed-off-by: Mahesh Kumar > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Maarten Lankhorst > --- Patch 6 and 7 were acked for inclusion through drm-misc by Jani: https://people.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&highlight_names=&date=2018-07-02 But we still need ack from the other maintainers to get this patch merged. :) Could you ping a few maintainers? ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] drm/atomic: Avoid connector to writeback_connector casts
Use container_of() instead of type casting so that it keeps working
even if base is moved inside the drm_writeback_connector struct.
Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Reviewed-by: Daniel Vetter
---
Changes in v3:
- Add Daniel's and Liviu's R-b
---
drivers/gpu/drm/drm_atomic.c | 4 +++-
include/drm/drm_writeback.h | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 178842380f75..6ea20d5dee66 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2423,6 +2423,7 @@ static int prepare_signaling(struct drm_device *dev,
}
for_each_new_connector_in_state(state, conn, conn_state, i) {
+ struct drm_writeback_connector *wb_conn;
struct drm_writeback_job *job;
struct drm_out_fence_state *f;
struct dma_fence *fence;
@@ -2446,7 +2447,8 @@ static int prepare_signaling(struct drm_device *dev,
f[*num_fences].out_fence_ptr = fence_ptr;
*fence_state = f;
- fence = drm_writeback_get_out_fence((struct
drm_writeback_connector *)conn);
+ wb_conn = drm_connector_to_writeback(conn);
+ fence = drm_writeback_get_out_fence(wb_conn);
if (!fence)
return -ENOMEM;
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index a10fe556dfd4..23df9d463003 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -110,6 +110,12 @@ struct drm_writeback_job {
struct dma_fence *out_fence;
};
+static inline struct drm_writeback_connector *
+drm_connector_to_writeback(struct drm_connector *connector)
+{
+ return container_of(connector, struct drm_writeback_connector, base);
+}
+
int drm_writeback_connector_init(struct drm_device *dev,
struct drm_writeback_connector *wb_connector,
const struct drm_connector_funcs *con_funcs,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] drm/vc4: Add support for the transposer IP
Hello, This is the third version of this series adding writeback support to the VC4 display engine. This version is based on drm-misc-next and include a bunch of modifications to the core that I had to add to make it work on VC4. Not much has changed in this v3, just a few minor fixes/cleanup/rework and the addition of one patch to make commit->atomic_commit() optional. See the changelog in each patch you want more details. Regards, Boris Boris Brezillon (9): drm/atomic: Avoid connector to writeback_connector casts drm/connector: Pass a drm_connector_state to ->atomic_commit() drm/connector: Make ->atomic_commit() optional drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks() drm/crtc: Add a generic infrastructure to fake VBLANK events drm/atomic: Call fake_vblank() from the generic commit_tail() helpers drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path drm/vc4: Add support for the transposer block ARM: dts: bcm283x: Add Transposer block .../devicetree/bindings/display/brcm,bcm-vc4.txt | 6 + arch/arm/boot/dts/bcm283x.dtsi | 6 + drivers/gpu/drm/drm_atomic.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c| 47 +- drivers/gpu/drm/vc4/Makefile | 1 + drivers/gpu/drm/vc4/vc4_crtc.c | 138 -- drivers/gpu/drm/vc4/vc4_debugfs.c | 1 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 7 + drivers/gpu/drm/vc4/vc4_kms.c | 11 +- drivers/gpu/drm/vc4/vc4_txp.c | 477 + include/drm/drm_atomic_helper.h| 1 + include/drm/drm_crtc.h | 23 + include/drm/drm_modeset_helper_vtables.h | 6 +- include/drm/drm_writeback.h| 6 + 15 files changed, 699 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/vc4/vc4_txp.c -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:13:42, Christian König wrote: > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > This is the v2 of RFC based on the feedback I've received so far. The > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > > > because I have no idea how. > > > > > > > > Any further feedback is highly appreciated of course. > > > That sounds like it should work and at least the amdgpu changes now look > > > good to me on first glance. > > > > > > Can you split that up further in the usual way? E.g. adding the blockable > > > flag in one patch and fixing all implementations of the MMU notifier in > > > follow up patches. > > But such a code would be broken, no? Ignoring the blockable state will > > simply lead to lockups until the fixup parts get applied. > > Well to still be bisect-able you only need to get the interface change in > first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. > Then add all the new code to the implementations and last start to actually > use the new interface. > > That is a pattern we use regularly and I think it's good practice to do > this. But we do rely on the proper blockable handling. > > Is the split up really worth it? I was thinking about that but had hard > > times to end up with something that would be bisectable. Well, except > > for returning -EBUSY until all notifiers are implemented. Which I found > > confusing. > > It at least makes reviewing changes much easier, cause as driver maintainer > I can concentrate on the stuff only related to me. > > Additional to that when you cause some unrelated side effect in a driver we > can much easier pinpoint the actual change later on when the patch is > smaller. > > > > > > This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd > > > changes. > > If you are worried to give r-b only for those then this can be done even > > for larger patches. Just make your Reviewd-by more specific > > R-b: name # For BLA BLA > > Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/connector: Pass a drm_connector_state to ->atomic_commit()
Other atomic hooks are passed state objects, let's change this one to
be consistent.
Signed-off-by: Boris Brezillon
Acked-by: Liviu Dudau
Reviewed-by: Daniel Vetter
---
Changes in v3:
- Add Liviu's A-b and Daniel's R-b
Changes in v2:
- New patch
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
include/drm/drm_modeset_helper_vtables.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 17baf5057132..69063bcf2334 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1187,7 +1187,7 @@ static void drm_atomic_helper_commit_writebacks(struct
drm_device *dev,
if (new_conn_state->writeback_job &&
new_conn_state->writeback_job->fb) {
WARN_ON(connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
- funcs->atomic_commit(connector,
new_conn_state->writeback_job);
+ funcs->atomic_commit(connector, new_conn_state);
}
}
}
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 3b289773297c..fb841f44949c 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -980,11 +980,13 @@ struct drm_connector_helper_funcs {
*
* This hook is to be used by drivers implementing writeback connectors
* that need a point when to commit the writeback job to the hardware.
+* The writeback_job to commit is available in
+* &drm_connector_state.writeback_job.
*
* This callback is used by the atomic modeset helpers.
*/
void (*atomic_commit)(struct drm_connector *connector,
- struct drm_writeback_job *writeback_job);
+ struct drm_connector_state *state);
};
/**
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/connector: Make ->atomic_commit() optional
Not all writeback connector implementations might want to commit things
from the connector driver. Some, like the malidp driver, commit things
from their main commit_tail() function, and would rather not have to
implement a dummy hook for drm_connector_helper_funcs.atomic_commit().
Make this function optional and reflect this fact in the doc.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- New patch
---
drivers/gpu/drm/drm_atomic_helper.c | 2 ++
include/drm/drm_modeset_helper_vtables.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 69063bcf2334..ea19fcc252dc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1184,6 +1184,8 @@ static void drm_atomic_helper_commit_writebacks(struct
drm_device *dev,
const struct drm_connector_helper_funcs *funcs;
funcs = connector->helper_private;
+ if (!funcs->funcs->atomic_commit)
+ continue;
if (new_conn_state->writeback_job &&
new_conn_state->writeback_job->fb) {
WARN_ON(connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index fb841f44949c..d0eb76c4b309 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -983,6 +983,8 @@ struct drm_connector_helper_funcs {
* The writeback_job to commit is available in
* &drm_connector_state.writeback_job.
*
+* This hook is optional.
+*
* This callback is used by the atomic modeset helpers.
*/
void (*atomic_commit)(struct drm_connector *connector,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] drm/atomic: Call fake_vblank() from the generic commit_tail() helpers
Now that we have a way to fake VBLANK events when requested by the CRTC hook it up to the generic commit_tail() helpers. Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Daniel Vetter --- Changes in v3: - Add R-b tags Changes in v2: - New patch --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index fc5a4ad1e3b3..ce2ebcd13cf2 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1450,6 +1450,8 @@ void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state) drm_atomic_helper_commit_modeset_enables(dev, old_state); + drm_atomic_helper_fake_vblank(old_state); + drm_atomic_helper_commit_hw_done(old_state); drm_atomic_helper_wait_for_vblanks(dev, old_state); @@ -1479,6 +1481,8 @@ void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state) drm_atomic_helper_commit_planes(dev, old_state, DRM_PLANE_COMMIT_ACTIVE_ONLY); + drm_atomic_helper_fake_vblank(old_state); + drm_atomic_helper_commit_hw_done(old_state); drm_atomic_helper_wait_for_vblanks(dev, old_state); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/9] drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path
Mimic what is done in drm_atomic_commit_tail() and call drm_atomic_helper_fake_vblank() so that VBLANK events are faked when the drm_crtc_state.no_vblank is true. Will be needed when we'll add support for the transposer block. Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt --- Changes in v3: - Add Eric's R-b Changes in v2: - New patch --- drivers/gpu/drm/vc4/vc4_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 91239b0a4fa0..ca5aa7fba769 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -153,6 +153,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state) drm_atomic_helper_commit_modeset_enables(dev, state); + drm_atomic_helper_fake_vblank(state); + drm_atomic_helper_commit_hw_done(state); drm_atomic_helper_wait_for_flip_done(dev, state); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] drm/crtc: Add a generic infrastructure to fake VBLANK events
In some cases CRTCs are active but are not able to generating events, at
least not at every frame at it's expected to.
This is typically the case when the CRTC is feeding a writeback connector
that has no job queued. In this situation the CRTC is usually stopped
until a new job is queued, and this can lead to timeouts when part of
the pipeline is updated but no new jobs are queued to the active
writeback connector.
In order to solve that, we add a ->no_vblank flag to drm_crtc_state
and ask the CRTC drivers to set it to true when they know they're not
able to generate VBLANK events. The core drm_atomic_helper_fake_vblank()
helper can then be used to fake VBLANKs at commit time.
Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Reviewed-by: Daniel Vetter
---
Changes in v3:
- Use inline doc for @no_vblank
- Fix drm_atomic_helper_fake_vblank() to only check
new_crtc_state->no_vblank
- Add R-b tags
Changes in v2:
- New patch
---
drivers/gpu/drm/drm_atomic_helper.c | 39 +
include/drm/drm_atomic_helper.h | 1 +
include/drm/drm_crtc.h | 23 ++
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ea19fcc252dc..fc5a4ad1e3b3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2053,6 +2053,45 @@ void drm_atomic_helper_wait_for_dependencies(struct
drm_atomic_state *old_state)
}
EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
+/**
+ * drm_atomic_helper_fake_vblank - fake VBLANK events if needed
+ * @old_state: atomic state object with old state structures
+ *
+ * This function walks all CRTCs and fake VBLANK events on those with
+ * &drm_crtc_state.no_vblank set to true and &drm_crtc_state.event != NULL.
+ * The primary use of this function is writeback connectors working in oneshot
+ * mode and faking VBLANK events. In this case they only fake the VBLANK event
+ * when a job is queued, and any change to the pipeline that does not touch the
+ * connector is leading to timeouts when calling
+ * drm_atomic_helper_wait_for_vblanks() or
+ * drm_atomic_helper_wait_for_flip_done().
+ *
+ * This is part of the atomic helper support for nonblocking commits, see
+ * drm_atomic_helper_setup_commit() for an overview.
+ */
+void drm_atomic_helper_fake_vblank(struct drm_atomic_state *old_state)
+{
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_crtc *crtc;
+ int i;
+
+ for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
+ unsigned long flags;
+
+ if (!new_crtc_state->no_vblank)
+ continue;
+
+ spin_lock_irqsave(&old_state->dev->event_lock, flags);
+ if (new_crtc_state->event) {
+ drm_crtc_send_vblank_event(crtc,
+ new_crtc_state->event);
+ new_crtc_state->event = NULL;
+ }
+ spin_unlock_irqrestore(&old_state->dev->event_lock, flags);
+ }
+}
+EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
+
/**
* drm_atomic_helper_commit_hw_done - setup possible nonblocking commit
* @old_state: atomic state object with old state structures
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 26aaba58d6ce..99e2a5297c69 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -100,6 +100,7 @@ int __must_check drm_atomic_helper_swap_state(struct
drm_atomic_state *state,
int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
bool nonblock);
void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state *state);
+void drm_atomic_helper_fake_vblank(struct drm_atomic_state *state);
void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *state);
void drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 23eddbccab10..17f4f93340b8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -119,6 +119,29 @@ struct drm_crtc_state {
bool zpos_changed : 1;
bool color_mgmt_changed : 1;
+ /**
+* @no_vblank:
+*
+* Reflects the ability of a CRTC to send VBLANK events. This state
+* usually depends on the pipeline configuration, and the main usuage
+* is CRTCs feeding a writeback connector operating in oneshot mode.
+* In this case the VBLANK event is only generated when a job is queued
+* to the writeback connector, and we want the core to fake VBLANK
+* events when this part of the pipeline hasn't changed but others had
+* or when the CRTC and connectors are being disabled.
+*
+* __drm_atomic_helper_crtc_duplicate_state() will not reset the value
+* from the current
[PATCH v3 4/9] drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()
drm_atomic_helper_wait_for_vblanks() assumes the CRTC will continuously generate VBLANK events and the vblank counter will keep increasing. While this work for a regular pipeline, it doesn't when you have the CRTC is feeding the transposer block, because this block works in oneshot mode, and, by the time we reach drm_atomic_helper_wait_for_vblanks() the only VBLANK event might have already been sent and the VBLANK counter will stay unchanged, thus triggering a timeout. Luckily, we can replace the drm_atomic_helper_wait_for_vblanks() call by drm_atomic_helper_wait_for_flip_done() because the only thing we want to check when calling drm_atomic_helper_wait_for_vblanks() from vc4_atomic_complete_commit() is that new FBs are in use and the old ones can be safely released. Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Eric Anholt --- Changes in v3: - Add Eric's and Liviu's R-b Changes in v2: - None --- drivers/gpu/drm/vc4/vc4_kms.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 8a411e5f8776..91239b0a4fa0 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -153,18 +153,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state) drm_atomic_helper_commit_modeset_enables(dev, state); - /* Make sure that drm_atomic_helper_wait_for_vblanks() -* actually waits for vblank. If we're doing a full atomic -* modeset (as opposed to a vc4_update_plane() short circuit), -* then we need to wait for scanout to be done with our -* display lists before we free it and potentially reallocate -* and overwrite the dlist memory with a new modeset. -*/ - state->legacy_cursor_update = false; - drm_atomic_helper_commit_hw_done(state); - drm_atomic_helper_wait_for_vblanks(dev, state); + drm_atomic_helper_wait_for_flip_done(dev, state); drm_atomic_helper_cleanup_planes(dev, state); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] drm/vc4: Add support for the transposer block
From: Boris Brezillon
The transposer block is providing support for mem-to-mem composition,
which is exposed as a drm_writeback connector in DRM.
Add a driver to support this feature.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- Add Eric's R-b
- Fix the code updating ->no_blank so that it does not reset it to
false when the CRTC is being disabled
- Use a table of txp formats instead of having a big switch-case block
- Fix typos in some comments
- Unconditionally update the DSP3 mux val
- Make sure we don't hang the system when TXP_BUSY is not cleared
Changes in v2:
- Rebased on top of drm-misc-next
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 6 +
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_crtc.c | 138 --
drivers/gpu/drm/vc4/vc4_debugfs.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 7 +
drivers/gpu/drm/vc4/vc4_txp.c | 477 +
7 files changed, 607 insertions(+), 24 deletions(-)
create mode 100644 drivers/gpu/drm/vc4/vc4_txp.c
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 284e2b14cfbe..26649b4c4dd8 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -74,6 +74,12 @@ Required properties for DSI:
The 3 clocks output from the DSI analog PHY: dsi[01]_byte,
dsi[01]_ddr2, and dsi[01]_ddr
+Required properties for the TXP (writeback) block:
+- compatible: Should be "brcm,bcm2835-txp"
+- reg: Physical base address and length of the TXP block's registers
+- interrupts: The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index 4a3a868235f8..b303703bc7f3 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -19,6 +19,7 @@ vc4-y := \
vc4_plane.o \
vc4_render_cl.o \
vc4_trace_points.o \
+ vc4_txp.o \
vc4_v3d.o \
vc4_validate.o \
vc4_validate_shaders.o
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index dcadf793ee80..96911a869cca 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -46,6 +46,8 @@ struct vc4_crtc_state {
struct drm_crtc_state base;
/* Dlist area for this CRTC configuration. */
struct drm_mm_node mm;
+ bool feed_txp;
+ bool txp_armed;
};
static inline struct vc4_crtc_state *
@@ -324,10 +326,8 @@ static struct drm_encoder *vc4_get_crtc_encoder(struct
drm_crtc *crtc)
return NULL;
}
-static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
+static void vc4_crtc_config_pv(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
- struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
@@ -338,12 +338,6 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
bool is_dsi = (vc4_encoder->type == VC4_ENCODER_TYPE_DSI0 ||
vc4_encoder->type == VC4_ENCODER_TYPE_DSI1);
u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
- bool debug_dump_regs = false;
-
- if (debug_dump_regs) {
- DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
- vc4_crtc_dump_regs(vc4_crtc);
- }
/* Reset the PV fifo. */
CRTC_WRITE(PV_CONTROL, 0);
@@ -419,6 +413,49 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
PV_CONTROL_CLK_SELECT) |
PV_CONTROL_FIFO_CLR |
PV_CONTROL_EN);
+}
+
+static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+ struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+ struct drm_display_mode *mode = &crtc->state->adjusted_mode;
+ bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
+ bool debug_dump_regs = false;
+
+ if (debug_dump_regs) {
+ DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
+ vc4_crtc_dump_regs(vc4_crtc);
+ }
+
+ if (vc4_crtc->channel == 2) {
+ u32 dispctrl;
+ u32 dsp3_mux;
+
+ /*
+* SCALER_DISPCTRL_DSP3 = X, where X < 2 means 'connect DSP3 to
+* FIFO X'.
+
[PATCH v3 9/9] ARM: dts: bcm283x: Add Transposer block
From: Boris Brezillon
The transposer block is allowing one to write the result of the VC4
composition back to memory instead of displaying it on a screen.
Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Reviewed-by: Eric Anholt
---
Changes in v3:
- Add R-b tags
Changes in v2:
- None
---
arch/arm/boot/dts/bcm283x.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index ac00e730f898..740870898b1e 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -66,6 +66,12 @@
clock-frequency = <100>;
};
+ txp@7e004000 {
+ compatible = "brcm,bcm2835-txp";
+ reg = <0x7e004000 0x20>;
+ interrupts = <1 11>;
+ };
+
dma: dma@7e007000 {
compatible = "brcm,bcm2835-dma";
reg = <0x7e007000 0xf00>;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
Op 29-06-18 om 12:27 schreef Stefan Schake: > Hey Maarten, > > On Fri, Jun 29, 2018 at 12:05 PM, Maarten Lankhorst > wrote: >> Op 22-02-18 om 04:54 schreef Stefan Schake: >>> Android assumes an implicit black background layer is always present >>> behind all layers it specifies for composition. drm_hwcomposer currently >>> punts responsibility for this to the kernel/DRM platform and puts layers >>> with per-pixel alpha content on the primary plane when requested. >>> >>> On some platforms (e.g. VC4) a background color fill has a cycle cost for >>> the hardware composer and is not enabled by default. Instead, userland can >>> request a background color through a CRTC property. Use this property to >>> specify the implicit black background Android expects. >>> >>> Signed-off-by: Stefan Schake >>> --- >>> Kernel changes for this (background_color) are available here: >>> >>> https://github.com/stschake/linux/commits/background-upstream >>> >>> Sending as RFC because I'm not entirely clear on whose responsibility >>> this should be, on most DRM drivers it seems to be implicit. I think >>> a case could also be made that VC4 should not accept alpha formats on >>> the lowest layer or enable background color fill when given one anyway. >>> On the other hand, userland control over background color seems desirable >>> regardless and is a feature of multiple hardware composers (i915, vc4, >>> omap). >> Ping? Would be nice if we were moving forward. :) > I was unclear if DRM specified a black background when writing this. > Someone pointed me towards the excerpt in the docs that explicitly > mandates black background fill and so I ended up writing a VC4 patch > that automatically sets it when required instead of the optional property > used here. > > Adding a background_color property would still be desirable, but I'm > unclear on what the userspace would be at the moment. drm_hwc doesn't > need any background color other than black and since that is the DRM > default, it wouldn't need to use a property. > > Thanks, > Stefan It would still be useful for e-paper displays where the background color would be better suited as white, or when we want to blend a different color than black. But I fear for now there's no real userspace. :( Which is unfortunate, because the series are easy to implement, but it's just a case where there's no need from userspace yet for the hw capability. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. But we do rely on the proper blockable handling. Yeah, but you could add the handling only after you have all the implementations in place. Don't you? Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. Well, I don't insist on this. It's just from my point of view that this patch doesn't needs to be one patch, but could be split up. Could be that I just don't know the code or the consequences of adding that well enough to really judge. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:24:29, Christian König wrote: > Am 02.07.2018 um 14:20 schrieb Michal Hocko: > > On Mon 02-07-18 14:13:42, Christian König wrote: > > > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > > > This is the v2 of RFC based on the feedback I've received so far. > > > > > > The > > > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, > > > > > > mostly > > > > > > because I have no idea how. > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > That sounds like it should work and at least the amdgpu changes now > > > > > look > > > > > good to me on first glance. > > > > > > > > > > Can you split that up further in the usual way? E.g. adding the > > > > > blockable > > > > > flag in one patch and fixing all implementations of the MMU notifier > > > > > in > > > > > follow up patches. > > > > But such a code would be broken, no? Ignoring the blockable state will > > > > simply lead to lockups until the fixup parts get applied. > > > Well to still be bisect-able you only need to get the interface change in > > > first with fixing the function signature of the implementations. > > That would only work if those functions return -AGAIN unconditionally. > > Otherwise they would pretend to not block while that would be obviously > > incorrect. This doesn't sound correct to me. > > > > > Then add all the new code to the implementations and last start to > > > actually > > > use the new interface. > > > > > > That is a pattern we use regularly and I think it's good practice to do > > > this. > > But we do rely on the proper blockable handling. > > Yeah, but you could add the handling only after you have all the > implementations in place. Don't you? Yeah, but then I would be adding a code with no user. And I really prefer to no do so because then the code is harder to argue about. > > > > Is the split up really worth it? I was thinking about that but had hard > > > > times to end up with something that would be bisectable. Well, except > > > > for returning -EBUSY until all notifiers are implemented. Which I found > > > > confusing. > > > It at least makes reviewing changes much easier, cause as driver > > > maintainer > > > I can concentrate on the stuff only related to me. > > > > > > Additional to that when you cause some unrelated side effect in a driver > > > we > > > can much easier pinpoint the actual change later on when the patch is > > > smaller. > > > > > > > > This way I'm pretty sure Felix and I can give an rb on the > > > > > amdgpu/amdkfd > > > > > changes. > > > > If you are worried to give r-b only for those then this can be done even > > > > for larger patches. Just make your Reviewd-by more specific > > > > R-b: name # For BLA BLA > > > Yeah, possible alternative but more work for me when I review it :) > > I definitely do not want to add more work to reviewers and I completely > > see how massive "flag days" like these are not popular but I really > > didn't find a reasonable way around that would be both correct and > > wouldn't add much more churn on the way. So if you really insist then I > > would really appreciate a hint on the way to achive the same without any > > above downsides. > > Well, I don't insist on this. It's just from my point of view that this > patch doesn't needs to be one patch, but could be split up. Well, if there are more people with the same concern I can try to do that. But if your only concern is to focus on your particular part then I guess it would be easier both for you and me to simply apply the patch and use git show $files_for_your_subystem on your end. I have put the patch to attempts/oom-vs-mmu-notifiers branch to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 14:35 schrieb Michal Hocko: On Mon 02-07-18 14:24:29, Christian König wrote: Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. But we do rely on the proper blockable handling. Yeah, but you could add the handling only after you have all the implementations in place. Don't you? Yeah, but then I would be adding a code with no user. And I really prefer to no do so because then the code is harder to argue about. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. Well, I don't insist on this. It's just from my point of view that this patch doesn't needs to be one patch, but could be split up. Well, if there are more people with the same concern I can try to do that. But if your only concern is to focus on your particular part then I guess it would be easier both for you and me to simply apply the patch and use git show $files_for_your_subystem on your end. I have put the patch to attempts/oom-vs-mmu-notifiers branch to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git Not wanting to block something as important as this, so feel free to add an Acked-by: Christian König to the patch. Let's rather face the next topic: Any idea how to runtime test this? I mean I can rather easily provide a test which crashes an AMD GPU, which in turn then would mean that the MMU notifier would block forever without this patch. But do you know a way to let the OOM killer kill a specific process? Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199475] AMDGPU Failed to blank
https://bugzilla.kernel.org/show_bug.cgi?id=199475 DCWizard (andrea...@protonmail.com) changed: What|Removed |Added Kernel Version|4.15.18 |4.17.3 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] drm/connector: Make ->atomic_commit() optional
On Mon, Jul 02, 2018 at 02:20:14PM +0200, Boris Brezillon wrote:
> Not all writeback connector implementations might want to commit things
> from the connector driver. Some, like the malidp driver, commit things
> from their main commit_tail() function, and would rather not have to
> implement a dummy hook for drm_connector_helper_funcs.atomic_commit().
>
> Make this function optional and reflect this fact in the doc.
>
> Signed-off-by: Boris Brezillon
Acked-by: Liviu Dudau
Thanks!
Liviu
> ---
> Changes in v3:
> - New patch
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 ++
> include/drm/drm_modeset_helper_vtables.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 69063bcf2334..ea19fcc252dc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1184,6 +1184,8 @@ static void drm_atomic_helper_commit_writebacks(struct
> drm_device *dev,
> const struct drm_connector_helper_funcs *funcs;
>
> funcs = connector->helper_private;
> + if (!funcs->funcs->atomic_commit)
> + continue;
>
> if (new_conn_state->writeback_job &&
> new_conn_state->writeback_job->fb) {
> WARN_ON(connector->connector_type !=
> DRM_MODE_CONNECTOR_WRITEBACK);
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index fb841f44949c..d0eb76c4b309 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -983,6 +983,8 @@ struct drm_connector_helper_funcs {
>* The writeback_job to commit is available in
>* &drm_connector_state.writeback_job.
>*
> + * This hook is optional.
> + *
>* This callback is used by the atomic modeset helpers.
>*/
> void (*atomic_commit)(struct drm_connector *connector,
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:39:50, Christian König wrote: [...] > Not wanting to block something as important as this, so feel free to add an > Acked-by: Christian König to the patch. Thanks a lot! > Let's rather face the next topic: Any idea how to runtime test this? This is a good question indeed. One way to do that would be triggering the OOM killer from the context which uses each of these mmu notifiers (one at the time) and see how that works. You would see the note in the log whenever the notifier would block. The primary thing to test is how often the oom reaper really had to back off completely. > I mean I can rather easily provide a test which crashes an AMD GPU, which in > turn then would mean that the MMU notifier would block forever without this > patch. Well, you do not really have to go that far. It should be sufficient to do the above. The current code would simply back of without releasing any memory. The patch should help to reclaim some memory. > But do you know a way to let the OOM killer kill a specific process? Yes, you can set its oom_score_adj to 1000 which means always select that task. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> Hi Ville,
>
> Thank you for the patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202
> base: git://people.freedesktop.org/~airlied/linux.git drm-next
>
> smatch warnings:
> drivers/gpu/drm/nouveau/nouveau_connector.c:461
> nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'.
>
> #
> https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06
> vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c
>
> 6ee738610 Ben Skeggs 2009-12-11 407
> 8777c5c11 Ben Skeggs 2014-06-06 408 static struct nouveau_encoder *
> 8777c5c11 Ben Skeggs 2014-06-06 409
> nouveau_connector_ddc_detect(struct drm_connector *connector)
> 6ee738610 Ben Skeggs 2009-12-11 410 {
> 6ee738610 Ben Skeggs 2009-12-11 411 struct drm_device *dev =
> connector->dev;
> 1a1841d30 Ben Skeggs 2012-12-10 412 struct nouveau_connector
> *nv_connector = nouveau_connector(connector);
> 77145f1cb Ben Skeggs 2012-07-31 413 struct nouveau_drm *drm =
> nouveau_drm(dev);
> 1167c6bc5 Ben Skeggs 2016-05-18 414 struct nvkm_gpio *gpio =
> nvxx_gpio(&drm->client.device);
> 8777c5c11 Ben Skeggs 2014-06-06 415 struct nouveau_encoder
> *nv_encoder;
> 6d385c0aa Rob Clark 2014-07-17 416 struct drm_encoder *encoder;
> 1a1841d30 Ben Skeggs 2012-12-10 417 int i, panel = -ENODEV;
> 1a1841d30 Ben Skeggs 2012-12-10 418
> 1a1841d30 Ben Skeggs 2012-12-10 419 /* eDP panels need powering on
> by us (if the VBIOS doesn't default it
> 1a1841d30 Ben Skeggs 2012-12-10 420 * to on) before doing any AUX
> channel transactions. LVDS panel power
> 1a1841d30 Ben Skeggs 2012-12-10 421 * is handled by the SOR
> itself, and not required for LVDS DDC.
> 1a1841d30 Ben Skeggs 2012-12-10 422 */
> 1a1841d30 Ben Skeggs 2012-12-10 423 if (nv_connector->type ==
> DCB_CONNECTOR_eDP) {
> 2ea7249fe Ben Skeggs 2015-08-20 424 panel =
> nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff);
> 1a1841d30 Ben Skeggs 2012-12-10 425 if (panel == 0) {
> 2ea7249fe Ben Skeggs 2015-08-20 426
> nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300);
> 1a1841d30 Ben Skeggs 2012-12-10 428 }
> 1a1841d30 Ben Skeggs 2012-12-10 429 }
> 6ee738610 Ben Skeggs 2009-12-11 430
> 7ec8bb653 Ville Syrjälä 2018-06-28 431
> drm_connector_for_each_possible_encoder(connector, encoder, i) {
> 6d385c0aa Rob Clark 2014-07-17 432 nv_encoder =
> nouveau_encoder(encoder);
>
> ^
> If we enter the loop that means nv_encoder is non-NULL. Smatch can't
> prove that we always enter the loop in this case for whatever reason but
> my guess is that we always do.
>
> 4ca2b7120 Francisco Jerez 2010-08-08 433
> 8777c5c11 Ben Skeggs 2014-06-06 434 if
> (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> 8777c5c11 Ben Skeggs 2014-06-06 435 int ret =
> nouveau_dp_detect(nv_encoder);
> 52aa30f25 Ben Skeggs 2016-11-04 436 if (ret ==
> NOUVEAU_DP_MST)
> 52aa30f25 Ben Skeggs 2016-11-04 437 return
> NULL;
> 52aa30f25 Ben Skeggs 2016-11-04 438 if (ret ==
> NOUVEAU_DP_SST)
> 8777c5c11 Ben Skeggs 2014-06-06 439 break;
> 8777c5c11 Ben Skeggs 2014-06-06 440 } else
> 39c1c9011 Lukas Wunner2016-01-11 441 if
> ((vga_switcheroo_handler_flags() &
> 39c1c9011 Lukas Wunner2016-01-11 442
> VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
> 39c1c9011 Lukas Wunner2016-01-11 443
> nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
> 39c1c9011 Lukas Wunner2016-01-11 444 nv_encoder->i2c) {
> 39c1c9011 Lukas Wunner2016-01-11 445 int ret;
> 39c1c9011 Lukas Wunner2016-01-11 446
> vga_switcheroo_lock_ddc(dev->pdev);
> 39c1c9011 Lukas Wunner2016-01-11 447 ret =
> nvkm_probe_i2c(nv_encoder->i2c, 0x50);
> 39c1c9011 Lukas Wunner2016-01-11 448
> vga_switcheroo_unlock_ddc(dev->pdev);
> 39c1c9011 Lukas Wunner2016-01-11 449 if (ret)
> 39c1c9011 Lukas Wunner2016-01-11 450 break;
> 39c1c9011 Lukas Wunner2016-01-11 451
Re: [PATCH v4 0/9] xen: dma-buf support for grant device
On 07/02/2018 11:20 AM, Juergen Gross wrote: On 02/07/18 09:10, Oleksandr Andrushchenko wrote: Hello, Boris, Juergen! Do you think I can re-base the series (which already has all required R-b's from Xen community) onto the latest kernel with API changes to patches 5 (of_dma_configure) and 8 (dma-buf atomic ops) and we can merge it to the Xen's kernel tree? Rebase: yes. Merging to the Xen kernel tree: only after setting up the for-linus-4.19 branch, which will be done by Boris later this month. Then I'll probably have to wait until for-linus-4.19 branch Boris, do you have any dates in mind for that? Juergen Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
These are needed for pl111 to use the generic fbdev emulation.
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 054b93689d94..17a38e85ba7d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -250,6 +250,8 @@ static struct drm_driver pl111_drm_driver = {
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/9] drm: Begin an API for in-kernel clients
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.
Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Documentation/gpu/drm-client.rst | 12 ++
Documentation/gpu/index.rst | 1 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_client.c | 289 +++
drivers/gpu/drm/drm_drv.c| 1 +
include/drm/drm_client.h | 76 ++
include/drm/drm_device.h | 7 +
7 files changed, 387 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/drm-client.rst
create mode 100644 drivers/gpu/drm/drm_client.c
create mode 100644 include/drm/drm_client.h
diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst
new file mode 100644
index ..7e672063e7eb
--- /dev/null
+++ b/Documentation/gpu/drm-client.rst
@@ -0,0 +1,12 @@
+=
+Kernel clients
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_client.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+ :export:
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 00288f34c5a6..1fcf8e851e15 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+ drm-client
drivers
vga-switcheroo
vgaarbiter
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 69c13517ea3a..d6657a61d037 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
- drm_syncobj.o drm_lease.o drm_writeback.o
+ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
new file mode 100644
index ..9c9b8ac7aea3
--- /dev/null
+++ b/drivers/gpu/drm/drm_client.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * This library provides support for clients running in the kernel like fbdev
and bootsplash.
+ * Currently it's only partially implemented, just enough to support fbdev.
+ *
+ * GEM drivers which provide a GEM based dumb buffer with a virtual address
are supported.
+ */
+
+static int drm_client_open(struct drm_client_dev *client)
+{
+ struct drm_device *dev = client->dev;
+ struct drm_file *file;
+
+ file = drm_file_alloc(dev->primary);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(&dev->filelist_mutex);
+ list_add(&file->lhead, &dev->filelist_internal);
+ mutex_unlock(&dev->filelist_mutex);
+
+ client->file = file;
+
+ return 0;
+}
+
+static void drm_client_close(struct drm_client_dev *client)
+{
+ struct drm_device *dev = client->dev;
+
+ mutex_lock(&dev->filelist_mutex);
+ list_del(&client->file->lhead);
+ mutex_unlock(&dev->filelist_mutex);
+
+ drm_file_free(client->file);
+}
+EXPORT_SYMBOL(drm_client_close);
+
+/**
+ * drm_client_new - Create a DRM client
+ * @dev: DRM device
+ * @client: DRM client
+ * @name: Client name
+ *
+ * Use drm_client_put() to free the client.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
+ const char *name)
+{
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+ !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
+ return -ENOTSUPP;
+
+ client->dev = dev;
+ client->name = name;
+
+ ret = drm_client_open(client);
+ if (ret)
+ return ret;
+
+ drm_dev_get(dev);
[PATCH v4 4/9] drm/cma-helper: Use the generic fbdev emulation
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini
This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().
tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 42 insertions(+), 321 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..5762a7c441e9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,6 +18,7 @@
*/
#include
+#include
#include
#include
#include
@@ -26,11 +27,8 @@
#include
#include
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
- const struct drm_framebuffer_funcs *fb_funcs;
};
/**
@@ -44,36 +42,6 @@ struct drm_fbdev_cma {
*
* An fbdev framebuffer backed by cma is also available by calling
* drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
- * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be
- * set up automatically. &drm_framebuffer_funcs.dirty is called by
- * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
- *
- * Example fbdev deferred io code::
- *
- * static int driver_fb_dirty(struct drm_framebuffer *fb,
- *struct drm_file *file_priv,
- *unsigned flags, unsigned color,
- *struct drm_clip_rect *clips,
- *unsigned num_clips)
- * {
- * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
- * ... push changes ...
- * return 0;
- * }
- *
- * static struct drm_framebuffer_funcs driver_fb_funcs = {
- * .destroy = drm_gem_fb_destroy,
- * .create_handle = drm_gem_fb_create_handle,
- * .dirty = driver_fb_dirty,
- * };
- *
- * Initialize::
- *
- * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
- * dev->mode_config.num_crtc,
- * dev->mode_config.num_connector,
- * &driver_fb_funcs);
- *
*/
static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
@@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
- return dma_mmap_writecombine(info->device, vma, info->screen_base,
-info->fix.smem_start, info->fix.smem_len);
-}
-
-static struct fb_ops drm_fbdev_cma_ops = {
- .owner = THIS_MODULE,
- DRM_FB_HELPER_DEFAULT_OPS,
- .fb_fillrect= drm_fb_helper_sys_fillrect,
- .fb_copyarea= drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
- .fb_mmap= drm_fb_cma_mmap,
-};
-
-static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
- fb_deferred_io_mmap(info, vma);
- vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-
- return 0;
-}
-
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdef
[PATCH v4 2/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 192 +++-
include/drm/drm_fb_helper.h | 31 +++
2 files changed, 222 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cab14f253384..0a0a577ebc3c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,6 +30,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
#include
#include
#include
@@ -738,6 +739,24 @@ static void drm_fb_helper_resume_worker(struct work_struct
*work)
console_unlock();
}
+static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
+ struct drm_clip_rect *clip)
+{
+ struct drm_framebuffer *fb = fb_helper->fb;
+ unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+ size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
+ void *src = fb_helper->fbdev->screen_buffer + offset;
+ void *dst = fb_helper->buffer->vaddr + offset;
+ size_t len = (clip->x2 - clip->x1) * cpp;
+ unsigned int y;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ memcpy(dst, src, len);
+ src += fb->pitches[0];
+ dst += fb->pitches[0];
+ }
+}
+
static void drm_fb_helper_dirty_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -753,8 +772,12 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
spin_unlock_irqrestore(&helper->dirty_lock, flags);
/* call dirty callback only when it has been really touched */
- if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
+ if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
+ /* Generic fbdev uses a shadow buffer */
+ if (helper->buffer)
+ drm_fb_helper_dirty_blit_real(helper, &clip_copy);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+ }
}
/**
@@ -2921,6 +2944,173 @@ void drm_fb_helper_output_poll_changed(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
+/* @user: 1=userspace, 0=fbcon */
+static int drm_fbdev_fb_open(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ if (!try_module_get(fb_helper->dev->driver->fops->owner))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int drm_fbdev_fb_release(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ module_put(fb_helper->dev->driver->fops->owner);
+
+ return 0;
+}
+
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct fb_info *fbi = fb_helper->fbdev;
+ struct fb_ops *fbops = NULL;
+ void *shadow = NULL;
+
+ if (fbi->fbdefio) {
+ fb_deferred_io_cleanup(fbi);
+ shadow = fbi->screen_buffer;
+ fbops = fbi->fbops;
+ }
+
+ drm_fb_helper_fini(fb_helper);
+
+ if (shadow) {
+ vfree(shadow);
+ kfree(fbops);
+ }
+
+ drm_client_framebuffer_delete(fb_helper->buffer);
+ drm_client_release(&fb_helper->client);
+ kfree(fb_helper);
+}
+
+static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ if (fb_helper->dev->driver->gem_prime_mmap)
+ return
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+ else
+ return -ENODEV;
+}
+
+static struct fb_ops drm_fbdev_fb_ops = {
+ .owner = THIS_MODULE,
+ DRM_FB_HELPER_DEFAULT_OPS,
+ .fb_open= drm_fbdev_fb_open,
+ .fb_release = drm_fbdev_fb_release,
+ .fb_destroy = drm_fbdev_fb_destroy,
+ .fb_mmap= drm_fbdev_fb_mmap,
+ .fb_read= drm_fb_helper_sys_read,
+ .fb_write = drm_fb_helper_sys_write,
+ .fb_fillrect= drm_fb_helper_sys_fillrect,
+ .fb_copyarea= drm_fb_helper_sys_copyarea,
+ .fb_imageblit = drm_fb_helper_sys_imageblit,
+};
+
+static struct fb_deferred_io drm_fbdev_defio = {
+ .delay = HZ / 20,
+ .deferred_io= drm_fb_helper_deferred_io,
+};
+
+/**
+ * drm_fb_helper_generic_probe - Generic fbdev emulation probe helper
+ * @fb_helper: fbdev helper structure
+ * @sizes: describes fbdev size and scanout surface
