Re: [PATCH] drm: Fix hdmi connector content type property docs
On Mon, Jul 02, 2018 at 10:03:51AM +, Lisovskiy, Stanislav wrote:
> 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.
Yeah figured as much, nw.
> Reviewed-by: Stanislav Lisovskiy
Thanks for your review, applied to 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] gpu: drm: virito: code cleanup
On Mon, Jul 02, 2018 at 11:57:28PM +0530, Souptick Joarder wrote: > The fault handler code is commented since v4.2. > If there is no plan to enable the fault handler > code in future, we can remove this dead code. Indeed, but please without tyops in the $subject line. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107095] Artifacts in X sessions, GPU fault 147
https://bugs.freedesktop.org/show_bug.cgi?id=107095 --- Comment #1 from Andrew Dorney --- Created attachment 140443 --> https://bugs.freedesktop.org/attachment.cgi?id=140443&action=edit lspci -- 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
[Bug 107095] Artifacts in X sessions, GPU fault 147
https://bugs.freedesktop.org/show_bug.cgi?id=107095 Bug ID: 107095 Summary: Artifacts in X sessions, GPU fault 147 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: andrew...@gmail.com Created attachment 140442 --> https://bugs.freedesktop.org/attachment.cgi?id=140442&action=edit dmesg I purchased a new "MSI Radeon RX 580 Armor MK2 8G OC" this week. I am getting intermittend visual artifacts on some windows, but not others. Arch Linux linux 4.17.3-1 mesa 18.1.3-1 xf86-video-amdgpu 18.0.1-2 xorg-server 1.20.0-9 When I play games, the card performs admirably. No artifacting, no stutter. I've tripled-to-quadrupled my FPS, so accelleration works great. Where I'm having problems is on GUIs. Text and GUI elements often show squares or lines. The color of the squares or lines are the color of the window or desktop below the active window. When I move or force a redraw on the active window, the squares/lines disappear or reappear in a new place on the active window. It occurs regularly in Firefox, xterm, Konsole, and kdesu4 permission popups. The problem occurs both when I am running only GUIs, and when I am running games and GUIs simultaneously, so I don't think it's a power state issue. To narrow down if it was Plasma or not, I rebooted and started Fluxbox. I started only xterms, ran some commands, and got no errors whatsoever. Then I started moving them around the screen. That's when I got this in my dmesg: [ 200.335982] amdgpu :01:00.0: GPU fault detected: 147 0x0508c402 [ 200.335986] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000FFAA1 [ 200.335988] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C4002 [ 200.335991] amdgpu :01:00.0: VM fault (0x02, vmid 5, pasid 32768) at page 1047201, read from 'TC3' (0x54433300) (196) >From then on, artifacts appeared on all windows per usual. Gaming and heavy 3D remained unaffected. Should I RMA the card, or is this likely a software stack bug and I should wait for more Mesa/Kernel updates? Please let me know if I can provide more information. Thanks! -- 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
[Bug 200395] nv04_timer_read() hangs a CPU
https://bugzilla.kernel.org/show_bug.cgi?id=200395 --- Comment #2 from Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) --- It also hangs when I run X but interestingly not when I run swaywm. -- 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 200395] nv04_timer_read() hangs a CPU
https://bugzilla.kernel.org/show_bug.cgi?id=200395 --- Comment #1 from Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) --- I forgot to add that there is also an integrated Intel GPU on the system. -- 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 200395] New: nv04_timer_read() hangs a CPU
https://bugzilla.kernel.org/show_bug.cgi?id=200395 Bug ID: 200395 Summary: nv04_timer_read() hangs a CPU Product: Drivers Version: 2.5 Kernel Version: 4.17.3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com Regression: No Created attachment 277145 --> https://bugzilla.kernel.org/attachment.cgi?id=277145&action=edit dmesg output Whenever I run "weston-launcher" from the Arch Linux repos the kernel hangs. As far as I can tell this is a nouveau issue. The official name of the offending GPU is "NVIDIA GeForce GTX 1060." Attached is the dmesg output right after I ran "weston-launcher"(getting it off that machine was not easy and involved a lot of rebooting). Unfortunately, the machine hangs when I do "lspci" or "lsusb". It seems to be an related if not the same issue. I do however have a working install of Microsoft Windows and can provide any hardware data collectible from Windows. -- 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 v13 3/3] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On Wed, Jun 27, 2018 at 03:27:35PM +0530, Sandeep Panda wrote: > Document the bindings used for the sn65dsi86 DSI to eDP bridge. > > Changes in v1: > - Rephrase the dt-binding descriptions to be more inline with existing >bindings (Andrzej Hajda). > - Add missing dt-binding that are parsed by corresponding driver >(Andrzej Hajda). > > Changes in v2: > - Remove edp panel specific dt-binding entries. Only keep bridge >specific entries (Sean Paul). > - Remove custom-modes dt entry since its usage is removed from driver also > (Sean Paul). > - Remove is-pluggable dt entry since this will not be needed anymore (Sean > Paul). > > Changes in v3: > - Remove irq-gpio dt entry and instead populate is an interrupt >property (Rob Herring). > > Changes in v4: > - Add link to bridge chip datasheet (Stephen Boyd) > - Add vpll and vcc regulator supply bindings (Stephen Boyd) > - Add ref clk optional dt binding (Stephen Boyd) > - Add gpio-controller optional dt binding (Stephen Boyd) > > Changes in v5: > - Use clock property to specify the input refclk (Stephen Boyd). > - Update gpio cell and pwm cell numbers (Stephen Boyd). > > Changes in v6: > - Add property to mention the lane mapping scheme and polarity inversion >(Stephen Boyd). > > Changes in v7: > - Detail description of lane mapping scheme dt property (Andrzej >Hajda/ Rob Herring). > - Removed HDP gpio binding, since the bridge uses IRQ signal to >determine HPD, and IRQ property is already documented in binding. > > Changes in v8: > - Removed unnecessary explanation of lane mapping and polarity dt >property, since these are already explained in media/video-interface >dt binidng (Rob Herring). > > Changes in v9: > - Avoid putting re-definition of lane mapping and polarity dt binding >(Rob Herring). > > Changes in v10: > - Use interrupts-extended property instead of interrupts to specify >interrupt line (Andrzej Hajda). > - Move data-lanes and lane-polarity property example to proper place > (Andrzej Hajda). > > Changes in v11: > - Add a property for suspend gpio function of GPIO1 pin on bridge chip >(Stephen Boyd). > > Signed-off-by: Sandeep Panda > --- > .../bindings/display/bridge/ti,sn65dsi86.txt | 89 > ++ > 1 file changed, 89 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
Dne nedelja, 01. julij 2018 ob 21:25:57 CEST je Jernej Škrabec napisal(a):
> 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>;
> > >> >> >> > +
[PATCH] drm: add missing ctx argument to plane transitional helpers
In commits:
34a2ab5e0689 ("drm: Add acquire ctx parameter to ->update_plane")
1931529448bc ("drm: Add acquire ctx parameter to ->plane_disable")
a pointer to a drm_modeset_acquire_ctx structure was added as an
argument to the method prototypes. The transitional helpers are
supposed to be directly plugged in as implementations of these
methods, but doing so generates a warning. Add the missing
argument.
A number of buggy users were added for drm_plane_helper_disable()
which need to be fixed up for this change, which we do by passing
a NULL ctx argument.
Fixes: 1931529448bc ("drm: Add acquire ctx parameter to ->plane_disable")
Signed-off-by: Russell King
---
Note: not build for all the affected drivers yet.
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +-
drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +-
drivers/gpu/drm/drm_plane_helper.c | 8 ++--
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 +-
drivers/gpu/drm/sti/sti_cursor.c | 2 +-
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/sti/sti_hqvdp.c| 2 +-
drivers/gpu/drm/vc4/vc4_plane.c| 2 +-
drivers/gpu/drm/zte/zx_plane.c | 2 +-
include/drm/drm_plane_helper.h | 6 --
11 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index c3349b8fb58b..965cda48dc13 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -186,7 +186,7 @@ static const struct drm_plane_helper_funcs
arc_pgu_plane_helper_funcs = {
static void arc_pgu_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane);
+ drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf5cbd63ecdf..f3f08cd6e9ef 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -282,7 +282,7 @@ static const struct drm_plane_helper_funcs
hdlcd_plane_helper_funcs = {
static void hdlcd_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane);
+ drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 2010794943bc..621f17643bb0 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -440,6 +440,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
* @src_y: y offset of @fb for panning
* @src_w: width of source rectangle in @fb
* @src_h: height of source rectangle in @fb
+ * @ctx: lock acquire context, not used here
*
* Provides a default plane update handler using the atomic plane update
* functions. It is fully left to the driver to check plane constraints and
@@ -455,7 +456,8 @@ int drm_plane_helper_update(struct drm_plane *plane, struct
drm_crtc *crtc,
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)
+ uint32_t src_w, uint32_t src_h,
+ struct drm_modeset_acquire_ctx *ctx)
{
struct drm_plane_state *plane_state;
@@ -489,6 +491,7 @@ EXPORT_SYMBOL(drm_plane_helper_update);
/**
* drm_plane_helper_disable() - Transitional helper for plane disable
* @plane: plane to disable
+ * @ctx: lock acquire context, not used here
*
* Provides a default plane disable handler using the atomic plane update
* functions. It is fully left to the driver to check plane constraints and
@@ -499,7 +502,8 @@ EXPORT_SYMBOL(drm_plane_helper_update);
* RETURNS:
* Zero on success, error code on failure
*/
-int drm_plane_helper_disable(struct drm_plane *plane)
+int drm_plane_helper_disable(struct drm_plane *plane,
+struct drm_modeset_acquire_ctx *ctx)
{
struct drm_plane_state *plane_state;
struct drm_framebuffer *old_fb;
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 7b641fa6dc4d..79ff653d8081 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -68,7 +68,7 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
{
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
- drm_plane_helper_disable(plane);
+ drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
kfree(mdp4_plane);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index c4f115fe96ff..7d306c5acd09 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -46,7 +46,7 @@ static voi
Re: [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
On Mon, Jul 02, 2018 at 01:53:17PM +0200, Thierry Reding wrote:
> 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.
Looks fine to me.
Acked-by: Russell King
Thanks.
>
> 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
> >
--
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
Regression: no display with Vega 56 AMD GPU bisected to commit bfdec2340478
Hi folks,
A Fedora user, Mikhail (CCed), reported[0] a regression with their Vega
56 AMD GPU introduced by bfdec2340478 ("drm/amd/display: Implement
dm_pp_get_clock_levels_by_type_with_latency"). The symptom is that
nothing is displayed and looking at the logs (attached to the Bugzilla),
I see gnome-shell is failing with "Failed to set CRTC mode 3840x2160:
Invalid argument". The problem persists through 4.18 RC2 so it's not
fixed by 10dd2b865393 ("drm/amd/display: Fix wrong latency assignment
for VEGA clock levels").
I see a couple "if (!dm_pp_get_clock_levels_by_type_with_latency)"
blocks which would no longer be unconditionally run, but I don't know
enough to even guess at the problem.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1592110
Regards,
Jeremy
___
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 Mon, 2018-07-02 at 09:36 +0200, Bernd Petrovitsch wrote: > > +#define for_each_registered_fb(i) \ > > + for (i = 0; i < FB_MAX; i++)\ > > + if (registered_fb[i]) > > + > > That leaves the possibility of a dangling-else. > snip > #define for_each_registered_fb(i) \ > for (i = 0; i < FB_MAX; i++)\ > if (!registered_fb[i]) \ > continue; \ > else > snip > avoids that. Yes, you not alone :-) AFAIU there is a v2 which fixes that, though Daniel pointed out that DRM has a specific macro to make life easier. -- Andy Shevchenko Intel Finland Oy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
trouble with kernel 4.17.3 amdgpu
Hi, I have a XFX Radeon VEGA 64, and a SuperMicro H11SSL-NC. I have been using the kernel.org 4.17.3 tree. I can run gnome-shell for awhile but the box eventually crashes. The VEGA fans go full blast and the machine becomes unresponsive. This is with my own "home brew" linux and also with Debian. I did try with a Fedora 28 live CD and it did not crash with it. I left it running for a fairly long time. Anyone have an ideas? This is what the kernel spits out: amdgpu :23:00.0: couldn't schedule ib on ring mpt3sas_cm0: scan devices: complete [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring PM: suspend exit [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_j
Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size
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
>
> 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 v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size
On 2 July 2018 at 13:57, Bartlomiej Zolnierkiewicz
wrote:
> 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).
>
Ah ok, I didn't realise that. I don't think there will be any
conflicts, since the efifb changes in the efi tree and these changes
operate on different parts of the file. But let's double check before
taking stuff into -next.
(efi/next is not pulled into -next directly, but via the tip:efi tree,
and I haven't sent a pull request yet for v4.19)
>> > 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
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
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. Juergen ___ 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 Mon, Jul 02, 2018 at 10:47:03AM +0200, Daniel Vetter wrote: > On Sun, Jul 01, 2018 at 04:34:02PM +0100, Russell King - ARM Linux wrote: > > > 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. However, isn't there a problem in doing that, as going through the transition process means you: 1. switch planes to use the plane transitional helpers 2. migrate crtc to mode_set_nofb() 3. migrate page_flip to use a transitional implementation 4. clean up to use the plane state for all properties 5. switch to atomic modeset by adding .atomic_check / .atomic_commit and DRIVER_ATOMIC flag 6. migrate away from transitional helpers as separate stages - which means there's a brief period where you have the .atomic_commit method populated (and hence drm_drv_uses_atomic_modeset() returns true) but the transitional helpers are still being used. I've found if you do (5) and (6) in one go, it becomes quite a large set of changes: drivers/gpu/drm/armada/armada_crtc.c| 308 +--- drivers/gpu/drm/armada/armada_crtc.h| 20 --- drivers/gpu/drm/armada/armada_overlay.c | 175 -- drivers/gpu/drm/armada/armada_plane.c | 4 +- 4 files changed, 36 insertions(+), 471 deletions(-) > 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(). Hmm, that's something else I've missed in my conversion... thanks for pointing it out. ;) > - 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. Ok, I've a commit for that - I just need to merge it with the one I already have adding the ctx argument, grab drm-misc-next and make sure it applies there... I'll try to get it out in shortly. -- 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
Hi all! On Fri, 2018-06-29 at 00:20 +0800, Yisheng Xie wrote: [...] > diff --git a/include/linux/fb.h b/include/linux/fb.h > index aa74a22..3e13b95 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct > fb_var_screeninfo *var, > extern int num_registered_fb; > extern struct class *fb_class; > > +#define for_each_registered_fb(i)\ > + for (i = 0; i < FB_MAX; i++)\ > + if (registered_fb[i]) > + That leaves the possibility of a dangling-else. snip #define for_each_registered_fb(i) \ for (i = 0; i < FB_MAX; i++)\ if (!registered_fb[i]) \ continue; \ else snip avoids that. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ 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 Mon, 2018-07-02 at 09:30 +0200, Daniel Vetter wrote: > 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: > > 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. Wow, didn't know we have a such. It's a good idea to forelift it for wider use. Yisheng, it seems you may use it in your patch directly. -- Andy Shevchenko Intel Finland Oy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: virito: code cleanup
The fault handler code is commented since v4.2.
If there is no plan to enable the fault handler
code in future, we can remove this dead code.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/virtio/virtgpu_ttm.c | 36 +---
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 11f8ae5..b6f021c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -106,29 +106,6 @@ static void virtio_gpu_ttm_global_fini(struct
virtio_gpu_device *vgdev)
}
}
-#if 0
-/*
- * Hmm, seems to not do anything useful. Leftover debug hack?
- * Something like printing pagefaults to kernel log?
- */
-static struct vm_operations_struct virtio_gpu_ttm_vm_ops;
-static const struct vm_operations_struct *ttm_vm_ops;
-
-static int virtio_gpu_ttm_fault(struct vm_fault *vmf)
-{
- struct ttm_buffer_object *bo;
- struct virtio_gpu_device *vgdev;
- int r;
-
- bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
- if (bo == NULL)
- return VM_FAULT_NOPAGE;
- vgdev = virtio_gpu_get_vgdev(bo->bdev);
- r = ttm_vm_ops->fault(vmf);
- return r;
-}
-#endif
-
int virtio_gpu_mmap(struct file *filp, struct vm_area_struct *vma)
{
struct drm_file *file_priv;
@@ -143,19 +120,8 @@ int virtio_gpu_mmap(struct file *filp, struct
vm_area_struct *vma)
return -EINVAL;
}
r = ttm_bo_mmap(filp, vma, &vgdev->mman.bdev);
-#if 0
- if (unlikely(r != 0))
- return r;
- if (unlikely(ttm_vm_ops == NULL)) {
- ttm_vm_ops = vma->vm_ops;
- virtio_gpu_ttm_vm_ops = *ttm_vm_ops;
- virtio_gpu_ttm_vm_ops.fault = &virtio_gpu_ttm_fault;
- }
- vma->vm_ops = &virtio_gpu_ttm_vm_ops;
- return 0;
-#else
+
return r;
-#endif
}
static int virtio_gpu_invalidate_caches(struct ttm_bo_device *bdev,
--
1.9.1
___
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 #13 from Andrey Grodzovsky --- (In reply to dwagner from comment #12) > (In reply to Andrey Grodzovsky from comment #10) > > Created attachment 140418 [details] [review] [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. > > While I can start X11 with this patch applied to current > amd-staging-drm-next, attempts to resume from S3 fail consistently. > > The following related output is emitted right before the suspend: > > Jul 02 21:31:32 ryzen kernel: Freezing remaining freezable tasks ... > (elapsed 0.000 seconds) done. > Jul 02 21:31:32 ryzen kernel: Suspending console(s) (use no_console_suspend > to debug) > Jul 02 21:31:32 ryzen kernel: sd 9:0:0:0: [sda] Synchronizing SCSI cache > Jul 02 21:31:32 ryzen kernel: [TTM] Buffer eviction failed > Jul 02 21:31:32 ryzen kernel: ACPI: Preparing to enter system sleep state S3 > Jul 02 21:31:32 ryzen kernel: PM: Saving platform NVS memory > Jul 02 21:31:32 ryzen kernel: Disabling non-boot CPUs ... > > (I wonder if that "[TTM] Buffer eviction failed" is a bad sign - as I have > seen it some other times in conjunction with heavy uses of the amdgpu > driver.) > > > Then, upon resume, the following messages are emitted: > > Jul 02 21:31:33 ryzen kernel: ACPI: Low-level resume complete > Jul 02 21:31:33 ryzen kernel: [drm] PCIE GART of 256M enabled (table at > 0x00F40030). > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 146 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 148 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 145 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 146 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 189 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 306 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 5e ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 18a ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 145 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 146 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 148 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 145 ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >last message was failed ret is 0 > Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] >failed to send message 146 ret is 0 > Jul 02 21:31:33 ryzen kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* > amdgpu: ring 0 test failed (scratch(0xC040)=0xC> > Jul 02 21:31:33 ryzen kernel: [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] > *ERROR* resume of IP block failed -22 > Jul 02 21:31:33 ryzen kernel: [drm:amdgpu_device_resume [amdgpu]] *ERROR* > amdgpu_device_ip_resume failed (-22). > Jul 02 21:31:33 ryzen kernel: dpm_run_callback(): pci_pm_
[Bug 99782] Driver lockup using dolphin in specific areas
https://bugs.freedesktop.org/show_bug.cgi?id=99782 --- Comment #1 from Charadon --- I'm getting this issue also on Mesa 18.1.3. So far its happened in the following areas Legend of Zelda: Twilight Princess: System locks up when going into the area of the first light spring. Metroid Prime: Freezes Randomly in Chozo Ruins It freezes with both the Vulkan and OpenGL backends at the exact same areas. Doesn't crash in software rendering mode, so its definately a driver issue. -- 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/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init
Hi Alex,
On Sun, Apr 15, 2018 at 9:48 PM Agrawal, Akshu wrote:
>
>
>
> On 4/13/2018 9:45 PM, Daniel Kurtz wrote:
> > Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
> > stoney/cz") added support for the "BT_I2S" ACP i2s channel. As part of
> > this change, one additional acp resource was added, but the "num_resource"
> > count was accidentally incremented by 2.
> >
> > This incorrect count eventually causes mfd_add_device() to try to access
> > an invalid memory address (the location of non-existent resource 5.
> >
> > This fault was detected by running a KASAN enabled kernel, which produced
> > the following splat at boot:
> >
> > [6.612987]
> > ==
> > [6.613509] BUG: KASAN: slab-out-of-bounds in mfd_add_device+0x4bc/0x7a7
> > [6.613509] Read of size 8 at addr 880107d4dc58 by task swapper/0/1
> > [6.613509]
> > [6.613509] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.33 #349
> > [6.613509] Hardware name: Google Grunt/Grunt, BIOS
> > Google_Grunt.10543.0.2018_04_03_1812 04/02/2018
> > [6.613509] Call Trace:
> > [6.613509] dump_stack+0x4d/0x63
> > [6.613509] print_address_description+0x80/0x2d6
> > [6.613509] ? mfd_add_device+0x4bc/0x7a7
> > [6.613509] kasan_report+0x255/0x295
> > [6.613509] mfd_add_device+0x4bc/0x7a7
> > [6.613509] ? kasan_kmalloc+0x99/0xa8
> > [6.613509] ? mfd_add_devices+0x58/0xe4
> > [6.613509] ? __kmalloc+0x154/0x178
> > [6.613509] mfd_add_devices+0xa5/0xe4
> > [6.613509] acp_hw_init+0x92e/0xc4a
> > [6.613509] amdgpu_device_init+0x1dfb/0x22a2
> > [6.613509] ? kmalloc_order+0x53/0x5d
> > [6.613509] ? kmalloc_order_trace+0x23/0xb3
> > [6.613509] amdgpu_driver_load_kms+0xce/0x267
> > [6.613509] drm_dev_register+0x169/0x2fb
> > [6.613509] amdgpu_pci_probe+0x217/0x242
> > [6.613509] pci_device_probe+0x101/0x18e
> > [6.613509] driver_probe_device+0x1dd/0x419
> > [6.613509] ? ___might_sleep+0x80/0x1b6
> > [6.613509] __driver_attach+0x9f/0xc9
> > [6.613509] ? driver_probe_device+0x419/0x419
> > [6.613509] bus_for_each_dev+0xbc/0xe1
> > [6.613509] bus_add_driver+0x189/0x2c0
> > [6.613509] driver_register+0x108/0x156
> > [6.613509] ? ttm_init+0x67/0x67
> > [6.613509] do_one_initcall+0xb2/0x161
> > [6.613509] kernel_init_freeable+0x25a/0x308
> > [6.613509] ? rest_init+0xcc/0xcc
> > [6.613509] kernel_init+0x11/0x10d
> > [6.613509] ? rest_init+0xcc/0xcc
> > [6.613509] ret_from_fork+0x22/0x40
> > [6.613509]
> > [6.613509] Allocated by task 1:
> > [6.613509] save_stack+0x46/0xce
> > [6.613509] kasan_kmalloc+0x99/0xa8
> > [6.613509] kmem_cache_alloc_trace+0x11a/0x13e
> > [6.613509] acp_hw_init+0x210/0xc4a
> > [6.613509] amdgpu_device_init+0x1dfb/0x22a2
> > [6.613509] amdgpu_driver_load_kms+0xce/0x267
> > [6.613509] drm_dev_register+0x169/0x2fb
> > [6.613509] amdgpu_pci_probe+0x217/0x242
> > [6.613509] pci_device_probe+0x101/0x18e
> > [6.613509] driver_probe_device+0x1dd/0x419
> > [6.613509] __driver_attach+0x9f/0xc9
> > [6.613509] bus_for_each_dev+0xbc/0xe1
> > [6.613509] bus_add_driver+0x189/0x2c0
> > [6.613509] driver_register+0x108/0x156
> > [6.613509] do_one_initcall+0xb2/0x161
> > [6.613509] kernel_init_freeable+0x25a/0x308
> > [6.613509] kernel_init+0x11/0x10d
> > [6.613509] ret_from_fork+0x22/0x40
> > [6.613509]
> > [6.613509] Freed by task 0:
> > [6.613509] (stack is not available)
> > [6.613509]
> > [6.613509] The buggy address belongs to the object at 880107d4db08
> > [6.613509] which belongs to the cache kmalloc-512 of size 512
> > [6.613509] The buggy address is located 336 bytes inside of
> > [6.613509] 512-byte region [880107d4db08, 880107d4dd08)
> > [6.613509] The buggy address belongs to the page:
> > [6.613509] page:ea00041f5300 count:1 mapcount:0 mapping:
> > (null) index:0x0 compound_mapcount: 0
> > [6.613509] flags: 0x80008100(slab|head)
> > [6.613509] raw: 80008100
> > 000100120012
> > [6.613509] raw: ea0004208520 88010b001680 88010b002cc0
> >
> > [6.613509] page dumped because: kasan: bad access detected
> > [6.613509]
> > [6.613509] Memory state around the buggy address:
> > [6.613509] 880107d4db00: fc 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00
> > [6.613509] 880107d4db80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00
> > [6.613509] >880107d4dc00: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
> > fc fc
> > [6.613509] ^
> > [6.613509] 880107d4dc80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > fc fc
> > [6.613509] 880107d4dd00:
Re: [PATCH 1/2] drm/panel: Augment the TPO TPG110 bindings
On Sun, Jul 1, 2018 at 1:01 PM 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. Yes, I'm aware of the term, but I see *far* more of the other use of "driver". Can you say "panel driver IC" to clarify. > 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. Yep. I've had the fun of trying to figure out how to get panels working and having the piecemeal documentation of the driver IC without all the hook-up details... > > 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. According to that, there's only 1 panel supported. > In fact I think many panel drivers are just sloppily slipping in > under the radar as "panels" in our bindings. Indeed. I'm not sure that trying to split driver ICs and panels is really feasible at least up front given how poor the documentation is typically. > >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. Nice. Can you add that detail. > 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 Also, use 'reset-gpios' as that is the standard name. > > > - 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. If this is 3-wire SPI then as Andrzej says, then still it should be done as spi-gpio. Which really just means these gpio properties go away and this should be a SPI child node. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
XFX Vega 64 crashing on Linux-4.17.3
Hi, I have a XFX Radeon VEGA 64, and a SuperMicro H11SSL-NC. I have been using the kernel.org 4.17.3 tree. I can run gnome-shell for awhile but the box eventually crashes. The VEGA fans go full blast and the machine becomes unresponsive. This is with my own "home brew" linux and also with Debian. I did try with a Fedora 28 live CD and it did not crash with it. I left it running for a fairly long time. Anyone have an ideas? This is what the kernel spits out: amdgpu :23:00.0: couldn't schedule ib on ring mpt3sas_cm0: scan devices: complete [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring PM: suspend exit [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) amdgpu :23:00.0: couldn't schedule ib on ring [drm:amdgpu_
[PATCH] video/console/vgacon: Print big fat warning with nomodeset
It's been a pretty good while since kernel modesetting was introduced.
It has almost entirely replaced previous solutions which required
userspace modesetting, and I can't even recall any drivers off the top
of my head for modern day hardware that don't only support one or the
other. Even nvidia's ugly blob does not require the use of nomodeset,
and only requires that nouveau be blacklisted.
Effectively, the only thing nomodeset does in the year 2018 is disable
your graphics drivers. Since VESA is a thing, this will give many users
the false impression that they've actually fixed an issue they were
having with their machine simply because the laptop will boot up to a
degraded GUI. This of course, is never actually the case.
Things get even worse when you consider that there's still an enormous
amount of tutorials users find on the internet that still suggest adding
nomodeset, along with various users who have been around long enough to
still suggest it.
There really isn't any legitimate reason I can see for this to be an
option that's used by anyone else other then developers, or properly
informed users. So, let's end the confusion and start printing warnings
whenever it's enabled.
Signed-off-by: Lyude Paul
---
drivers/video/console/vgacon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index f09e17b60e45..09731b2f6815 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -112,6 +112,11 @@ EXPORT_SYMBOL(vgacon_text_force);
static int __init text_mode(char *str)
{
vgacon_text_mode_force = true;
+
+ pr_warning("You have booted with nomodeset. This means your GPU drivers
are DISABLED\n");
+ pr_warning("Any video related functionality will be severely degraded,
and you may not even be able to suspend the system properly\n");
+ pr_warning("Unless you actually understand what nomodeset does, you
should reboot without enabling it\n");
+
return 1;
}
--
2.17.1
___
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 #15 from phoenix (fe...@feldspaten.org) --- Created attachment 277135 --> https://bugzilla.kernel.org/attachment.cgi?id=277135&action=edit kmemleak output of Cities.x64 I was finally able to create a kmemleak output and cropped it to the relevant outpt coming from the affected program. I hope this is helpful. -- 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: [amdgpu][tahiti xt] cursor motion smoothness
On Mon, Jul 02, 2018 at 06:43:48PM +0200, Michel Dänzer wrote: > > Sending the logs as direct email to your personal email box. > > Does using xf86-input-libinput instead of xf86-input-evdev help? I did plan to switch to libinput in the futur, but: I did test the xinput events and I get for a reasonable mouse motion speed an update of coords for each column of the screen (full hd). It means that the cursor is supposely displayed for nearly all columns of the screen. For a fast mouse motion, the coord updates jump to a few tens of pixels. (1000Hz mouse) Those numbers does not change from 60Hz to 144Hz, then I can rule out the input code. If it's not my eyes or the screen itself, the pb will be in the cursor update code path from the xserver down to the driver... The bottom of it is if I happened to see a system which has mouse motion which looks smooth for my eyes at 60Hz, I would get back to you on this issue. regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Disable mdp5 crtc when there are no active planes
Unlike other compositors, we don't get a crtc disable from weston when the cable is unplugged. As such, when the cable is re-plugged the kernel doesn't detect an enable/mode change and initiates a simple plane update instead of a modeset. This patch clears the mode when all planes are off. Signed-off-by: Sean Paul --- Sorry for the wide distribution, I'm not 100% on whether this is the right place to fix this. Is this expected behavior from weston? Once we have solid fill support, it seems reasonable that a crtc might be left on if no planes are active (for blanking the screen, etc). However, hotplug is currently borked, so I don't want to just leave it as-is if this should be handled in the kernel. Suggestions welcome! Sean drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c index 63dcc39b5efd..e89e46a4014e 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c @@ -645,7 +645,7 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc, /* bail out early if there aren't any planes */ if (!cnt) - return 0; + return drm_atomic_set_mode_for_crtc(state, NULL); hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 9/9] ARM: dts: bcm283x: Add Transposer block
Boris Brezillon writes: > 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 I've pulled this one to bcm2835-dt-next. The drm-misc-next commits will be up to you. signature.asc Description: PGP signature ___ 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 #12 from dwagner --- (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. While I can start X11 with this patch applied to current amd-staging-drm-next, attempts to resume from S3 fail consistently. The following related output is emitted right before the suspend: Jul 02 21:31:32 ryzen kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. Jul 02 21:31:32 ryzen kernel: Suspending console(s) (use no_console_suspend to debug) Jul 02 21:31:32 ryzen kernel: sd 9:0:0:0: [sda] Synchronizing SCSI cache Jul 02 21:31:32 ryzen kernel: [TTM] Buffer eviction failed Jul 02 21:31:32 ryzen kernel: ACPI: Preparing to enter system sleep state S3 Jul 02 21:31:32 ryzen kernel: PM: Saving platform NVS memory Jul 02 21:31:32 ryzen kernel: Disabling non-boot CPUs ... (I wonder if that "[TTM] Buffer eviction failed" is a bad sign - as I have seen it some other times in conjunction with heavy uses of the amdgpu driver.) Then, upon resume, the following messages are emitted: Jul 02 21:31:33 ryzen kernel: ACPI: Low-level resume complete Jul 02 21:31:33 ryzen kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40030). Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 146 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 148 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 145 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 146 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 189 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 306 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 5e ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 18a ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 145 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 146 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 148 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 145 ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] last message was failed ret is 0 Jul 02 21:31:33 ryzen kernel: amdgpu: [powerplay] failed to send message 146 ret is 0 Jul 02 21:31:33 ryzen kernel: [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xC> Jul 02 21:31:33 ryzen kernel: [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -22 Jul 02 21:31:33 ryzen kernel: [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-22). Jul 02 21:31:33 ryzen kernel: dpm_run_callback(): pci_pm_resume+0x0/0xa0 returns -22 Jul 02 21:31:33 ryzen kernel: PM: Device :0a:00.0 failed to resume async: error -22 Jul 02 21:31:33 ryzen kernel: OOM killer enabled. Jul 02 21:31:33 ryzen kernel: Restarting tasks ... done. Jul 02 21:31:
Re: [PATCH v3 8/9] drm/vc4: Add support for the transposer block
On Mon, 02 Jul 2018 11:52:58 -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 > > --- > > Changes in v3: > > - Add Eric's R-b > > I don't see it, but the cleanups all look good to me so go ahead and add > it :) One more reason to send a v4 ;-). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 8/9] drm/vc4: Add support for the transposer block
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 > --- > Changes in v3: > - Add Eric's R-b I don't see it, but the cleanups all look good to me so go ahead and add it :) signature.asc Description: PGP signature ___ 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 Mon, Jul 2, 2018 at 5:41 PM, Russell King - ARM Linux wrote: > On Mon, Jul 02, 2018 at 10:47:03AM +0200, Daniel Vetter wrote: >> On Sun, Jul 01, 2018 at 04:34:02PM +0100, Russell King - ARM Linux wrote: >> > > 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. > > However, isn't there a problem in doing that, as going through the > transition process means you: > 1. switch planes to use the plane transitional helpers > 2. migrate crtc to mode_set_nofb() > 3. migrate page_flip to use a transitional implementation > 4. clean up to use the plane state for all properties > 5. switch to atomic modeset by adding .atomic_check / .atomic_commit >and DRIVER_ATOMIC flag > 6. migrate away from transitional helpers > > as separate stages - which means there's a brief period where you have > the .atomic_commit method populated (and hence > drm_drv_uses_atomic_modeset() returns true) but the transitional > helpers are still being used. > > I've found if you do (5) and (6) in one go, it becomes quite a large > set of changes: > > drivers/gpu/drm/armada/armada_crtc.c| 308 > +--- > drivers/gpu/drm/armada/armada_crtc.h| 20 --- > drivers/gpu/drm/armada/armada_overlay.c | 175 -- > drivers/gpu/drm/armada/armada_plane.c | 4 +- > 4 files changed, 36 insertions(+), 471 deletions(-) Hm yeah that doesn't work. I'd say that's perhaps cleanup work for someone bored after armada atomic has landed. I also think that after armada it probably makes sense to drop the transitional helpers. Anyone else trying to do a legacy2atomic conversion can dig them out of the git history and just carry them around in their driver for the transition. That also avoids the constant headaches of them breaking accidentally all the time. -Daniel >> 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(). > > Hmm, that's something else I've missed in my conversion... thanks for > pointing it out. ;) > >> - 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. > > Ok, I've a commit for that - I just need to merge it with the one I > already have adding the ctx argument, grab drm-misc-next and make sure > it applies there... I'll try to get it out in shortly. > > -- > 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/vmwgfx: Use drm_plane_mask() & co.
Reviewed-by: Sinclair Yeh
I assume you'll upstream this as part of your series?
On Tue, Jun 26, 2018 at 10:47:16PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_{plane,connector}_mask() where appropriate.
>
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index ef96ba7432ad..17e01423ead1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -535,9 +535,9 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
>struct drm_crtc_state *new_state)
> {
> struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
> - int connector_mask = 1 << drm_connector_index(&du->connector);
> + int connector_mask = drm_connector_mask(&du->connector);
> bool has_primary = new_state->plane_mask &
> -BIT(drm_plane_index(crtc->primary));
> +drm_plane_mask(crtc->primary);
>
> /* We always want to have an active plane with an active CRTC */
> if (has_primary != new_state->enable)
> --
> 2.16.4
>
___
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 #14 from Michel Dänzer (mic...@daenzer.net) --- Another possibility would be narrowing down where between 4.4 and 4.16 this started happening, and eventually bisecting. -- 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: [amdgpu][tahiti xt] cursor motion smoothness
On 2018-07-02 05:28 PM, sylvain.bertr...@gmail.com wrote: > On Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote: > >> Sounds like maybe DOTA doesn't use the X11 cursor (which would end up >> using the HW cursor), but renders the cursor as part of its scene. > > Probably, but it happens only at 60Hz. Unless DOTA runs steadily at >= 60 Hz, there will sometimes be >= 33 ms between consecutive visible mouse cursor positions. This is correspondingly lower at higher refresh rate. > hum... the log was filtered out somewhere... FWIW, I think I saw a bounce e-mail mentioning attachments being filtered due to them having multiple file name extensions. (BTW, it looks like your mailer gets confused by my name or e-mail address as well) > Sending the logs as direct email to your personal email box. Does using xf86-input-libinput instead of xf86-input-evdev 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: [PATCH v3 3/9] drm/connector: Make ->atomic_commit() optional
On Mon, 2 Jul 2018 23:30:05 +0800
kbuild test robot wrote:
> Hi Boris,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20180702]
> [cannot apply to drm/drm-next anholt/for-next robh/for-next v4.18-rc3
> v4.18-rc2 v4.18-rc1 v4.18-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-vc4-Add-support-for-the-transposer-IP/20180702-211805
> config: x86_64-randconfig-x015-201826 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu//drm/drm_atomic_helper.c: In function
> 'drm_atomic_helper_commit_writebacks':
> >> drivers/gpu//drm/drm_atomic_helper.c:1187:13: error: 'const struct
> >> drm_connector_helper_funcs' has no member named 'funcs'
> if (!funcs->funcs->atomic_commit)
> ^~
>
> vim +1187 drivers/gpu//drm/drm_atomic_helper.c
>
> 1175
> 1176static void drm_atomic_helper_commit_writebacks(struct
> drm_device *dev,
> 1177struct
> drm_atomic_state *old_state)
> 1178{
> 1179struct drm_connector *connector;
> 1180struct drm_connector_state *new_conn_state;
> 1181int i;
> 1182
> 1183for_each_new_connector_in_state(old_state, connector,
> new_conn_state, i) {
> 1184const struct drm_connector_helper_funcs *funcs;
> 1185
> 1186funcs = connector->helper_private;
> > 1187if (!funcs->funcs->atomic_commit)
Oh, shame on me! :-)
I'll send a v4 with this build failure fixed, and this time I'll
compile-test at least. :-)
> 1188continue;
> 1189
> 1190if (new_conn_state->writeback_job &&
> new_conn_state->writeback_job->fb) {
> 1191WARN_ON(connector->connector_type !=
> DRM_MODE_CONNECTOR_WRITEBACK);
> 1192funcs->atomic_commit(connector,
> new_conn_state);
> 1193}
> 1194}
> 1195}
> 1196
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
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 Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote: > Is the behaviour different with the Xorg modesetting driver and/or the > radeon kernel driver? Tested both. Same thing than with amdgpu. -- Sylvain ___ 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 #13 from phoenix (fe...@feldspaten.org) --- Having some problems setting up kmemleak at the moment. I'll test and check tomorrow -- 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 00/10] Improve crc-core driver interface
+ Harry and Leo On Mon, Jul 2, 2018 at 7:07 AM, Mahesh Kumar wrote: > 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 ___ 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 #12 from phoenix (fe...@feldspaten.org) --- I'm rebuilding the kernel and checking a possible memory leak with kmemleak. -- 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 v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
On 07/02/2018 08:54 AM, Noralf Trønnes wrote: Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has moved to drm_fbdev_generic_setup(). Cc: Laurent Pinchart Signed-off-by: Noralf Trønnes --- Reviewed-by: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic-helper: Use old/new state in drm_atomic_helper_commit_planes_on_crtc()
On Wed, Jun 27, 2018 at 10:59:49AM +0200, Daniel Vetter wrote:
> On Tue, Jun 26, 2018 at 11:41:44PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Update drm_atomic_helper_commit_planes_on_crtc() to use explicit old/new
> > states instead of relying on obj->state.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Daniel Vetter
Thansk. Pushed to drm-misc-next.
>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 15 ++-
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index e022cacdae34..8008a7de2e10 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2342,11 +2342,13 @@ drm_atomic_helper_commit_planes_on_crtc(struct
> > drm_crtc_state *old_crtc_state)
> > const struct drm_crtc_helper_funcs *crtc_funcs;
> > struct drm_crtc *crtc = old_crtc_state->crtc;
> > struct drm_atomic_state *old_state = old_crtc_state->state;
> > + struct drm_crtc_state *new_crtc_state =
> > + drm_atomic_get_new_crtc_state(old_state, crtc);
> > struct drm_plane *plane;
> > unsigned plane_mask;
> >
> > plane_mask = old_crtc_state->plane_mask;
> > - plane_mask |= crtc->state->plane_mask;
> > + plane_mask |= new_crtc_state->plane_mask;
> >
> > crtc_funcs = crtc->helper_private;
> > if (crtc_funcs && crtc_funcs->atomic_begin)
> > @@ -2355,6 +2357,8 @@ drm_atomic_helper_commit_planes_on_crtc(struct
> > drm_crtc_state *old_crtc_state)
> > drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
> > struct drm_plane_state *old_plane_state =
> > drm_atomic_get_old_plane_state(old_state, plane);
> > + struct drm_plane_state *new_plane_state =
> > + drm_atomic_get_new_plane_state(old_state, plane);
> > const struct drm_plane_helper_funcs *plane_funcs;
> >
> > plane_funcs = plane->helper_private;
> > @@ -2362,13 +2366,14 @@ drm_atomic_helper_commit_planes_on_crtc(struct
> > drm_crtc_state *old_crtc_state)
> > if (!old_plane_state || !plane_funcs)
> > continue;
> >
> > - WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
> > + WARN_ON(new_plane_state->crtc &&
> > + new_plane_state->crtc != crtc);
> >
> > - if (drm_atomic_plane_disabling(old_plane_state, plane->state) &&
> > + if (drm_atomic_plane_disabling(old_plane_state,
> > new_plane_state) &&
> > plane_funcs->atomic_disable)
> > plane_funcs->atomic_disable(plane, old_plane_state);
> > - else if (plane->state->crtc ||
> > -drm_atomic_plane_disabling(old_plane_state,
> > plane->state))
> > + else if (new_plane_state->crtc ||
> > +drm_atomic_plane_disabling(old_plane_state,
> > new_plane_state))
> > plane_funcs->atomic_update(plane, old_plane_state);
> > }
> >
> > --
> > 2.16.4
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm: Add drm_plane_mask()
On Tue, Jun 26, 2018 at 01:09:53PM -0700, Rodrigo Vivi wrote:
> On Tue, Jun 26, 2018 at 10:47:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add drm_plane_mask() which returns the 1< > We already have an identical drm_crtc_mask() for crtcs.
> >
> > Mostly performed with coccinelle:
> > @@
> > @@
> > - (1< > + drm_plane_mask(
> > ...)
> > - )
> >
> > @@
> > @@
> > - 1< > + drm_plane_mask(
> > ...)
> >
> > @@
> > @@
> > - BIT(drm_plane_index(
> > + drm_plane_mask(
> > ...)
> > - )
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Rodrigo Vivi
Series pushed to drm-misc-next. Thanks for the reviews/acks.
>
> > ---
> > drivers/gpu/drm/drm_atomic.c| 4 ++--
> > drivers/gpu/drm/drm_framebuffer.c | 2 +-
> > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> > include/drm/drm_plane.h | 14 --
> > 4 files changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 178842380f75..684c9d3a1d6c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1581,7 +1581,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state
> > *plane_state,
> > if (WARN_ON(IS_ERR(crtc_state)))
> > return PTR_ERR(crtc_state);
> >
> > - crtc_state->plane_mask &= ~(1 << drm_plane_index(plane));
> > + crtc_state->plane_mask &= ~drm_plane_mask(plane);
> > }
> >
> > plane_state->crtc = crtc;
> > @@ -1591,7 +1591,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state
> > *plane_state,
> >crtc);
> > if (IS_ERR(crtc_state))
> > return PTR_ERR(crtc_state);
> > - crtc_state->plane_mask |= (1 << drm_plane_index(plane));
> > + crtc_state->plane_mask |= drm_plane_mask(plane);
> > }
> >
> > if (crtc)
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index ed90974a452a..781af1d42d76 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -847,7 +847,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> > if (ret)
> > goto unlock;
> >
> > - plane_mask |= BIT(drm_plane_index(plane));
> > + plane_mask |= drm_plane_mask(plane);
> > }
> >
> > /* This list is only filled when disable_crtcs is set. */
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 7a00455ca568..9d87961da1db 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -52,7 +52,7 @@ static int drm_simple_kms_crtc_check(struct drm_crtc
> > *crtc,
> > struct drm_crtc_state *state)
> > {
> > bool has_primary = state->plane_mask &
> > - BIT(drm_plane_index(crtc->primary));
> > + drm_plane_mask(crtc->primary);
> >
> > /* We always want to have an active plane with an active CRTC */
> > if (has_primary != state->enable)
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 7d4d6c7f0afd..cee9dfaaa740 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -639,10 +639,20 @@ void drm_plane_cleanup(struct drm_plane *plane);
> > * Given a registered plane, return the index of that plane within a DRM
> > * device's list of planes.
> > */
> > -static inline unsigned int drm_plane_index(struct drm_plane *plane)
> > +static inline unsigned int drm_plane_index(const struct drm_plane *plane)
> > {
> > return plane->index;
> > }
> > +
> > +/**
> > + * drm_plane_mask - find the mask of a registered plane
> > + * @plane: plane to find mask for
> > + */
> > +static inline u32 drm_plane_mask(const struct drm_plane *plane)
> > +{
> > + return 1 << drm_plane_index(plane);
> > +}
> > +
> > struct drm_plane * drm_plane_from_index(struct drm_device *dev, int idx);
> > void drm_plane_force_disable(struct drm_plane *plane);
> >
> > @@ -678,7 +688,7 @@ static inline struct drm_plane *drm_plane_find(struct
> > drm_device *dev,
> > */
> > #define drm_for_each_plane_mask(plane, dev, plane_mask) \
> > list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
> > - for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
> > + for_each_if ((plane_mask) & drm_plane_mask(plane))
> >
> > /**
> > * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
> > --
> > 2.16.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.f
Re: [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()
On 07/02/2018 08:54 AM, Noralf Trønnes wrote: Make full use of the generic fbdev client. Cc: David Lechner Signed-off-by: Noralf Trønnes --- Reviewed-by: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the current media master branch (https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top of the current mainline tree. This patch series has been tested with my NUC7i5BNK, a Google USB-C to HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI adapter (where the CEC pin is wired up). The latter is to check that replacing a USB-C to HDMI adapter by a USB-C MST Hub works correctly. CEC for MST is currently not supported. Please note this comment at the start of drm_dp_cec.c: -- Unfortunately it turns out that we have a chicken-and-egg situation here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters have a converter chip that supports CEC-Tunneling-over-AUX (usually the Parade PS176), but they do not wire up the CEC pin, thus making CEC useless. Sadly there is no way for this driver to know this. What happens is that a /dev/cecX device is created that is isolated and unable to see any of the other CEC devices. Quite literally the CEC wire is cut (or in this case, never connected in the first place). The reason so few adapters support this is that this tunneling protocol was never supported by any OS. So there was no easy way of testing it, and no incentive to correctly wire up the CEC pin. Hopefully by creating this driver it will be easier for vendors to finally fix their adapters and test the CEC functionality. I keep a list of known working adapters here: https://hverkuil.home.xs4all.nl/cec-status.txt Please mail me (hverk...@xs4all.nl) if you find an adapter that works and is not yet listed there. Note that the current implementation does not support CEC over an MST hub. As far as I can see there is no mechanism defined in the DisplayPort standard to transport CEC interrupts over an MST device. It might be possible to do this through polling, but I have not been able to get that to work. -- I really hope that this work will provide an incentive for vendors to finally connect the CEC pin. It's a shame that there are so few adapters that work (I found only three USB-C to HDMI adapters that work, and no (mini-)DP to HDMI adapters at all). It is a very nice feature for HTPC boxes. This v8 incorporates Ville's suggested cleanups from his review of v7 and it adds his Reviewed-by tag. Regards, Hans Changes since v7: - Drop unnecessary aux->cec.adap check from drm_dp_cec_unregister_work() - Cancel unregister_work at the start of drm_dp_cec_unset_edid(). This simplifies the remainder of the code in that function. Changes since v6: - Made struct edid const in drm_dp_cec_set_edid() - Changed drm_dp_cec_unregister_delay behavior: 0 == no unregister delay, >= 1000 == never unregister. - Fixed potential deadlock in drm_dp_cec_unset_edid(). - Moved all cec fields in struct drm_dp_aux to a struct drm_dp_aux_cec. Changes since v5: - Moved the logic of when to unregister a CEC adapter to the drm core code, since this is independent of the actual driver implementation. - Simplified the calls the driver needs to make: the core code is informed when a connector is (un)registered, when the EDID is unset or set and when a DP short pulse is seen and you need to check if that is for a CEC interrupt. - Added the drm_dp_cec_unregister_delay module option to set the delay between unsetting the EDID and unregistering the CEC adapter. Changes since v4: - Updated comment at the start of drm_dp_cec.c - Add edid pointer to drm_dp_cec_configure_adapter - Reworked the last patch (adding CEC to i915) based on Ville's comments and my MST testing: - register/unregister CEC in intel_dp_connector_register/unregister - add comment and check if connector is registered in long_pulse - unregister CEC if an MST 'connector' is detected. Hans Verkuil (3): drm: add support for DisplayPort CEC-Tunneling-over-AUX drm-kms-helpers.rst: document the DP CEC helpers drm/i915: add DisplayPort CEC-Tunneling-over-AUX support Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_dp_cec.c | 427 ++ drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 17 +- include/drm/drm_dp_helper.h | 56 7 files changed, 519 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_cec.c -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even though a CEC device is created, it may not actually work. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/Kconfig | 10 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_dp_cec.c| 427 drivers/gpu/drm/drm_dp_helper.c | 1 + include/drm/drm_dp_helper.h | 56 + 5 files changed, 495 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_cec.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 2a72d2feb76d..d5e217fd0c14 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -122,6 +122,16 @@ config DRM_LOAD_EDID_FIRMWARE default case is N. Details and instructions how to build your own EDID data are given in Documentation/EDID/HOWTO.txt. +config DRM_DP_CEC + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" + select CEC_CORE + help + Choose this option if you want to enable HDMI CEC support for + DisplayPort/USB-C to HDMI adapters. + + Note: not all adapters support this feature, and even for those + that do support this they often do not hook up the CEC pin. + config DRM_TTM tristate depends on DRM && MMU diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ef9f3dab287f..270266cc6eca 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c new file mode 100644 index ..87b67cc1ea58 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -0,0 +1,427 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DisplayPort CEC-Tunneling-over-AUX support + * + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + */ + +#include +#include +#include +#include +#include + +/* + * Unfortunately it turns out that we have a chicken-and-egg situation + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the + * Parade PS176), but they do not wire up the CEC pin, thus making CEC + * useless. + * + * Sadly there is no way for this driver to know this. What happens is + * that a /dev/cecX device is created that is isolated and unable to see + * any of the other CEC devices. Quite literally the CEC wire is cut + * (or in this case, never connected in the first place). + * + * The reason so few adapters support this is that this tunneling protocol + * was never supported by any OS. So there was no easy way of testing it, + * and no incentive to correctly wire up the CEC pin. + * + * Hopefully by creating this driver it will be easier for vendors to + * finally fix their adapters and test the CEC functionality. + * + * I keep a list of known working adapters here: + * + * https://hverkuil.home.xs4all.nl/cec-status.txt + * + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works + * and is not yet listed there. + * + * Note that the current implementation does not support CEC over an MST hub. + * As far as I can see there is no mechanism defined in the DisplayPort + * standard to transport CEC interrupts over an MST device. It might be + * possible to do this through polling, but I have not been able to get that + * to work. + */ + +/** + * DOC: dp cec helpers + * + * These functions take care of supporting the CEC-Tunneling-over-AUX + * feature of DisplayPort-to-HDMI adapters. + */ + +/* + * When the EDID is unset because the HPD went low, then the CEC DPCD registers + * typically can no longer be read (true for a DP-to-HDMI adapter since it is + * powered by the HPD). However, some displays toggle the HPD off and on for a + * short period for one reason or another, and that would cause the CEC adapter + * to be removed and added again, even though nothing else changed. + * + * This module parameter sets a delay in seconds before the CEC adapter is + * actually unregistered. Only if the HPD does not return within that time will + * the CEC adapter be unregistered. + * + * If it is set to a value >= NEVER_UNREG_DELAY, then the CEC adapter will never + * be unregistered for as long as the connector remains registered. + * + * If it is set to 0, then the CEC adapter will be
[PATCHv8 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 16faea30114a..c3045262eba1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4466,6 +4466,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
+ /* Handle CEC interrupts, if any */
+ drm_dp_cec_irq(&intel_dp->aux);
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -4780,6 +4783,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ drm_dp_cec_set_edid(&intel_dp->aux, edid);
}
static void
@@ -4787,6 +4791,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ drm_dp_cec_unset_edid(&intel_dp->aux);
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
@@ -4975,6 +4980,7 @@ static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_device *dev = connector->dev;
int ret;
ret = intel_connector_register(connector);
@@ -4987,13 +4993,20 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
- return drm_dp_aux_register(&intel_dp->aux);
+ ret = drm_dp_aux_register(&intel_dp->aux);
+ if (!ret)
+ drm_dp_cec_register_connector(&intel_dp->aux,
+ connector->name, dev->dev);
+ return ret;
}
static void
intel_dp_connector_unregister(struct drm_connector *connector)
{
- drm_dp_aux_unregister(&intel_attached_dp(connector)->aux);
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+
+ drm_dp_cec_unregister_connector(&intel_dp->aux);
+ drm_dp_aux_unregister(&intel_dp->aux);
intel_connector_unregister(connector);
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 2/3] drm-kms-helpers.rst: document the DP CEC helpers
From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index e37557b30f62..62de583e9efe 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -169,6 +169,15 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c :export: +Display Port CEC Helper Functions Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :doc: dp cec helpers + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :export: + Display Port Dual Mode Adaptor Helper Functions Reference = -- 2.18.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 Christian König (christian.koe...@amd.com) changed: What|Removed |Added CC||christian.koe...@amd.com --- Comment #11 from Christian König (christian.koe...@amd.com) --- You could also try to compile your kernel with kmemleak enabled. -- 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 v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
Looks good: Acked-by: Christoph Hellwig ___ 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
Hi Boris,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20180702]
[cannot apply to drm/drm-next anholt/for-next robh/for-next v4.18-rc3 v4.18-rc2
v4.18-rc1 v4.18-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-vc4-Add-support-for-the-transposer-IP/20180702-211805
config: x86_64-randconfig-x015-201826 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu//drm/drm_atomic_helper.c: In function
'drm_atomic_helper_commit_writebacks':
>> drivers/gpu//drm/drm_atomic_helper.c:1187:13: error: 'const struct
>> drm_connector_helper_funcs' has no member named 'funcs'
if (!funcs->funcs->atomic_commit)
^~
vim +1187 drivers/gpu//drm/drm_atomic_helper.c
1175
1176 static void drm_atomic_helper_commit_writebacks(struct drm_device *dev,
1177 struct drm_atomic_state
*old_state)
1178 {
1179 struct drm_connector *connector;
1180 struct drm_connector_state *new_conn_state;
1181 int i;
1182
1183 for_each_new_connector_in_state(old_state, connector,
new_conn_state, i) {
1184 const struct drm_connector_helper_funcs *funcs;
1185
1186 funcs = connector->helper_private;
> 1187 if (!funcs->funcs->atomic_commit)
1188 continue;
1189
1190 if (new_conn_state->writeback_job &&
new_conn_state->writeback_job->fb) {
1191 WARN_ON(connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
1192 funcs->atomic_commit(connector, new_conn_state);
1193 }
1194 }
1195 }
1196
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] drm/connector: Make ->atomic_commit() optional
Hi Boris,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180702]
[cannot apply to drm/drm-next anholt/for-next robh/for-next v4.18-rc3 v4.18-rc2
v4.18-rc1 v4.18-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-vc4-Add-support-for-the-transposer-IP/20180702-211805
config: x86_64-randconfig-x010-201826 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/drm_atomic_helper.c:28:
drivers/gpu/drm/drm_atomic_helper.c: In function
'drm_atomic_helper_commit_writebacks':
drivers/gpu/drm/drm_atomic_helper.c:1187:13: error: 'const struct
drm_connector_helper_funcs' has no member named 'funcs'
if (!funcs->funcs->atomic_commit)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/drm_atomic_helper.c:1187:3: note: in expansion of macro 'if'
if (!funcs->funcs->atomic_commit)
^~
drivers/gpu/drm/drm_atomic_helper.c:1187:13: error: 'const struct
drm_connector_helper_funcs' has no member named 'funcs'
if (!funcs->funcs->atomic_commit)
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/drm_atomic_helper.c:1187:3: note: in expansion of macro 'if'
if (!funcs->funcs->atomic_commit)
^~
drivers/gpu/drm/drm_atomic_helper.c:1187:13: error: 'const struct
drm_connector_helper_funcs' has no member named 'funcs'
if (!funcs->funcs->atomic_commit)
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers/gpu/drm/drm_atomic_helper.c:1187:3: note: in expansion of macro 'if'
if (!funcs->funcs->atomic_commit)
^~
vim +/if +1187 drivers/gpu/drm/drm_atomic_helper.c
1175
1176 static void drm_atomic_helper_commit_writebacks(struct drm_device *dev,
1177 struct drm_atomic_state
*old_state)
1178 {
1179 struct drm_connector *connector;
1180 struct drm_connector_state *new_conn_state;
1181 int i;
1182
1183 for_each_new_connector_in_state(old_state, connector,
new_conn_state, i) {
1184 const struct drm_connector_helper_funcs *funcs;
1185
1186 funcs = connector->helper_private;
> 1187 if (!funcs->funcs->atomic_commit)
1188 continue;
1189
1190 if (new_conn_state->writeback_job &&
new_conn_state->writeback_job->fb) {
1191 WARN_ON(connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
1192 funcs->atomic_commit(connector, new_conn_state);
1193 }
1194 }
1195 }
1196
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
v3: Initialize nv_encoder to NULL to shut up gcc/smatch
Cc: Dan Carpenter
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher #v1
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7b557c354307..bb46c1d489cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -363,19 +363,11 @@ module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
struct nouveau_encoder *
find_encoder(struct drm_connector *connector, int type)
{
- struct drm_device *dev = connector->dev;
struct nouveau_encoder *nv_encoder;
struct drm_encoder *enc;
- int i, id;
-
- for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- id = connector->encoder_ids[i];
- if (!id)
- break;
+ int i;
- enc = drm_encoder_find(dev, NULL, id);
- if (!enc)
- continue;
+ drm_connector_for_each_possible_encoder(connector, enc, i) {
nv_encoder = nouveau_encoder(enc);
if (type == DCB_OUTPUT_ANY ||
@@ -420,7 +412,7 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_gpio *gpio = nvxx_gpio(&drm->client.device);
- struct nouveau_encoder *nv_encoder;
+ struct nouveau_encoder *nv_encoder = NULL;
struct drm_encoder *encoder;
int i, panel = -ENODEV;
@@ -436,14 +428,7 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
}
}
- for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- int id = connector->encoder_ids[i];
- if (id == 0)
- break;
-
- encoder = drm_encoder_find(dev, NULL, id);
- if (!encoder)
- continue;
+ drm_connector_for_each_possible_encoder(connector, encoder, i) {
nv_encoder = nouveau_encoder(encoder);
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
--
2.16.4
___
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 Mon, Jul 02, 2018 at 04:22:47PM +0200, Michel Dänzer wrote: > I'm afraid I'm still not sure what "blurry motion" means exactly. Like the mouse cursor location is updated very slowly, and that, only at 60Hz. (in dota2, it looks like sub-30Hz with lag). > Is the behaviour different with the Xorg modesetting driver and/or the > radeon kernel driver? I don't know, I would need to setup these and test (my custom distro is made for amdgpu). > Sounds like maybe DOTA doesn't use the X11 cursor (which would end up > using the HW cursor), but renders the cursor as part of its scene. Probably, but it happens only at 60Hz. hum... the log was filtered out somewhere... Sending the logs as direct email to your personal email box. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On 02/07/18 16:55, Ville Syrjälä wrote: > On Thu, Jun 28, 2018 at 09:42:51AM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This adds support for the DisplayPort CEC-Tunneling-over-AUX >> feature that is part of the DisplayPort 1.3 standard. >> >> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a >> chip that has this capability actually hook up the CEC pin, so >> even though a CEC device is created, it may not actually work. >> >> Signed-off-by: Hans Verkuil >> --- >> drivers/gpu/drm/Kconfig | 10 + >> drivers/gpu/drm/Makefile| 1 + >> drivers/gpu/drm/drm_dp_cec.c| 433 >> drivers/gpu/drm/drm_dp_helper.c | 1 + >> include/drm/drm_dp_helper.h | 56 + >> 5 files changed, 501 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_dp_cec.c >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 2a72d2feb76d..d5e217fd0c14 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -122,6 +122,16 @@ config DRM_LOAD_EDID_FIRMWARE >>default case is N. Details and instructions how to build your own >>EDID data are given in Documentation/EDID/HOWTO.txt. >> >> +config DRM_DP_CEC >> +bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" >> +select CEC_CORE >> +help >> + Choose this option if you want to enable HDMI CEC support for >> + DisplayPort/USB-C to HDMI adapters. >> + >> + Note: not all adapters support this feature, and even for those >> + that do support this they often do not hook up the CEC pin. >> + >> config DRM_TTM >> tristate >> depends on DRM && MMU >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index ef9f3dab287f..270266cc6eca 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o >> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o >> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o >> drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o >> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o >> >> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o >> obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ >> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c >> new file mode 100644 >> index ..1530ca685955 >> --- /dev/null >> +++ b/drivers/gpu/drm/drm_dp_cec.c >> @@ -0,0 +1,433 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * DisplayPort CEC-Tunneling-over-AUX support >> + * >> + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights >> reserved. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* >> + * Unfortunately it turns out that we have a chicken-and-egg situation >> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters >> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the >> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC >> + * useless. >> + * >> + * Sadly there is no way for this driver to know this. What happens is >> + * that a /dev/cecX device is created that is isolated and unable to see >> + * any of the other CEC devices. Quite literally the CEC wire is cut >> + * (or in this case, never connected in the first place). >> + * >> + * The reason so few adapters support this is that this tunneling protocol >> + * was never supported by any OS. So there was no easy way of testing it, >> + * and no incentive to correctly wire up the CEC pin. >> + * >> + * Hopefully by creating this driver it will be easier for vendors to >> + * finally fix their adapters and test the CEC functionality. >> + * >> + * I keep a list of known working adapters here: >> + * >> + * https://hverkuil.home.xs4all.nl/cec-status.txt >> + * >> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works >> + * and is not yet listed there. >> + * >> + * Note that the current implementation does not support CEC over an MST >> hub. >> + * As far as I can see there is no mechanism defined in the DisplayPort >> + * standard to transport CEC interrupts over an MST device. It might be >> + * possible to do this through polling, but I have not been able to get that >> + * to work. >> + */ >> + >> +/** >> + * DOC: dp cec helpers >> + * >> + * These functions take care of supporting the CEC-Tunneling-over-AUX >> + * feature of DisplayPort-to-HDMI adapters. >> + */ >> + >> +/* >> + * When the EDID is unset because the HPD went low, then the CEC DPCD >> registers >> + * typically can no longer be read (true for a DP-to-HDMI adapter since it >> is >> + * powered by the HPD). However, some displays toggle the HPD off and on >> for a >> + * short period for one reason or another, and that would cause the CEC >> adapter >> + * to be removed and added again, even though nothing else chang
[Bug 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #10 from phoenix (fe...@feldspaten.org) --- I uploaded all the requested files. Interestingly the output of top and statm of the process has comparable values except for the data stack (see file stats) Virtual, resident and shared memory are comparable. If you need any further data don't hesitate to ask. Thank you -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #9 from phoenix (fe...@feldspaten.org) --- Created attachment 277131 --> https://bugzilla.kernel.org/attachment.cgi?id=277131&action=edit Output of top of the problematic process on the two Kernels Truncated output of top of the problematic process on the two kernels -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #8 from phoenix (fe...@feldspaten.org) --- Created attachment 277129 --> https://bugzilla.kernel.org/attachment.cgi?id=277129&action=edit Free and stats of the two Kernels Contains free and the /proc/$ID/stat and /proc/$ID/statm output of the two Kernel versions -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #7 from phoenix (fe...@feldspaten.org) --- Created attachment 277127 --> https://bugzilla.kernel.org/attachment.cgi?id=277127&action=edit Xorg log on 4.4.0 -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #6 from phoenix (fe...@feldspaten.org) --- Created attachment 277125 --> https://bugzilla.kernel.org/attachment.cgi?id=277125&action=edit Xorg Log on 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
[Bug 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #5 from phoenix (fe...@feldspaten.org) --- Created attachment 277123 --> https://bugzilla.kernel.org/attachment.cgi?id=277123&action=edit dmesg on Kernel 4.4.0 -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 --- Comment #4 from phoenix (fe...@feldspaten.org) --- Created attachment 277121 --> https://bugzilla.kernel.org/attachment.cgi?id=277121&action=edit dmesg Kernel 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: [PATCHv7 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On Thu, Jun 28, 2018 at 09:42:51AM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > This adds support for the DisplayPort CEC-Tunneling-over-AUX > feature that is part of the DisplayPort 1.3 standard. > > Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a > chip that has this capability actually hook up the CEC pin, so > even though a CEC device is created, it may not actually work. > > Signed-off-by: Hans Verkuil > --- > drivers/gpu/drm/Kconfig | 10 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/drm_dp_cec.c| 433 > drivers/gpu/drm/drm_dp_helper.c | 1 + > include/drm/drm_dp_helper.h | 56 + > 5 files changed, 501 insertions(+) > create mode 100644 drivers/gpu/drm/drm_dp_cec.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 2a72d2feb76d..d5e217fd0c14 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -122,6 +122,16 @@ config DRM_LOAD_EDID_FIRMWARE > default case is N. Details and instructions how to build your own > EDID data are given in Documentation/EDID/HOWTO.txt. > > +config DRM_DP_CEC > + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" > + select CEC_CORE > + help > + Choose this option if you want to enable HDMI CEC support for > + DisplayPort/USB-C to HDMI adapters. > + > + Note: not all adapters support this feature, and even for those > + that do support this they often do not hook up the CEC pin. > + > config DRM_TTM > tristate > depends on DRM && MMU > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index ef9f3dab287f..270266cc6eca 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -41,6 +41,7 @@ drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o > +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o > > obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o > obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c > new file mode 100644 > index ..1530ca685955 > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_cec.c > @@ -0,0 +1,433 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * DisplayPort CEC-Tunneling-over-AUX support > + * > + * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights > reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +/* > + * Unfortunately it turns out that we have a chicken-and-egg situation > + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters > + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the > + * Parade PS176), but they do not wire up the CEC pin, thus making CEC > + * useless. > + * > + * Sadly there is no way for this driver to know this. What happens is > + * that a /dev/cecX device is created that is isolated and unable to see > + * any of the other CEC devices. Quite literally the CEC wire is cut > + * (or in this case, never connected in the first place). > + * > + * The reason so few adapters support this is that this tunneling protocol > + * was never supported by any OS. So there was no easy way of testing it, > + * and no incentive to correctly wire up the CEC pin. > + * > + * Hopefully by creating this driver it will be easier for vendors to > + * finally fix their adapters and test the CEC functionality. > + * > + * I keep a list of known working adapters here: > + * > + * https://hverkuil.home.xs4all.nl/cec-status.txt > + * > + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works > + * and is not yet listed there. > + * > + * Note that the current implementation does not support CEC over an MST hub. > + * As far as I can see there is no mechanism defined in the DisplayPort > + * standard to transport CEC interrupts over an MST device. It might be > + * possible to do this through polling, but I have not been able to get that > + * to work. > + */ > + > +/** > + * DOC: dp cec helpers > + * > + * These functions take care of supporting the CEC-Tunneling-over-AUX > + * feature of DisplayPort-to-HDMI adapters. > + */ > + > +/* > + * When the EDID is unset because the HPD went low, then the CEC DPCD > registers > + * typically can no longer be read (true for a DP-to-HDMI adapter since it is > + * powered by the HPD). However, some displays toggle the HPD off and on for > a > + * short period for one reason or another, and that would cause the CEC > adapter > + * to be removed and added again, even though nothing else changed. > + * > + * This module parameter sets a delay in seconds before the CEC adapter is > + * actually unregistered. Only if the HPD does not return within
Re: [amdgpu][tahiti xt] cursor motion smoothness
On 2018-07-02 04:04 PM, sylvain.bertr...@gmail.com wrote: > On Mon, Jul 02, 2018 at 11:29:19AM +0200, Michel Dänzer wrote: >> 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? > > I meant cursor motion is very blury, enough I can loose its location on the > screen. I'm afraid I'm still not sure what "blurry motion" means exactly. Is the behaviour different with the Xorg modesetting driver and/or the radeon kernel driver? > And for instance, while moving the dota2 map with the grab method, at 60Hz > it looks like moving the dota2 map at a sub-30Hz with some lag. Sounds like maybe DOTA doesn't use the X11 cursor (which would end up using the HW cursor), but renders the cursor as part of its scene. Can you share the corresponding dmesg output and Xorg log file? -- 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 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Mon, Jul 02, 2018 at 04:04:45PM +0300, Ville Syrjälä wrote:
> 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 Wunner
Re: [amdgpu][tahiti xt] cursor motion smoothness
On Mon, Jul 02, 2018 at 11:29:19AM +0200, Michel Dänzer wrote: > 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? I meant cursor motion is very blury, enough I can loose its location on the screen. And for instance, while moving the dota2 map with the grab method, at 60Hz it looks like moving the dota2 map at a sub-30Hz with some lag. At 120/144Hz, cursor motion is way less blury, and dota2 map motion is smooth with the grab method. -- Sylvain Xorg.0.log.xz Description: application/xz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
On Sat, 30 Jun 2018, 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
> 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.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Yisheng Xie
> ---
> v2:
> - rebase it to fbdev-for-next branch and add one more loop to replace - per
> Hans
> - Macro should be protected against nested conditionals. - per Andy
> drivers/video/fbdev/core/fbcon.c | 31 +++
> drivers/video/fbdev/core/fbmem.c | 4 +---
> include/linux/fb.h | 4
> 3 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 5fb156b..e30d3a1 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2234,8 +2234,8 @@ static int fbcon_switch(struct vc_data *vc)
>*
>* info->currcon = vc->vc_num;
>*/
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL && registered_fb[i]->fbcon_par) {
> + for_each_registered_fb(i) {
> + if (registered_fb[i]->fbcon_par) {
> struct fbcon_ops *o = registered_fb[i]->fbcon_par;
>
> o->currcon = vc->vc_num;
> @@ -3124,11 +3124,9 @@ static int fbcon_fb_unregistered(struct fb_info *info)
> if (idx == info_idx) {
> info_idx = -1;
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL) {
> - info_idx = i;
> - break;
> - }
> + for_each_registered_fb(i) {
> + info_idx = i;
> + break;
> }
> }
>
> @@ -3609,10 +3607,8 @@ static int fbcon_output_notifier(struct notifier_block
> *nb,
> deferred_takeover = false;
> logo_shown = FBCON_LOGO_DONTSHOW;
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i])
> - fbcon_fb_registered(registered_fb[i]);
> - }
> + for_each_registered_fb(i)
> + fbcon_fb_registered(registered_fb[i]);
>
> return NOTIFY_OK;
> }
> @@ -3638,11 +3634,9 @@ static void fbcon_start(void)
>
> console_lock();
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL) {
> - info_idx = i;
> - break;
> - }
> + for_each_registered_fb(i) {
> + info_idx = i;
> + break;
> }
>
> do_fbcon_takeover(0);
> @@ -3669,15 +3663,12 @@ static void fbcon_exit(void)
> kfree((void *)softback_buf);
> softback_buf = 0UL;
>
> - for (i = 0; i < FB_MAX; i++) {
> + for_each_registered_fb(i) {
> int pending = 0;
>
> mapped = 0;
> info = registered_fb[i];
>
> - if (info == NULL)
> - continue;
> -
> if (info->queue.func)
> pending = cancel_work_sync(&info->queue);
> DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 609438d..645c6ac 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1593,10 +1593,8 @@ static int do_remove_conflicting_framebuffers(struct
> apertures_struct *a,
> int i, ret;
>
> /* check all firmware fbs and kick off if the base addr overlaps */
> - for (i = 0 ; i < FB_MAX; i++) {
> + for_each_registered_fb(i) {
> struct apertures_struct *gen_aper;
> - if (!registered_fb[i])
> - continue;
>
> if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
> continue;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index aa74a22..fd31e6f 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
> *var,
> extern int num_registered_fb;
> extern struct class *fb_class;
>
> +#define for_each_registered_fb(i)\
> + for (i = 0; i < FB_MAX; i++)\
> + if (!registered_fb[i]) {} else
There's for_each_if in drmP.h to handle dangling else. Maybe that should
be lifted outside of drm.
BR,
Jani.
> +
> extern int lock_fb_info(struct fb_info *info);
>
> static inline void unlock_fb_info(struct fb_info *info)
--
Jani Nikula, Intel Open Source Graphics Ce
[PATCH v4 7/9] drm/fb-helper: Finish the generic fbdev emulation
This adds a drm_fbdev_generic_setup() function that sets up generic
fbdev emulation with client callbacks for restore, hotplug and
unregister.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 117
include/drm/drm_fb_helper.h | 7 +++
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bea3a0cb324a..e2f0db1432aa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -67,6 +67,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* helper functions used by many drivers to implement the kernel mode setting
* interfaces.
*
+ * Drivers that support a dumb buffer with a virtual address and mmap support,
+ * should try out the generic fbdev emulation using drm_fbdev_generic_setup().
+ *
* Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
* down by calling drm_fb_helper_fbdev_teardown().
*
@@ -3118,6 +3121,120 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper
*fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_generic_probe);
+static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = {
+ .fb_probe = drm_fb_helper_generic_probe,
+};
+
+static void drm_fbdev_client_unregister(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+ if (fb_helper->fbdev) {
+ drm_fb_helper_unregister_fbi(fb_helper);
+ /* drm_fbdev_fb_destroy() takes care of cleanup */
+ return;
+ }
+
+ /* Did drm_fb_helper_fbdev_setup() run? */
+ if (fb_helper->dev)
+ drm_fb_helper_fini(fb_helper);
+
+ drm_client_release(client);
+ kfree(fb_helper);
+}
+
+static int drm_fbdev_client_restore(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+ drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+
+ return 0;
+}
+
+static int drm_fbdev_client_hotplug(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+ struct drm_device *dev = client->dev;
+ int ret;
+
+ /* If drm_fb_helper_fbdev_setup() failed, we only try once */
+ if (!fb_helper->dev && fb_helper->funcs)
+ return 0;
+
+ if (dev->fb_helper)
+ return drm_fb_helper_hotplug_event(dev->fb_helper);
+
+ if (!dev->mode_config.num_connector)
+ return 0;
+
+ ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
&drm_fb_helper_generic_funcs,
+ fb_helper->preferred_bpp, 0);
+ if (ret) {
+ fb_helper->dev = NULL;
+ fb_helper->fbdev = NULL;
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct drm_client_funcs drm_fbdev_client_funcs = {
+ .owner = THIS_MODULE,
+ .unregister = drm_fbdev_client_unregister,
+ .restore= drm_fbdev_client_restore,
+ .hotplug= drm_fbdev_client_hotplug,
+};
+
+/**
+ * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ *
+ * This function sets up generic fbdev emulation for drivers that supports
+ * dumb buffers with a virtual address and that can be mmap'ed.
+ *
+ * Restore, hotplug events and teardown are all taken care of. Drivers that do
+ * suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves.
+ * Simple drivers might use drm_mode_config_helper_suspend().
+ *
+ * Drivers that set the dirty callback on their framebuffer will get a shadow
+ * fbdev buffer that is blitted onto the real buffer. This is done in order to
+ * make deferred I/O work with all kinds of buffers.
+ *
+ * This function is safe to call even when there are no connectors present.
+ * Setup will be retried on the next hotplug event.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
+{
+ struct drm_fb_helper *fb_helper;
+ int ret;
+
+ if (!drm_fbdev_emulation)
+ return 0;
+
+ fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
+ if (!fb_helper)
+ return -ENOMEM;
+
+ ret = drm_client_new(dev, &fb_helper->client, "fbdev",
&drm_fbdev_client_funcs);
+ if (ret) {
+ kfree(fb_helper);
+ return ret;
+ }
+
+ fb_helper->preferred_bpp = preferred_bpp;
+
+ drm_fbdev_client_hotplug(&fb_helper->client);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_fbdev_generic_setup);
+
/* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT)
* but the module doesn't depend on any fb console
[Bug 107087] GPU Crash When Running Wine from Lutris
https://bugs.freedesktop.org/show_bug.cgi?id=107087 Bug ID: 107087 Summary: GPU Crash When Running Wine from Lutris Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: coolo...@gmail.com Created attachment 140426 --> https://bugs.freedesktop.org/attachment.cgi?id=140426&action=edit journalctl info GPU crashes as soon as a wine game is run from lutris, before the game even starts. Screens go blank and do not recover, though still able to ssh in. Relevant log data attached -- 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 v4 6/9] drm/debugfs: Add internal client debugfs file
Print the names of the internal clients currently attached.
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 28
drivers/gpu/drm/drm_debugfs.c | 7 +++
include/drm/drm_client.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index f05ee98bd10c..e8d7b259ff22 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -375,3 +375,31 @@ void drm_client_framebuffer_delete(struct
drm_client_buffer *buffer)
drm_client_buffer_delete(buffer);
}
EXPORT_SYMBOL(drm_client_framebuffer_delete);
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct drm_client_dev *client;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry(client, &dev->clientlist, list)
+ drm_printf(&p, "%s\n", client->name);
+ mutex_unlock(&dev->clientlist_mutex);
+
+ return 0;
+}
+
+static const struct drm_info_list drm_client_debugfs_list[] = {
+ { "internal_clients", drm_client_debugfs_internal_clients, 0 },
+};
+
+int drm_client_debugfs_init(struct drm_minor *minor)
+{
+ return drm_debugfs_create_files(drm_client_debugfs_list,
+ ARRAY_SIZE(drm_client_debugfs_list),
+ minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b2482818fee8..50a20bfc07ea 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
DRM_ERROR("Failed to create framebuffer debugfs
file\n");
return ret;
}
+
+ ret = drm_client_debugfs_init(minor);
+ if (ret) {
+ DRM_ERROR("Failed to create client debugfs file\n");
+ return ret;
+ }
}
if (dev->driver->debugfs_init) {
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 02cbb02714d8..e03ac786b0e1 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -10,6 +10,7 @@ struct drm_device;
struct drm_file;
struct drm_framebuffer;
struct drm_gem_object;
+struct drm_minor;
struct module;
/**
@@ -146,4 +147,6 @@ struct drm_client_buffer *
drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32
height, u32 format);
void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
+int drm_client_debugfs_init(struct drm_minor *minor);
+
#endif
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()
Make full use of the generic fbdev client.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
drivers/gpu/drm/tinydrm/ili9225.c | 1 -
drivers/gpu/drm/tinydrm/ili9341.c | 1 -
drivers/gpu/drm/tinydrm/mi0283qt.c | 1 -
drivers/gpu/drm/tinydrm/st7586.c| 1 -
drivers/gpu/drm/tinydrm/st7735r.c | 1 -
6 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 24a33bf862fa..19c7f70adfa5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -204,7 +204,7 @@ static int tinydrm_register(struct tinydrm_device *tdev)
if (ret)
return ret;
- ret = drm_fb_cma_fbdev_init_with_funcs(drm, 0, 0, tdev->fb_funcs);
+ ret = drm_fbdev_generic_setup(drm, 0);
if (ret)
DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
@@ -214,7 +214,6 @@ static int tinydrm_register(struct tinydrm_device *tdev)
static void tinydrm_unregister(struct tinydrm_device *tdev)
{
drm_atomic_helper_shutdown(tdev->drm);
- drm_fb_cma_fbdev_fini(tdev->drm);
drm_dev_unregister(tdev->drm);
}
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 841c69aba059..455fefe012f5 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -368,7 +368,6 @@ static struct drm_driver ili9225_driver = {
DRIVER_ATOMIC,
.fops = &ili9225_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.name = "ili9225",
.desc = "Ilitek ILI9225",
.date = "20171106",
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c
b/drivers/gpu/drm/tinydrm/ili9341.c
index 8864dcde6edc..6701037749a7 100644
--- a/drivers/gpu/drm/tinydrm/ili9341.c
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -145,7 +145,6 @@ static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
.fops = &ili9341_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "ili9341",
.desc = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 015d03f2acba..d7bb4c5e6657 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -154,7 +154,6 @@ static struct drm_driver mi0283qt_driver = {
DRIVER_ATOMIC,
.fops = &mi0283qt_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "mi0283qt",
.desc = "Multi-Inno MI0283QT",
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 5c29e3803ecb..2fcbc3067d71 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -304,7 +304,6 @@ static struct drm_driver st7586_driver = {
DRIVER_ATOMIC,
.fops = &st7586_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "st7586",
.desc = "Sitronix ST7586",
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
b/drivers/gpu/drm/tinydrm/st7735r.c
index 6c7b15c9da4f..3081bc57c116 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -120,7 +120,6 @@ static struct drm_driver st7735r_driver = {
DRIVER_ATOMIC,
.fops = &st7735r_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "st7735r",
.desc = "Sitronix ST7735R",
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
include/drm/drm_fb_cma_helper.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 718c7f961d8a..9da36a6271d3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -99,27 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-/**
- * drm_fb_cma_fbdev_init_with_funcs() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- * @dev->mode_config.num_connector is used if this is zero.
- * @funcs: Framebuffer functions, in particular a custom dirty() callback.
- * Can be NULL.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count,
- const struct drm_framebuffer_funcs *funcs)
-{
- return drm_fb_cma_fbdev_init(dev, preferred_bpp, max_conn_count);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init_with_funcs);
-
/**
* drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
* @dev: DRM device
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a0546c3451f9..96e26e3b9a0c 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -16,9 +16,6 @@ struct drm_mode_fb_cmd2;
struct drm_plane;
struct drm_plane_state;
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count,
- const struct drm_framebuffer_funcs *funcs);
int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
unsigned int max_conn_count);
void drm_fb_cma_fbdev_fini(struct drm_device *dev);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/9] drm: Add generic fbdev emulation
This patchset adds generic fbdev emulation for drivers that supports GEM based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An API is begun to support in-kernel clients in general. Change this version: Fix a bug in an error path that the kbuild test robot caught. Change previous version: Rework client removal (again). Drop reference counting, only allow the driver to remove a client. Noralf. Changes since version 3: - drm/cma-helper: Use the generic fbdev emulation: Fix error path - Remove setting .lastclose in new tinydrm driver ili9341 Changes since version 2: - Applied first 3 patches to drm-misc-next - Drop client reference counting and only allow the driver to release clients. Noralf Trønnes (9): drm: Begin an API for in-kernel clients drm/fb-helper: Add generic fbdev emulation .fb_probe function drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap drm/cma-helper: Use the generic fbdev emulation drm/client: Add client callbacks drm/debugfs: Add internal client debugfs file drm/fb-helper: Finish the generic fbdev emulation drm/tinydrm: Use drm_fbdev_generic_setup() drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Documentation/gpu/drm-client.rst| 12 + Documentation/gpu/index.rst | 1 + drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_client.c| 405 drivers/gpu/drm/drm_debugfs.c | 7 + drivers/gpu/drm/drm_drv.c | 8 + drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++--- drivers/gpu/drm/drm_fb_helper.c | 316 +- drivers/gpu/drm/drm_file.c | 3 + drivers/gpu/drm/drm_probe_helper.c | 3 + drivers/gpu/drm/pl111/pl111_drv.c | 2 + drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +- drivers/gpu/drm/tinydrm/ili9225.c | 1 - drivers/gpu/drm/tinydrm/ili9341.c | 1 - drivers/gpu/drm/tinydrm/mi0283qt.c | 1 - drivers/gpu/drm/tinydrm/st7586.c| 1 - drivers/gpu/drm/tinydrm/st7735r.c | 1 - include/drm/drm_client.h| 152 +++ include/drm/drm_device.h| 21 ++ include/drm/drm_fb_cma_helper.h | 6 - include/drm/drm_fb_helper.h | 38 +++ 21 files changed, 1010 insertions(+), 353 deletions(-) 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 -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/9] drm/client: Add client callbacks
Add client callbacks and hook them up.
Add a list of clients per drm_device.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 92 -
drivers/gpu/drm/drm_drv.c | 7 +++
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 11 -
drivers/gpu/drm/drm_file.c | 3 ++
drivers/gpu/drm/drm_probe_helper.c | 3 ++
include/drm/drm_client.h| 75 +-
include/drm/drm_device.h| 14 ++
8 files changed, 201 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9c9b8ac7aea3..f05ee98bd10c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close);
* @dev: DRM device
* @client: DRM client
* @name: Client name
+ * @funcs: DRM client functions (optional)
*
* Use drm_client_put() to free the client.
*
@@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close);
* 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)
+ const char *name, const struct drm_client_funcs *funcs)
{
+ bool registered;
int ret;
if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
return -ENOTSUPP;
+ if (funcs && !try_module_get(funcs->owner))
+ return -ENODEV;
+
client->dev = dev;
client->name = name;
+ client->funcs = funcs;
ret = drm_client_open(client);
if (ret)
- return ret;
+ goto err_put_module;
+
+ mutex_lock(&dev->clientlist_mutex);
+ registered = dev->registered;
+ if (registered)
+ list_add(&client->list, &dev->clientlist);
+ mutex_unlock(&dev->clientlist_mutex);
+ if (!registered) {
+ ret = -ENODEV;
+ goto err_close;
+ }
drm_dev_get(dev);
return 0;
+
+err_close:
+ drm_client_close(client);
+err_put_module:
+ if (funcs)
+ module_put(funcs->owner);
+
+ return ret;
}
EXPORT_SYMBOL(drm_client_new);
@@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev *client)
drm_client_close(client);
drm_dev_put(dev);
+ if (client->funcs)
+ module_put(client->funcs->owner);
}
EXPORT_SYMBOL(drm_client_release);
+void drm_client_dev_unregister(struct drm_device *dev)
+{
+ struct drm_client_dev *client, *tmp;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry_safe(client, tmp, &dev->clientlist, list) {
+ list_del(&client->list);
+ if (client->funcs && client->funcs->unregister) {
+ client->funcs->unregister(client);
+ } else {
+ drm_client_release(client);
+ kfree(client);
+ }
+ }
+ mutex_unlock(&dev->clientlist_mutex);
+}
+
+void drm_client_dev_hotplug(struct drm_device *dev)
+{
+ struct drm_client_dev *client;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry(client, &dev->clientlist, list) {
+ if (!client->funcs || !client->funcs->hotplug)
+ continue;
+
+ ret = client->funcs->hotplug(client);
+ DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
+ }
+ mutex_unlock(&dev->clientlist_mutex);
+}
+EXPORT_SYMBOL(drm_client_dev_hotplug);
+
+void drm_client_dev_restore(struct drm_device *dev)
+{
+ struct drm_client_dev *client;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry(client, &dev->clientlist, list) {
+ if (!client->funcs || !client->funcs->restore)
+ continue;
+
+ ret = client->funcs->restore(client);
+ DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
+ if (!ret) /* The first one to return zero gets the privilege to
restore */
+ break;
+ }
+ mutex_unlock(&dev->clientlist_mutex);
+}
+
static void drm_client_buffer_delete(struct drm_client_buffer *buffer)
{
struct drm_device *dev = buffer->client->dev;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e7ff0b03328b..6eb935bb2f92 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/d
[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 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 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
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
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: [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 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
[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: [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
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: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 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
[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
[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 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 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 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
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 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
