[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #16 from Alex Deucher --- (In reply to Andrey Grodzovsky from comment #15) > I think it just means systems with large VRAM so it will require large BAR > for mapping. But I am not sure on that point. That's correct. the updates are done with the CPU rather than the GPU (SDMA). The default BAR size on most systems is usually 256MB for 32 bit compatibility so the window for CPU access to vram (where the page tables live) is limited. -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #15 from Andrey Grodzovsky --- (In reply to dwagner from comment #13) > (In reply to Andrey Grodzovsky from comment #12) > > Can you load the kernel with grub command line amdgpu.vm_update_mode=3 to > > force CPU VM update mode and see if this helps ? > > Sure. Too early yet to say "hurray", but at an uptime of one hour, > currently, 4.17.2 survived with amdgpu.vm_update_mode=3 already about 20 > times longer than without that option before the first crash. > > One (probably just informal) message is emitted by the kernel: > [ 19.319565] CPU update of VM recommended only for large BAR system > > Can you explain a little: What is a "large BAR system", and what does the > vm_update_mode=3 option actually cause? Should I expect any weird side > effects to look for? I think it just means systems with large VRAM so it will require large BAR for mapping. But I am not sure on that point. vm_update_mode=3 means GPUVM page tables update is done using CPU. By default we do it using DMA engine on the ASIC. The log showed a hang in this engine so I assumed there is something wrong with SDMA commands we submit. I assume more CPU utilization as a side effect and maybe slower rendering. > > > BTW: Not a result of that option, but of the kernel version, seems to be the > fact that the shader clock keeps at a pretty high frequency all the time - > even without any 3d or compute load, just displaying a quiet 4k/60Hz desktop > image: > > cat pp_dpm_sclk > 0: 214Mhz > 1: 481Mhz > 2: 760Mhz > 3: 1020Mhz > 4: 1102Mhz > 5: 1138Mhz > 6: 1180Mhz * > 7: 1220Mhz > > Much lower shader clocks are used only if I lower the refresh rate of the > screen. Is there a reason why the shader clocks should stay high even in the > absence of 3d/compute load? > > (I would have better understood if the minimum memory clock was depending on > the refresh rate, but memory clock stays as low as with the older kernels.) -- 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 v7 00/29] Add support for mediatek SOC MT2712
Hi, Daniel Vetter: On Mon, 2018-06-25 at 10:47 +0200, Daniel Vetter wrote: > On Wed, Jun 20, 2018 at 04:19:02PM +0800, Stu Hsieh wrote: > > This patch add support for the Mediatek MT2712 DISP subsystem. > > MT2712 is base on MT8173, there are some difference as following: > > MT2712 support three disp output(two ovl and one rdma) > > > > Change in v6: > > - Update commit message for the patch > > "drm/mediatek: Update the definition of connection from RDMA1 to DPI0" > > Just a drive-by comment on the mediatek driver: > > As far as I can see mtk_drm_gem.c reimplements the cma helpers as a > copypaste job. Any reasons why you're not using the normal cma helpers? > > Thanks, Daniel > > In the beginning, we develop mtk_drm_gem.c by referring other platform. We will try to use the normal cma helpers according to your idea. Thanks, Stu > > Stu Hsieh (29): > > drm/mediatek: update dt-bindings for mt2712 > > drm/mediatek: support maximum 64 mutex mod > > drm/mediatek: add ddp component AAL1 > > drm/mediatek: add ddp component OD1 > > drm/mediatek: add ddp component PWM1 > > drm/mediatek: add ddp component PWM2 > > drm/mediatek: add component DPI1 > > drm/mediatek: add component DSI2 > > drm/mediatek: add component DSI3 > > drm/mediatek: add the DSI1 for component init condition > > drm/mediatek: add connection from OD1 to RDMA1 > > drm/mediatek: Update the definition of connection from RDMA1 to DPI0 > > drm/mediatek: add connection from RDMA0 to DPI0 > > drm/mediatek: add connection from RDMA0 to DSI2 > > drm/mediatek: add connection from RDMA0 to DSI3 > > drm/mediatek: add connection from RDMA1 to DPI1 > > drm/mediatek: add connection from RDMA1 to DSI1 > > drm/mediatek: add connection from RDMA1 to DSI2 > > drm/mediatek: add connection from RDMA1 to DSI3 > > drm/mediatek: add connection from RDMA2 to DPI0 > > drm/mediatek: add connection from RDMA2 to DPI1 > > drm/mediatek: add connection from RDMA2 to DSI1 > > drm/mediatek: add connection from RDMA2 to DSI2 > > drm/mediatek: add connection from RDMA2 to DSI3 > > drm/mediatek: add DPI1 support for mutex > > drm/mediatek: add DSI2 support for mutex > > drm/mediatek: add DSI3 support for mutex > > drm/mediatek: add third ddp path > > drm/mediatek: Add support for mediatek SOC MT2712 > > > > .../bindings/display/mediatek/mediatek,disp.txt| 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 3 + > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 235 > > ++--- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 15 +- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 10 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 - > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 5 +- > > 7 files changed, 274 insertions(+), 43 deletions(-) > > > > -- > > 2.12.5 > > > > ___ > > 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
[pull] amdgpu drm-fixes-4.18
Hi Dave, A few fixes for 4.18: - fix a read past the end of an array due to vega20 changes - fix driver on systems with non-4K pages - fix locking with pageflipping in DC that could lead to a sleep while atomic - fix VCN firmware version reporting for upcoming firmware The following changes since commit fe2a19652918a5247418aed48a247414a5e45fe2: drm/amdgpu: Count disabled CRTCs in commit tail earlier (2018-06-22 14:55:25 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.18 for you to fetch changes up to 4de9f38bb2cce3a4821ffb8a83d6b08f6e37d905: drm/amd/display: release spinlock before committing updates to stream (2018-06-27 14:35:53 -0500) James Zhu (1): drm/amdgpu:Support new VCN FW version naming convention Leo Liu (1): drm/amdgpu: fix UBSAN: Undefined behaviour for amdgpu_fence.c Michel Dänzer (1): drm/amdgpu: GPU vs CPU page size fixes in amdgpu_vm_bo_split_mapping Shirish S (1): drm/amd/display: release spinlock before committing updates to stream drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 33 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8 +++--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++--- 4 files changed, 35 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 24/24] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> Since HDMI can be considered as main output, most capable mixer is
> connected to it (mixer0).
>
> Signed-off-by: Jernej Skrabec
> ---
> .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> index 27d9ccd0ef2f..0ebc2f9a980e 100644
> --- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> +++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> @@ -58,6 +58,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -93,6 +104,10 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> @@ -101,6 +116,16 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> +};
> +
> {
> status = "okay";
>
> @@ -195,6 +220,26 @@
> status = "okay";
> };
>
> +_top_hdmi_in_tcon_tv0 {
> + remote-endpoint = <_tv0_out_tcon_top>;
> +};
> +
> +_top_mixer0_out_tcon_tv0 {
> + remote-endpoint = <_tv0_in_tcon_top>;
> +};
> +
> +_tv0_in {
> + tcon_tv0_in_tcon_top: endpoint {
> + remote-endpoint = <_top_mixer0_out_tcon_tv0>;
> + };
> +};
> +
> +_tv0_out {
> + tcon_tv0_out_tcon_top: endpoint {
> + remote-endpoint = <_top_hdmi_in_tcon_tv0>;
> + };
> +};
> +
This is the wrong place for this. Once removed,
Reviewed-by: Chen-Yu Tsai
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pb_pins>;
> --
> 2.18.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
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
> #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.
> + allwinner,pipelines = <>, <>;
> + 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 = < CLK_DE>,
> +< CLK_BUS_DE>;
> + clock-names = "mod",
> + "bus";
> + resets = < RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + mixer0: mixer@110 {
> + compatible = "allwinner,sun8i-r40-de2-mixer-0";
> + reg = <0x0110 0x10>;
> + clocks = <_clocks CLK_BUS_MIXER0>,
> +<_clocks CLK_MIXER0>;
> + clock-names = "bus",
> + "mod";
> + resets = <_clocks RST_MIXER0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer0_out: port@1 {
> + reg = <1>;
> + mixer0_out_tcon_top: endpoint {
> + remote-endpoint =
> <_top_mixer0_in_mixer0>;
> + };
> + };
> + };
> + };
> +
> + mixer1: mixer@120 {
> + compatible = "allwinner,sun8i-r40-de2-mixer-1";
> + reg = <0x0120 0x10>;
> + clocks = <_clocks CLK_BUS_MIXER1>,
> +<_clocks CLK_MIXER1>;
> + clock-names = "bus",
> + "mod";
> + resets = <_clocks RST_WB>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer1_out: port@1 {
> + reg = <1>;
> + mixer1_out_tcon_top: endpoint {
> + remote-endpoint =
> <_top_mixer1_in_mixer1>;
> + };
> + };
> + };
> + };
> +
> nmi_intc: interrupt-controller@1c00030 {
> compatible = "allwinner,sun7i-a20-sc-nmi";
> interrupt-controller;
> @@ -451,6 +518,163 @@
> #size-cells = <0>;
> };
>
> + tcon_top: tcon-top@1c7 {
> + compatible = "allwinner,sun8i-r40-tcon-top";
> + reg = <0x01c7 0x1000>;
> + clocks = < CLK_BUS_TCON_TOP>,
> +< CLK_TCON_TV0>,
> +< CLK_TVE0>,
> +< CLK_TCON_TV1>,
> +< CLK_TVE1>,
> +< CLK_DSI_DPHY>;
> + clock-names = "bus",
> + "tcon-tv0",
> + "tve0",
> + "tcon-tv1",
> +
Re: [PATCH v3 22/24] drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote: > drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is > connected to TCON (crtc) through mux in TCON TOP. > > In that case TCON TOP HDMI mux input port has to be manually traversed > and checked if it matches any known crtc. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 21/24] drm: of: Export drm_crtc_port_mask()
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote: > Function is useful when drm_of_find_possible_crtcs() can't be used and > custom parsing is needed. This can happen for example when there is a > node with multiple muxes between crtc and encoder. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 20/24] drm/sun4i: Add support for A64 HDMI PHY
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote: > PHY is the same as in H3, except it can switch between two clock > parents. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 19/24] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Expand HDMI PHY clock driver to support second clock parent.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 --
> 3 files changed, 73 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> index 46a3aa6a53a9..aadbe0a10b0c 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -99,6 +99,7 @@
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_ENBIT(28)
> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> #define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x)((x) << 22)
> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> @@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
> void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
> const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
>
> -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
> +bool second_parent);
>
> #endif /* _SUN8I_DW_HDMI_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> index f0877b3f67e7..aea46b08f127 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -491,7 +491,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> struct device_node *node)
> }
> }
>
> - ret = sun8i_phy_clk_create(phy, dev);
> + ret = sun8i_phy_clk_create(phy, dev,
> + phy->variant->has_second_pll);
> if (ret) {
> dev_err(dev, "Couldn't create the PHY clock\n");
> goto err_put_clk_pll1;
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> index faea449812f8..a4d31fe3abff 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> @@ -22,35 +22,45 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
> {
> unsigned long rate = req->rate;
> unsigned long best_rate = 0;
> + struct clk_hw *best_parent = NULL;
> struct clk_hw *parent;
> int best_div = 1;
> - int i;
> + int i, p;
>
> - parent = clk_hw_get_parent(hw);
> -
> - for (i = 1; i <= 16; i++) {
> - unsigned long ideal = rate * i;
> - unsigned long rounded;
> -
> - rounded = clk_hw_round_rate(parent, ideal);
> + for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
> + parent = clk_hw_get_parent_by_index(hw, p);
> + if (!parent)
> + continue;
>
> - if (rounded == ideal) {
> - best_rate = rounded;
> - best_div = i;
> - break;
> + for (i = 1; i <= 16; i++) {
> + unsigned long ideal = rate * i;
> + unsigned long rounded;
> +
> + rounded = clk_hw_round_rate(parent, ideal);
> +
> + if (rounded == ideal) {
> + best_rate = rounded;
> + best_div = i;
> + best_parent = parent;
> + break;
> + }
> +
> + if (!best_rate ||
> + abs(rate - rounded / i) <
> + abs(rate - best_rate / best_div)) {
> + best_rate = rounded;
> + best_div = i;
> + best_parent = parent;
> + }
> }
>
> - if (!best_rate ||
> - abs(rate - rounded / i) <
> - abs(rate - best_rate / best_div)) {
> - best_rate = rounded;
> - best_div = i;
> - }
> + if (best_rate / best_div == rate)
> + break;
> }
>
> req->rate = best_rate / best_div;
> req->best_parent_rate = best_rate;
> - req->best_parent_hw = parent;
> + req->best_parent_hw = best_parent;
>
> return 0;
> }
> @@ -95,22 +105,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw,
> unsigned long rate,
> return 0;
> }
>
> +static u8
Re: [PATCH v3 18/24] drm/sun4i: DW HDMI PHY: Add support for second PLL
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select > between two clock parents. > > Add code which reads second PLL from DT. > > Signed-off-by: Jernej Skrabec This patch by itself does not do anything. It should be merged with the next one. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 17/24] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > DW HDMI PHY driver and PHY clock driver share same registers. Make sure > that DW HDMI PHY setup code doesn't change any clock related bits. > During initialization, set PHY PLL parent bit to 0. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai and maybe a fixes tag? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 16/24] drm/sun4i: Enable DW HDMI PHY clock
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Current DW HDMI PHY code never prepares and enables PHY clock after it is
> created. It's just used as it is. This may work in some cases, but it's
> clearly wrong. Fix it by adding proper calls to enable/disable PHY
> clock.
>
> Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
>
> Signed-off-by: Jernej Skrabec
So why does it work on the H3? Because there's only one PLL that the whole
display pipeline uses?
We should probably tag this for stable. So,
Cc:
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 15/24] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL > clock parents. It is compatible to other HDMI PHYs, like that found in > R40. > > Acked-by: Rob Herring > Signed-off-by: Jernej Skrabec > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index 84fe38dbb900..dc83f21ef188 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -101,6 +101,7 @@ DWC HDMI PHY > > Required properties: >- compatible: value must be one of: > +* allwinner,sun50i-a64-hdmi-phy > * allwinner,sun8i-a83t-hdmi-phy > * allwinner,sun8i-h3-hdmi-phy Nit: the list is sorted by family first, then SoC name, so it should be the last on the list. Otherwise, Reviewed-by: Chen-Yu Tsai >- reg: base address and size of memory-mapped region > @@ -111,8 +112,9 @@ Required properties: >- resets: phandle to the reset controller driving the PHY >- reset-names: must be "phy" > > -H3 HDMI PHY requires additional clock: > +H3 and A64 HDMI PHY require additional clocks: >- pll-0: parent of phy clock > + - pll-1: second possible phy clock parent (A64 only) > > TV Encoder > -- > -- > 2.18.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/24] drm/sun4i: Add support for R40 mixers
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > Both mixers have similar capabilities as others SoCs with DE2. > > First mixer has 1 VI and 3 UI planes and supports HW scaling on all > planes. > > Second mixer has 1 VI and 1 UI planes and also supports HW scaling on > all planes. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/24] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > R40 DE2 mixers are similar to those found in A83T, except it needs > different clock settings. > > Add a compatibles for them. > > Acked-by: Rob Herring > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/24] drm/sun4i: Don't check for panel or bridge on TV TCONs
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 761687ebacba..a41c7bb0d557 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1178,13 +1178,19 @@ static const struct component_ops sun4i_tcon_ops = {
> static int sun4i_tcon_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + const struct sun4i_tcon_quirks *quirks;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(node, 1, 0, , );
> - if (ret == -EPROBE_DEFER)
> - return ret;
> + quirks = of_device_get_match_data(>dev);
> +
> + /* panels and bridges are present only on TCONs with channel 0 */
> + if (quirks->has_channel_0) {
This is implied by the device tree binding. TCONs that don't have panels
or bridges will have endpoint 0 unconnected, and drm_of_find_panel_or_bridge
will return -ENODEV.
It doesn't hurt to skip the check though.
Reviewed-by: Chen-Yu Tsai
> + ret = drm_of_find_panel_or_bridge(node, 1, 0, ,
> );
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + }
>
> return component_add(>dev, _tcon_ops);
> }
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #14 from Alex Deucher --- (In reply to dwagner from comment #13) > > Much lower shader clocks are used only if I lower the refresh rate of the > screen. Is there a reason why the shader clocks should stay high even in the > absence of 3d/compute load? > Certain display requirements can cause the engine clock to be kept higher as well. -- 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 v3 11/24] drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > LVDS and RGB interfaces are always connected to TCONs which have channel > 0. It doesn't make sense to try to init them on TV TCONs. > > Add a check if TCON has channel 0 before trying to init LVDS or RGB > interface. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Though I think at some point we could just have separate functions to handle channel 0 and channel 1. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/24] drm/sun4i: tcon: Generalize engine search algorithm
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Current "old" method to find engine worked pretty well for DE2. However,
> it doesn't work when TCON TOP is between mixer (engine) and TCON. TCON
> TOP has multiple input ports, but current engine search algorithm
> expects only one.
>
> This can be fixed by first looking for output port id and selecting
> matching input by subtracting 1 for the next round. This work even if
> there is only one input and output.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 08747fc3ee71..264bcc43da11 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -791,12 +791,14 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> */
> static struct sunxi_engine *
> sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
> - struct device_node *node)
> + struct device_node *node,
> + u32 port_id)
> {
> struct device_node *port, *ep, *remote;
> struct sunxi_engine *engine = ERR_PTR(-EINVAL);
> + u32 reg = 0;
>
> - port = of_graph_get_port_by_id(node, 0);
> + port = of_graph_get_port_by_id(node, port_id);
> if (!port)
> return ERR_PTR(-EINVAL);
>
> @@ -826,8 +828,20 @@ sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
> if (remote == engine->node)
> goto out_put_remote;
>
> + /*
> +* According to device tree binding input ports have even id
> +* number and output ports have odd id. Since component with
> +* more than one input and one output (TCON TOP) exits, correct
> +* remote input id has to be calculated by subtracting 1 from
> +* remote output id. If this for some reason can't be done, 0
> +* is used as input port id.
> +*/
You need to call
of_node_put(port);
to drop the reference to the original port.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> + port = of_graph_get_remote_port(ep);
> + if (!of_property_read_u32(port, "reg", ) && reg > 0)
> + reg -= 1;
> +
> /* keep looking through upstream ports */
> - engine = sun4i_tcon_find_engine_traverse(drv, remote);
> + engine = sun4i_tcon_find_engine_traverse(drv, remote, reg);
>
> out_put_remote:
> of_node_put(remote);
> @@ -950,7 +964,7 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct
> sun4i_drv *drv,
>
> /* Fallback to old method by traversing input endpoints */
> of_node_put(port);
> - return sun4i_tcon_find_engine_traverse(drv, node);
> + return sun4i_tcon_find_engine_traverse(drv, node, 0);
> }
>
> static int sun4i_tcon_bind(struct device *dev, struct device *master,
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/24] drm/sun4i: Add support for traversing graph with TCON TOP
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > TCON TOP is different from other nodes in graph by having 3 input and 3 > output ports. Additionally, connection to TV TCON might lead back to > HDMI mux input port, creating loops. > > Add support for traversing such graph. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 07/24] drm/sun4i: Split out code for enumerating endpoints in output port
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > Until now, each node has one input port and one output port. However, > with TCON TOP this is no longer true. It has 3 input and 3 output ports. > > In order to prepare to this situation, split out the code which checks > all endpoints in input port and adds available components to fifo. > > This patch doesn't do any functional change. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 06/24] drm/sun4i: Fix releasing node when enumerating enpoints
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put() > when remote is equal to NULL and does nothing when remote has a valid > pointer. > > Invert the logic to fix memory leak. > > Signed-off-by: Jernej Skrabec Given this is a fix, it should have Fixes and stable tags. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/24] drm/sun4i: Don't skip TCONs if they don't have channel 0
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > TV TCONs (channel 1 only) are always connected to TV or HDMI encoder. > Because of that, all output endpoints on such TCON node will point to a > encoder which is part of component framework. > > Correct current graph traversing algorithm in such way that it doesn't > skip output enpoints with id 0 on TV TCONs. No. Our bindings say that endpoint 0 _is_ channel 0. For TCONs that don't have channel 0, it must be skipped. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/24] drm/sun4i: Add TCON TOP driver
Hi,
So I'm late to the party, but...
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> As already described in DT binding, TCON TOP is responsible for
> configuring display pipeline. In this initial driver focus is on HDMI
> pipeline, so TVE and LCD configuration is not implemented.
>
> Implemented features:
> - HDMI source selection
> - clock driver (TCON and DSI gating)
> - connecting mixers and TCONS
>
> Something similar also existed in previous SoCs, except that it was part
> of first TCON.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/Makefile | 3 +-
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 300 +
> drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 40
> 3 files changed, 342 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 2589f4acd5ae..09fbfd6304ba 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
>
> sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
>sun8i_vi_layer.o sun8i_ui_scaler.o \
> - sun8i_vi_scaler.o sun8i_csc.o
> + sun8i_vi_scaler.o sun8i_csc.o \
> + sun8i_tcon_top.o
>
> sun4i-tcon-y += sun4i_crtc.o
> sun4i-tcon-y += sun4i_dotclock.o
> diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> new file mode 100644
> index ..8da0460e0028
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> @@ -0,0 +1,300 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (c) 2018 Jernej Skrabec */
> +
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sun8i_tcon_top.h"
> +
> +static int sun8i_tcon_top_get_connected_ep_id(struct device_node *node,
> + int port_id)
> +{
> + struct device_node *ep, *remote, *port;
> + struct of_endpoint endpoint;
> +
> + port = of_graph_get_port_by_id(node, port_id);
> + if (!port)
> + return -ENOENT;
> +
> + for_each_available_child_of_node(port, ep) {
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote)
> + continue;
> +
> + if (of_device_is_available(remote)) {
> + of_graph_parse_endpoint(ep, );
> +
> + of_node_put(remote);
> +
> + return endpoint.id;
> + }
> +
> + of_node_put(remote);
> + }
> +
> + return -ENOENT;
> +}
> +
> +static struct clk_hw *sun8i_tcon_top_register_gate(struct device *dev,
> + struct clk *parent,
> + void __iomem *regs,
> + spinlock_t *lock,
> + u8 bit, int name_index)
> +{
> + const char *clk_name, *parent_name;
> + int ret;
> +
> + parent_name = __clk_get_name(parent);
You can simply pass in the binding clock name, and have
index = of_property_match_string(np, "clock-names", name);
parent_name = of_clk_get_parent_name(dev->of_node, index);
> + ret = of_property_read_string_index(dev->of_node,
> + "clock-output-names", name_index,
> + _name);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return clk_hw_register_gate(dev, clk_name, parent_name,
> + CLK_SET_RATE_PARENT,
> + regs + TCON_TOP_GATE_SRC_REG,
> + bit, 0, lock);
> +};
> +
> +static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct clk *dsi, *tcon_tv0, *tcon_tv1, *tve0, *tve1;
> + struct clk_hw_onecell_data *clk_data;
> + struct sun8i_tcon_top *tcon_top;
> + bool mixer0_unused = false;
> + struct resource *res;
> + void __iomem *regs;
> + int ret, i, id;
> + u32 val;
> +
> + tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
> + if (!tcon_top)
> + return -ENOMEM;
> +
> + clk_data = devm_kzalloc(dev, sizeof(*clk_data) +
> + sizeof(*clk_data->hws) * CLK_NUM,
> + GFP_KERNEL);
> + if (!clk_data)
> +
[PULL] drm-misc-next
Hi Dave, One more for 4.19. We don't have any big change on this one, it is mostly drivers updates here. Please pull. Regards, Gustavo drm-misc-next-2018-06-27: drm-misc-next for 4.19: Cross-subsystem Changes: devicetree documentation dt-bindings defintions for sun8i (Jernej Skrabec) Core Changes: Consider drivers setting DRIVER_ATOMIC as atomic (Eric Anholt) Improvements for in-kernel clients (Noralf Trønnes) Export and rename drm_crtc_port_mask() (Jernej Skrabec) Driver Changes: v3d: Add looking for GPU scheduler jobs management (Eric Anholt) Add Ilitek ILI9881c panel driver(Maxime Ripard) rockchip: vop: fixup linebuffer mode calc error (Sandy Huang) tinydrm: new driver for ILI9341 display panels (David Lechner) sun4i: Add TCON TOP driver (Jernej Skrabec) The following changes since commit c612ae0503af753c062594dcd14aecea121fa414: staging: android: ion: fix ion_dma_buf_attach signatur (2018-06-21 11:46:47 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-06-27 for you to fetch changes up to 57e23de02f4878061818fd118129a6b0e1516b11: drm/sun4i: DW HDMI: Expand algorithm for possible crtcs (2018-06-27 21:44:05 +0200) drm-misc-next for 4.19: Cross-subsystem Changes: devicetree documentation dt-bindings defintions for sun8i (Jernej Skrabec) Core Changes: Consider drivers setting DRIVER_ATOMIC as atomic (Eric Anholt) Improvements for in-kernel clients (Noralf Trønnes) Export and rename drm_crtc_port_mask() (Jernej Skrabec) Driver Changes: v3d: Add looking for GPU scheduler jobs management (Eric Anholt) Add Ilitek ILI9881c panel driver(Maxime Ripard) rockchip: vop: fixup linebuffer mode calc error (Sandy Huang) tinydrm: new driver for ILI9341 display panels (David Lechner) sun4i: Add TCON TOP driver (Jernej Skrabec) Christian König (1): drm/omap: remove now unused functions David Herrmann (1): drm: provide management functions for drm_file David Lechner (4): MAINTAINERS: fix path to ilitek, ili9225 device tree bindings dt-bindings: Add vendor prefix for Adafruit dt-bindings: new binding for Ilitek ILI9341 display panels drm/tinydrm: new driver for ILI9341 display panels Eric Anholt (4): drm/bridge: Move the struct drm_bridge member kerneldoc inline. drm/v3d: Take a lock across GPU scheduler job creation and queuing. drm/v3d: Remove the bad signaled() implementation. drm: Consider drivers setting DRIVER_ATOMIC as atomic. Gustavo A. R. Silva (2): drm/gma500: Fix potential NULL pointer dereference drm/gma500: Fix compile warning Jernej Skrabec (18): dt-bindings: display: sunxi-drm: Add TCON TOP description drm/sun4i: Add TCON TOP driver drm/sun4i: Fix releasing node when enumerating enpoints drm/sun4i: Split out code for enumerating endpoints in output port drm/sun4i: Add support for traversing graph with TCON TOP drm/sun4i: Don't skip TCONs if they don't have channel 0 drm/sun4i: tcon: Generalize engine search algorithm drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1 drm/sun4i: Don't check for panel or bridge on TV TCONs drm/sun4i: Add support for R40 mixers dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY drm/sun4i: Enable DW HDMI PHY clock drm/sun4i: Don't change clock bits in DW HDMI PHY driver drm/sun4i: DW HDMI PHY: Add support for second PLL drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver drm/sun4i: Add support for A64 HDMI PHY drm: of: Export and rename drm_crtc_port_mask() drm/sun4i: DW HDMI: Expand algorithm for possible crtcs John Stultz (1): drm: kirin: Remove useless "Scale not support" error message Maxime Ripard (2): dt-bindings: panel: Add the Ilitek ILI9881c panel documentation drm/panel: Add Ilitek ILI9881c panel driver Noralf Trønnes (2): drm/file: Don't set master on in-kernel clients drm: Make ioctls available for in-kernel clients Sandy Huang (1): drm/rockchip: vop: fixup linebuffer mode calc error Souptick Joarder (1): gpu: drm: vc4: Adding new typedef vm_fault_t Thomas Zimmermann (1): drm/gma500: Replace drm_gem_object_unreference_unlocked with put function Ville Syrjälä (2): drm: Document mode_config.max_width/height as the max fb dimensions drm/rockchip: Use drm_crtc_mask() .../devicetree/bindings/display/ilitek,ili9341.txt | 27 ++ .../bindings/display/panel/ilitek,ili9881c.txt | 20 + .../bindings/display/sunxi/sun4i-drm.txt | 60 ++- .../devicetree/bindings/vendor-prefixes.txt| 1 + MAINTAINERS| 8 +- drivers/gpu/drm/drm_crtc_internal.h| 19 +- drivers/gpu/drm/drm_dumb_buffers.c
Re: [[DPU]PATCH] drm/msm/dsi: move the API setting PLL src to modeset_init()
On Wed, Jun 27, 2018 at 2:48 PM, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 26, 2018 at 10:27 AM, Rob Clark wrote:
>> On Tue, Jun 26, 2018 at 11:55 AM, Doug Anderson
>> wrote:
>>> Hi,
>>>
>>> On Mon, Jun 25, 2018 at 9:45 PM, Sandeep Panda
>>> wrote:
From: Abhinav Kumar
Setting the DSI PLL src in probe doesn't provide the clock
driver sufficient time to reclaim unused clock resources
from coreboot resulting in warnings from clock driver.
Move the DSI PLL src setting to modeset_init() so that the
clock driver can claim unused display clock resources before
the display driver requests for them again.
>>>
>>> IMHO this is a bad design. Sean and Stephen can feel free to override
>>> me, but I think the clock driver should be improved to handle this
>>> case and not require the clock to get disabled before Linux enables
>>> it.
>>>
>>
>> I experimented with it a while back[1] (in this case w/ lk lighting up
>> the display). In that case I needed both the clk and gdsc code to
>> realize that clks/gdsc's were on at boot, and fixup the refcnt of the
>> clks (and parent clocks and so on). And then when probed the display
>> driver would check if clocks were enabled to decide to readback the
>> state from the hw. (Maybe you can short-circuit some of that if you
>> only care about DSI panels with a single fixed resolution, but as soon
>> as external displays come into the picture you can't assume so much
>> about the hw state.)
>>
>> BR,
>> -R
>>
>> [1] https://github.com/freedreno/kernel-msm/commits/display-handover
>
> It seems like something like that is the right real solution here, but
> I guess someone needs to step up and work on it.
>
yeah, sadly I haven't found time to revisit it (kinda been short on
time to work on display/kernel side of things.. it would be helpful if
qcom would stop coming out with new gpu's so often :-P)
But I am pretty sure if we want a general solution that can also deal
w/ splash screen on hot-pluggable display, and not just the simpler
case of fixed resolution dsi panels, it is going to require
cooperation between clk/gdsc and display driver.
> ...in general I'm wary of any patch that will not work when
> "clk_ignore_unused" is passed as a command line parameter. It's
> useful to be able to use this command line parameter for debugging
> sometimes and it would be unfortunate if doing so spewed a bunch of
> extra warnings.
for "full distro" config where all the display drivers are built as
modules and prior to real display driver loading you have kernel
inheriting the display via efifb or simplefb, I think we need to be
able to flag certain clocks and power domains (and on other platforms,
perhaps regulators) as "if the bootloader left this on, keep it that
way".. I guess for simple-fb we could perhaps solve it by attaching
power domains and clks to the simple-fb node, but that doesn't really
work for efifb..
BR,
-R
>
>
> On a side node, it appears that even without ${SUBJECT} patch the
> warnings seem to have gone away with the latest stack of patches I've
> been testing. The warnings don't even come back with
> "clk_ignore_unused". I haven't personally dug into why, but I figured
> I'd mention it.
>
>
> -Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199621] iMac 2009, Mobility Radeon HD 4670: black screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=199621 Matthew Trescott (matthewtresc...@gmail.com) changed: What|Removed |Added CC||matthewtresc...@gmail.com --- Comment #6 from Matthew Trescott (matthewtresc...@gmail.com) --- Created attachment 276935 --> https://bugzilla.kernel.org/attachment.cgi?id=276935=edit strace log of xorg when I ran the command that fixes this problem I have a 21.5-inch Mid-2010 iMac with the same Mobility Radeon HD 4670 GPU. It also exhibits this problem (the solution in #100301 doesn't work either); however I can temporarily fix it by running the following command (I had to type it blindly because it won't work over SSH): xrandr -d :0 --output eDP-1 --crtc 1 After which everything works well, including backlight control via /sys/class/backlight/radeon_bl0/brightness. The fix does not persist across reboots or even across log-out/log-in cycles (I guess the handoff between Xorg and radeondrmfb triggers some sort of reset and the problem comes back). I'm on kernel 4.17.2 (Arch Linux). I'm no Linux graphics expert, but I did capture an strace of all the ioctl calls from Xorg during while running the above command as well as monitoring sysfs with inotifywait. Nothing relevant happened in sysfs, but there were a few interesting system calls from when I ran the command that I've attached. -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #13 from dwagner --- (In reply to Andrey Grodzovsky from comment #12) > Can you load the kernel with grub command line amdgpu.vm_update_mode=3 to > force CPU VM update mode and see if this helps ? Sure. Too early yet to say "hurray", but at an uptime of one hour, currently, 4.17.2 survived with amdgpu.vm_update_mode=3 already about 20 times longer than without that option before the first crash. One (probably just informal) message is emitted by the kernel: [ 19.319565] CPU update of VM recommended only for large BAR system Can you explain a little: What is a "large BAR system", and what does the vm_update_mode=3 option actually cause? Should I expect any weird side effects to look for? BTW: Not a result of that option, but of the kernel version, seems to be the fact that the shader clock keeps at a pretty high frequency all the time - even without any 3d or compute load, just displaying a quiet 4k/60Hz desktop image: cat pp_dpm_sclk 0: 214Mhz 1: 481Mhz 2: 760Mhz 3: 1020Mhz 4: 1102Mhz 5: 1138Mhz 6: 1180Mhz * 7: 1220Mhz Much lower shader clocks are used only if I lower the refresh rate of the screen. Is there a reason why the shader clocks should stay high even in the absence of 3d/compute load? (I would have better understood if the minimum memory clock was depending on the refresh rate, but memory clock stays as low as with the older kernels.) -- 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 106942] X freezes with Ubuntu kernel 4.15.0-23-generic (AMDGPU)
https://bugs.freedesktop.org/show_bug.cgi?id=106942 --- Comment #3 from Andrey Grodzovsky --- (In reply to Olaf 'Rhialto' Seibert from comment #2) > On the Launchpad ticket I got a reqest to try a pre-built mainline kernel > from Ubuntu. So I had this one tested: > Linux xa-xubu 4.18.0-041800rc1-generic #201806162031 SMP Sun Jun 17 00:34:22 > UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > and I now have the report that it works. Hopefully this kernel is close > enough to the one you meant. > > So it seems that the bug is indeed fixed by the changes you mention. > Now this should still trickle into the general Ubuntu kernels I suppose. Good to know, yes, this is upstream already and should get to Ubuntu once they update their distro versions. I moved the ticket to resolved. Andrey -- 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 106942] X freezes with Ubuntu kernel 4.15.0-23-generic (AMDGPU)
https://bugs.freedesktop.org/show_bug.cgi?id=106942 Andrey Grodzovsky changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 106942] X freezes with Ubuntu kernel 4.15.0-23-generic (AMDGPU)
https://bugs.freedesktop.org/show_bug.cgi?id=106942 --- Comment #2 from Olaf 'Rhialto' Seibert --- On the Launchpad ticket I got a reqest to try a pre-built mainline kernel from Ubuntu. So I had this one tested: Linux xa-xubu 4.18.0-041800rc1-generic #201806162031 SMP Sun Jun 17 00:34:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and I now have the report that it works. Hopefully this kernel is close enough to the one you meant. So it seems that the bug is indeed fixed by the changes you mention. Now this should still trickle into the general Ubuntu kernels I suppose. -- 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 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4
https://bugs.freedesktop.org/show_bug.cgi?id=106263 --- Comment #8 from Harry Wentland --- Bisected commit is different from what was originally reported (both in generic_reg_update_ex, but otherwise completely different codepaths and cases). The bisected commit is fixed in 4.18 rc1 by this commit commit 9356badb2636b0afe2b34a8133ab246547cdf9ca Author: Roman Li Date: Thu May 17 18:08:54 2018 -0400 drm/amd/display: check if audio clk enable is applicable Fixing warning on dce10 with HDMI display. Signed-off-by: Roman Li Reviewed-by: Charlene Liu Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher -- 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 v3 00/24] Add support for R40 HDMI pipeline
1;5202;0c On Wed, Jun 27, 2018 at 08:02:15PM +0200, Maxime Ripard wrote: > On Mon, Jun 25, 2018 at 02:02:40PM +0200, Jernej Skrabec wrote: > > This series adds support for R40 HDMI pipeline. It is a bit special > > than other already supported pipelines because it has additional unit > > called TCON TOP responsible for relationship configuration between > > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI > > and TV TCONs, TV encoder clock settings and pin muxing between LCD > > and TV encoders. > > > > However, it seems that TCON TOP will become a norm, since newer > > Allwinner SoCs like H6 also have this unit. > > > > I tested different possible configurations: > > - mixer0 <> TCON-TV0 <> HDMI > > - mixer0 <> TCON-TV1 <> HDMI > > - mixer1 <> TCON-TV0 <> HDMI > > - mixer1 <> TCON-TV1 <> HDMI > > > > Please review. > > I just applied it. It didn't apply cleanly, so please make sure it > does next time, or at least state what the dependencies are. And it didn't compile either, because of the compile error that was reported to the previous version by kbuild... Those shouldn't be ignored and simply fixed. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105018] Kernel panic when waking up after screen goes blank.
https://bugs.freedesktop.org/show_bug.cgi?id=105018 Harry Wentland changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #36 from Harry Wentland --- The kernel BUG should be fixed since 4.17 by this commit commit 20d4ac659c76034586a3ab79489b0940631a65de Author: Leo (Sunpeng) Li Date: Tue May 29 09:51:51 2018 -0400 drm/amd/display: Fix BUG_ON during CRTC atomic check update For cases where the CRTC is inactive (DPMS off), where a modeset is not required, yet the CRTC is still in the atomic state, we should not attempt to update anything on it. Previously, we were relying on the modereset_required() helper to check the above condition. However, the function returns false immediately if a modeset is not required, ignoring the CRTC's enable/active state flags. The correct way to filter is by looking at these flags instead. Fixes: e277adc5a06c "drm/amd/display: Hookup color management functions" Bugzilla: https://bugs.freedesktop.org/106194 Signed-off-by: Leo (Sunpeng) Li Reviewed-by: Harry Wentland Tested-by: Michel Dänzer Signed-off-by: Alex Deucher I'll mark this as resolved but please reopen if it still reproduces. -- 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: [[DPU]PATCH] drm/msm/dsi: move the API setting PLL src to modeset_init()
Hi,
On Tue, Jun 26, 2018 at 10:27 AM, Rob Clark wrote:
> On Tue, Jun 26, 2018 at 11:55 AM, Doug Anderson wrote:
>> Hi,
>>
>> On Mon, Jun 25, 2018 at 9:45 PM, Sandeep Panda wrote:
>>> From: Abhinav Kumar
>>>
>>> Setting the DSI PLL src in probe doesn't provide the clock
>>> driver sufficient time to reclaim unused clock resources
>>> from coreboot resulting in warnings from clock driver.
>>>
>>> Move the DSI PLL src setting to modeset_init() so that the
>>> clock driver can claim unused display clock resources before
>>> the display driver requests for them again.
>>
>> IMHO this is a bad design. Sean and Stephen can feel free to override
>> me, but I think the clock driver should be improved to handle this
>> case and not require the clock to get disabled before Linux enables
>> it.
>>
>
> I experimented with it a while back[1] (in this case w/ lk lighting up
> the display). In that case I needed both the clk and gdsc code to
> realize that clks/gdsc's were on at boot, and fixup the refcnt of the
> clks (and parent clocks and so on). And then when probed the display
> driver would check if clocks were enabled to decide to readback the
> state from the hw. (Maybe you can short-circuit some of that if you
> only care about DSI panels with a single fixed resolution, but as soon
> as external displays come into the picture you can't assume so much
> about the hw state.)
>
> BR,
> -R
>
> [1] https://github.com/freedreno/kernel-msm/commits/display-handover
It seems like something like that is the right real solution here, but
I guess someone needs to step up and work on it.
...in general I'm wary of any patch that will not work when
"clk_ignore_unused" is passed as a command line parameter. It's
useful to be able to use this command line parameter for debugging
sometimes and it would be unfortunate if doing so spewed a bunch of
extra warnings.
On a side node, it appears that even without ${SUBJECT} patch the
warnings seem to have gone away with the latest stack of patches I've
been testing. The warnings don't even come back with
"clk_ignore_unused". I haven't personally dug into why, but I figured
I'd mention it.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Implement zpos for DE2
Hi! On Wed, Jun 27, 2018 at 06:45:14PM +0200, Jernej Skrabec wrote: > Initial implementation of DE2 planes only supported fixed zpos. > > Expand implementation with configurable zpos property. > > Signed-off-by: Jernej Skrabec Thanks for that work. I guess you should expand a bit on the exact setup you're doing here. Are the pipes working the same way on the DE2 than on DE1, ie does the pipe blending applies before the alpha blending, and therefore you need to make sure that there's not two planes with alpha going to the same pipe? Also, you seem to use the pipe and channels indifferently now, why is that? Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
On 06/27/2018 01:58 AM, Daniel Vetter wrote: On Tue, Jun 26, 2018 at 8:16 PM, David Lechner wrote: On 06/20/2018 04:07 AM, Daniel Vetter wrote: I acked and forwarded the account request, sorry for the delay. Next time around, poking maintainers on irc helps if this stuff is stuck. -Daniel The account was supposedly setup, but I am not able to use it for some reason. Are there any particular nicks I should ping on IRC? #freedesktop on freenode is the channel where fd.o admins hang out. Got that sorted out and pushed this series. Hope I didn't break anything. :-o ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/24] Add support for R40 HDMI pipeline
On Mon, Jun 25, 2018 at 02:02:40PM +0200, Jernej Skrabec wrote: > This series adds support for R40 HDMI pipeline. It is a bit special > than other already supported pipelines because it has additional unit > called TCON TOP responsible for relationship configuration between > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI > and TV TCONs, TV encoder clock settings and pin muxing between LCD > and TV encoders. > > However, it seems that TCON TOP will become a norm, since newer > Allwinner SoCs like H6 also have this unit. > > I tested different possible configurations: > - mixer0 <> TCON-TV0 <> HDMI > - mixer0 <> TCON-TV1 <> HDMI > - mixer1 <> TCON-TV0 <> HDMI > - mixer1 <> TCON-TV1 <> HDMI > > Please review. I just applied it. It didn't apply cleanly, so please make sure it does next time, or at least state what the dependencies are. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On Tue, Jun 12, 2018 at 01:18:29PM +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| 423 > drivers/gpu/drm/drm_dp_helper.c | 1 + > include/drm/drm_dp_helper.h | 56 + > 5 files changed, 491 insertions(+) > create mode 100644 drivers/gpu/drm/drm_dp_cec.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index deeefa7a1773..d63876425cdc 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -121,6 +121,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 50093ff4479b..c787481c2502 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_MM_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 ..555a9fca3fef > --- /dev/null > +++ b/drivers/gpu/drm/drm_dp_cec.c > @@ -0,0 +1,423 @@ > +// 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
Re: [PATCH] drm/etnaviv: bring back progress check in job timeout handler
Lucas Stach writes: > When the hangcheck handler was replaced by the DRM scheduler timeout > handling we dropped the forward progress check, as this might allow > clients to hog the GPU for a long time with a big job. > > It turns out that even reasonably well behaved clients like the > Armada Xorg driver occasionally trip over the 500ms timeout. Bring > back the forward progress check to get rid of the userspace regression. > > We would still like to fix userspace to submit smaller batches > if possible, but that is for another day. > > Fixes: 6d7a20c07760 (drm/etnaviv: replace hangcheck with scheduler timeout) > Signed-off-by: Lucas Stach I was just wondering if there was a way to do this with the scheduler (I had a similar issue with GTF-GLES2.gtf.GL.acos.acos_float_vert_xvary), and this looks correct. As far as I can see, the fence_completed check shouldn't be necessary, since you'll get a cancel_delayed_work_sync() once the job finish happens, so you're only really protecting from a timeout not detecting progress in between fence signal and job finish, but we expect job finish to be quick. Regardless, Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: Augment the TPO TPG110 bindings
On Thu, Jun 21, 2018 at 08:49:41PM +0200, Linus Walleij wrote:
> The TPO TPG110 bindings were using the DPI bindings (popular
> in the fbdev subsystem) but this misses the finer points
> learned in the DRM subsystem.
>
> We need to augment the bindings for proper DRM integration:
> the timings are expressed by the hardware, not put into the
> device tree.
>
> Old device trees with the DPI info will continue to work,
> but no known deployments exist.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
> ---
> .../bindings/display/panel/tpo,tpg110.txt | 34 ---
> 1 file changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> index f5e3c6f2095a..0e918076d55e 100644
> --- a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> +++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> @@ -1,26 +1,32 @@
> TPO TPG110 Panel
>
>
> -This binding builds on the DPI bindings, adding a few properties
> -as a superset of a DPI. See panel-dpi.txt for the required DPI
> -bindings.
> +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...
If you remove timings, how does it drive a variety of panels? Just by
compatible? That would mean "tpo,tpg110" alone is not valid nor useful
as a fallback.
> +a few GPIO lines for control of its reset line and custom serial
> +protocol.
>
> Required properties:
> -- compatible : "tpo,tpg110"
> +- compatible : one of:
> + "ste,nomadik-nhk15-display", "tpo,tpg110"
> + "tpo,tpg110"
> - grestb-gpios : panel reset GPIO
> - scen-gpios : serial control enable GPIO
> - scl-gpios : serial control clock line GPIO
> - sda-gpios : serial control data line GPIO
I2C? That should be done differently...
> +- width-mm : see display/panel/panel-common.txt
> +- height-mm : see display/panel/panel-common.txt
>
> -Required nodes:
> -- Video port for DPI input, see panel-dpi.txt
> -- Panel timing for DPI setup, see panel-dpi.txt
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in
> +media/video-interfaces.txt. This node should describe panel's video bus.
>
> Example
> ---
>
> panel {
> - compatible = "tpo,tpg110", "panel-dpi";
> + compatible = "tpo,tpg110";
> + width-mm = <116>;
> + height-mm = <87>;
> grestb-gpios = <_gpio44 5 GPIO_ACTIVE_LOW>;
> scen-gpios = < 6 GPIO_ACTIVE_LOW>;
> scl-gpios = < 5 GPIO_ACTIVE_HIGH>;
> @@ -32,16 +38,4 @@ panel {
> remote-endpoint = <_clcd_pads>;
> };
> };
> -
> - panel-timing {
> - clock-frequency = <3320>;
> - hactive = <800>;
> - hback-porch = <216>;
> - hfront-porch = <40>;
> - hsync-len = <1>;
> - vactive = <480>;
> - vback-porch = <35>;
> - vfront-porch = <10>;
> - vsync-len = <1>;
> - };
> };
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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
[Bug 106430] GPU hang when played video with acceleration (vaapi)
https://bugs.freedesktop.org/show_bug.cgi?id=106430 --- Comment #10 from mikhail.v.gavri...@gmail.com --- Benjamin, I see that in Fedora 29 (Rawhide) with kernel 4.18.0-0.rc0.git9.1.fc29 problem was gone. But with kernel 4.18.0-0.rc0.git10.1.fc29.x86_64 came yet another problem (video output at least DP stop working) -- 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 106430] GPU hang when played video with acceleration (vaapi)
https://bugs.freedesktop.org/show_bug.cgi?id=106430 --- Comment #9 from Benjamin Xiao --- I am seeing the same thing with VLC when setting Hardware-accelerated decoding from Automatic to VA-API. Fedora 28 RX Vega 64 Kernel 4.17.2 mesa 18.0.5 llvm 6 -- 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/etnaviv: bring back progress check in job timeout handler
Hi Lucas, On Wed, Jun 27, 2018 at 11:34 AM, Lucas Stach wrote: > When the hangcheck handler was replaced by the DRM scheduler timeout > handling we dropped the forward progress check, as this might allow > clients to hog the GPU for a long time with a big job. > > It turns out that even reasonably well behaved clients like the > Armada Xorg driver occasionally trip over the 500ms timeout. Bring > back the forward progress check to get rid of the userspace regression. > > We would still like to fix userspace to submit smaller batches > if possible, but that is for another day. > > Fixes: 6d7a20c07760 (drm/etnaviv: replace hangcheck with scheduler timeout) Maybe you could add a Reported-by tag from Russell? > Signed-off-by: Lucas Stach > + /* > +* If the GPU managed to complete this jobs fence, the timout is s/timout/timeout Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Move BUG_ON from _add_shared_fence to _add_shared_inplace
On 2018-06-27 01:50 PM, Chris Wilson wrote:
> Quoting Michel Dänzer (2018-06-26 15:31:47)
>> From: Michel Dänzer
>>
>> Fixes the BUG_ON spuriously triggering under the following
>> circumstances:
>>
>> * ttm_eu_reserve_buffers processes a list containing multiple BOs using
>> the same reservation object, so it calls
>> reservation_object_reserve_shared with that reservation object once
>> for each such BO.
>> * In reservation_object_reserve_shared, old->shared_count ==
>> old->shared_max - 1, so obj->staged is freed in preparation of an
>> in-place update.
>> * ttm_eu_fence_buffer_objects calls reservation_object_add_shared_fence
>> once for each of the BOs above, always with the same fence.
>> * The first call adds the fence in the remaining free slot, after which
>> old->shared_count == old->shared_max.
>>
>> In the next call to reservation_object_add_shared_fence, the BUG_ON
>> triggers. However, nothing bad would happen in
>> reservation_object_add_shared_inplace, since the fence is already in the
>> reservation object.
>>
>> Prevent this by moving the BUG_ON to where an overflow would actually
>> happen (e.g. if a buggy caller didn't call
>> reservation_object_reserve_shared before).
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Michel Dänzer
>
> I've convinced myself (or rather have not found a valid argument
> against) that being able to call reserve_shared + add_shared multiple
> times for the same fence is an intended part of reservation_object API
>
> I'd double check with Christian though.
Right, I'm interested in Christian's feedback.
> Reviewed-by: Chris Wilson
Thanks!
>> drivers/dma-buf/reservation.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>> index 314eb1071cce..532545b9488e 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -141,6 +141,7 @@ reservation_object_add_shared_inplace(struct
>> reservation_object *obj,
>> if (signaled) {
>> RCU_INIT_POINTER(fobj->shared[signaled_idx], fence);
>> } else {
>> + BUG_ON(fobj->shared_count >= fobj->shared_max);
>
> Personally I would just let kasan detect this and throw away the BUG_ON
> or at least move it behind some DMABUF_BUG_ON().
Hmm. Normally, I'm not a fan of BUG(_ON) either. But in this case, it's
clear that the caller is buggy, and proceeding to write beyond the end
of the array could have far-reaching consequences. I'm leaving that to
somebody else.
--
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
[Bug 107053] Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04
https://bugs.freedesktop.org/show_bug.cgi?id=107053 --- Comment #2 from cen.is.i...@gmail.com --- Created attachment 140367 --> https://bugs.freedesktop.org/attachment.cgi?id=140367=edit dmesg attached dmesg -- 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 107053] Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04
https://bugs.freedesktop.org/show_bug.cgi?id=107053 --- Comment #1 from Michel Dänzer --- Please attach the corresponding dmesg output as well. -- 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 107053] Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04
https://bugs.freedesktop.org/show_bug.cgi?id=107053 Michel Dänzer changed: What|Removed |Added Attachment #140366|text/x-log |text/plain mime type|| -- 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 106544] Boot error: gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu] dce110_stream_encoder_update_hdmi_info_packets+0x20e/0x3a0 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=106544 --- Comment #8 from Harald Judt --- I have experienced no bad symptoms caused by this error so far on my R9 390, but I also get these after hibernate/resume and will try if reverting the patch mentioned in Comment #4 gets rid of them. -- 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 107053] Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04
https://bugs.freedesktop.org/show_bug.cgi?id=107053 Bug ID: 107053 Summary: Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: cen.is.i...@gmail.com Created attachment 140366 --> https://bugs.freedesktop.org/attachment.cgi?id=140366=edit xorg log Symptom: flicker or tearing (not sure what to call it) at the bottom of the screen as seen in this videos: Fedora 28 (old install): https://www.youtube.com/watch?v=q9tHH2LdYOc Ubuntu 18.04 (currently installed, with glxgears info in description): https://youtu.be/CsFHt74HY3A Tested on: Debian Jessie KDE, Kubuntu 18.04, Fedora 28, Elementary OS Loki, Ubuntu 18.04, all exact same symptom. Hardware: Macbook Pro 11.5 lshw: *-display description: VGA compatible controller product: Venus XT [Radeon HD 8870M / R9 M270X/M370X] vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 0 bus info: pci@:01:00.0 version: 83 width: 64 bits clock: 33MHz capabilities: pm pciexpress msi vga_controller bus_master cap_list rom configuration: driver=radeon latency=0 resources: irq:51 memory:8000-8fff memory:b0c0-b0c3 ioport:3000(size=256) memory:b0c4-b0c5 Added TearFree, DRI3 and glamor to try to remedy the symptom, nothing changed: cat /usr/share/X11/xorg.conf.d/20-radeon.conf Section "Device" Identifier "Radeon" Driver "radeon" Option "TearFree" "on" Option "DRI" "3" Option "AccelMethod" "glamor" EndSection Xorg log attached. Some device busy errors seen at the bottom, not sure if it has any relation. Nothing really interesting in dmesg. Symptop appears even at single monitor, however, my current setup is triple external plus native hidpi: xrandr --fbmm 11520x4200 --output eDP --pos 4320x2400 --mode 2880x1800 --scale 1x1 --primary --output DisplayPort-1 --pos 0x0 --mode 1920x1200 --scale 2x2 --output DisplayPort-0 --pos 3840x0 --mode 1920x1200 --scale 2x2 --output HDMI-0 --pos 7680x0 --mode 1920x1200 --scale 2x2 -- 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 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output
https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #17 from Harry Wentland --- I think we had a fix for that. Can you check if this is still a problem on https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next -- 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 02/10] drm: crc: Introduce pre_crc_read function
Hi,
On 6/27/2018 8:48 PM, Maarten Lankhorst wrote:
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_debugfs_crc.c | 8
include/drm/drm_crtc.h| 14 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index c6a725b79ac6..2b4a737c5aeb 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -278,6 +278,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
__user *user_buf,
return 0;
}
+ if (crtc->funcs->pre_crc_read) {
+ ret = crtc->funcs->pre_crc_read(crtc);
+ if (ret) {
+ spin_unlock_irq(>lock);
+ return ret;
+ }
+ }
+
/* Nothing to read? */
while (crtc_crc_data_count(crc) == 0) {
if (filep->f_flags & O_NONBLOCK) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a6dcbf91744..bae432469616 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,20 @@ struct drm_crtc_funcs {
*/
int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @pre_crc_read:
+*
+* Driver callback for performing any preparation work required by
+* driver before reading CRC
+*
+* This callback is optional if the driver does not support CRC
+* generation or no prework is required before reading the crc
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*pre_crc_read)(struct drm_crtc *crtc);
/**
* @atomic_print_state:
I think this patch might have to be dropped, or reordered after the revert in
10/10, because else in theory open could block. :)
Or maybe just drop until we have upstream kernel users?
thanks,
Can reorder it after patch-10 and if others also vote to drop it will
take decision accordingly, atleast it should not block other patches :)
-Mahesh
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] Revert "drm: crc: Wait for a frame before returning from open()"
Op 27-06-18 om 16:44 schreef Mahesh Kumar: > This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. > > Don't wait for first CRC during crtc_crc_open. It avoids one frame wait > during open. If application want to wait after read call, it can use > poll/read blocking read() call. > > Suggested-by: Ville Syrjälä > Signed-off-by: Mahesh Kumar > Cc: dri-devel@lists.freedesktop.org > Cc: Tomeu Vizoso > --- > drivers/gpu/drm/drm_debugfs_crc.c | 16 > 1 file changed, 16 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 08dfe19b6286..7aeed89f934a 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -226,24 +226,8 @@ static int crtc_crc_open(struct inode *inode, struct > file *filep) > if (ret) > goto err; > > - spin_lock_irq(>lock); > - /* > - * Only return once we got a first frame, so userspace doesn't have to > - * guess when this particular piece of HW will be ready to start > - * generating CRCs. > - */ > - ret = wait_event_interruptible_lock_irq(crc->wq, > - crtc_crc_data_count(crc), > - crc->lock); > - spin_unlock_irq(>lock); > - > - if (ret) > - goto err_disable; > - > return 0; > > -err_disable: > - crtc->funcs->set_crc_source(crtc, NULL); > err: > spin_lock_irq(>lock); > crtc_crc_cleanup(crc); For the whole series except 2/10: Reviewed-by: Maarten Lankhorst ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] drm: crc: Introduce pre_crc_read function
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
> This patch implements a callback function "pre_crc_read" which will
> be called before crc read. In this function driver can implement and
> preparation work required for successfully reading CRC data.
>
> Signed-off-by: Mahesh Kumar
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 8
> include/drm/drm_crtc.h| 14 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index c6a725b79ac6..2b4a737c5aeb 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -278,6 +278,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> __user *user_buf,
> return 0;
> }
>
> + if (crtc->funcs->pre_crc_read) {
> + ret = crtc->funcs->pre_crc_read(crtc);
> + if (ret) {
> + spin_unlock_irq(>lock);
> + return ret;
> + }
> + }
> +
> /* Nothing to read? */
> while (crtc_crc_data_count(crc) == 0) {
> if (filep->f_flags & O_NONBLOCK) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 1a6dcbf91744..bae432469616 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -676,6 +676,20 @@ struct drm_crtc_funcs {
>*/
> int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
>size_t *values_cnt);
> + /**
> + * @pre_crc_read:
> + *
> + * Driver callback for performing any preparation work required by
> + * driver before reading CRC
> + *
> + * This callback is optional if the driver does not support CRC
> + * generation or no prework is required before reading the crc
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> + int (*pre_crc_read)(struct drm_crtc *crtc);
>
> /**
>* @atomic_print_state:
I think this patch might have to be dropped, or reordered after the revert in
10/10, because else in theory open could block. :)
Or maybe just drop until we have upstream kernel users?
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm: Add drm_for_each_connector_encoder_ids()
On Wed, Jun 27, 2018 at 11:11:57AM +0200, Daniel Vetter wrote:
> On Wed, Jun 27, 2018 at 11:08:48AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 26, 2018 at 08:47:09PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a convenience macro for iterating connector->encoder_ids[].
> > > Isolates the users from the implementation details.
> > >
> > > Also use ARRAY_SIZE() when populating the array to avoid spreading
> > > knowledge about the array size all over.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_connector.c| 22 ++
> > > drivers/gpu/drm/drm_fb_helper.c| 6 +++---
> > > drivers/gpu/drm/drm_probe_helper.c | 9 +
> > > include/drm/drm_connector.h| 11 +++
> > > 4 files changed, 29 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > b/drivers/gpu/drm/drm_connector.c
> > > index 2f9ebddd178e..c43646cb8145 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -321,7 +321,7 @@ int drm_mode_connector_attach_encoder(struct
> > > drm_connector *connector,
> > > if (WARN_ON(connector->encoder))
> > > return -EINVAL;
> > >
> > > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> > > + for (i = 0; i < ARRAY_SIZE(connector->encoder_ids); i++) {
> > > if (connector->encoder_ids[i] == 0) {
> > > connector->encoder_ids[i] = encoder->base.id;
> > > return 0;
> > > @@ -1693,6 +1693,7 @@ int drm_mode_getconnector(struct drm_device *dev,
> > > void *data,
> > > int encoders_count = 0;
> > > int ret = 0;
> > > int copied = 0;
> > > + u32 encoder_id;
> > > int i;
> > > struct drm_mode_modeinfo u_mode;
> > > struct drm_mode_modeinfo __user *mode_ptr;
> > > @@ -1708,22 +1709,19 @@ int drm_mode_getconnector(struct drm_device *dev,
> > > void *data,
> > > if (!connector)
> > > return -ENOENT;
> > >
> > > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
> > > - if (connector->encoder_ids[i] != 0)
> > > - encoders_count++;
> > > + drm_for_each_connector_encoder_ids(connector, encoder_id, i)
> > > + encoders_count++;
> > >
> > > if ((out_resp->count_encoders >= encoders_count) && encoders_count) {
> > > copied = 0;
> > > encoder_ptr = (uint32_t __user *)(unsigned
> > > long)(out_resp->encoders_ptr);
> > > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> > > - if (connector->encoder_ids[i] != 0) {
> > > - if (put_user(connector->encoder_ids[i],
> > > - encoder_ptr + copied)) {
> > > - ret = -EFAULT;
> > > - goto out;
> > > - }
> > > - copied++;
> > > +
> > > + drm_for_each_connector_encoder_ids(connector, encoder_id, i) {
> > > + if (put_user(encoder_id, encoder_ptr + copied)) {
> > > + ret = -EFAULT;
> > > + goto out;
> > > }
> > > + copied++;
> > > }
> > > }
> > > out_resp->count_encoders = encoders_count;
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 61c39cd75a27..e086b08748f4 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -2326,12 +2326,12 @@ static bool drm_target_preferred(struct
> > > drm_fb_helper *fb_helper,
> > > static bool connector_crtc_ok(struct drm_connector *connector,
> > > struct drm_crtc *crtc)
> > > {
> > > + u32 encoder_id;
> > > int i;
> > >
> > > - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> > > + drm_for_each_connector_encoder_ids(connector, encoder_id, i) {
> > > struct drm_encoder *encoder =
> > > - drm_encoder_find(connector->dev, NULL,
> > > - connector->encoder_ids[i]);
> > > + drm_encoder_find(connector->dev, NULL, encoder_id);
> > >
> > > if (encoder->possible_crtcs & drm_crtc_mask(crtc))
> > > return true;
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 527743394150..0239f76c52fb 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -88,9 +88,9 @@ drm_mode_validate_pipeline(struct drm_display_mode
> > > *mode,
> > > struct drm_connector *connector)
> > > {
> > > struct drm_device *dev = connector->dev;
> > > - uint32_t *ids = connector->encoder_ids;
> > > enum drm_mode_status ret = MODE_OK;
> > > - unsigned int i;
> > > + u32 encoder_id;
> > > + int i;
> > >
> > > /* Step 1: Validate against connector */
> > > ret =
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #11 from Harry Wentland (harry.wentl...@amd.com) --- Should be fixed by https://patchwork.freedesktop.org/patch/230831/ which is merged into amd-staging-drm-next -- 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 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit
https://bugs.freedesktop.org/show_bug.cgi?id=103277 --- Comment #25 from Harry Wentland --- Is this fixed on recent kernels? If so, can we close this one? -- 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 105354] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=105354 Harry Wentland changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Harry Wentland --- Marking fixed as per last comment. For different issues please open a new bug report. -- 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: [Intel-gfx] [PATCH v3 4/9] drm/cma-helper: Use the generic fbdev emulation
Hi Noralf,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180627]
[cannot apply to drm/drm-next linus/master drm-exynos/exynos-drm/for-next
v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
[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/Noralf-Tr-nnes/drm-Add-generic-fbdev-emulation/20180627-222604
config: i386-randconfig-x018-201825 (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=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 67 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 2 drivers/gpu/drm/drm_fb_cma_helper.c:to_fbdev_cma
Cyclomatic Complexity 3
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fb_cma_get_gem_obj
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fb_cma_get_gem_addr
Cyclomatic Complexity 4
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_init
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fb_cma_fbdev_init
Cyclomatic Complexity 1
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fb_cma_fbdev_init_with_funcs
Cyclomatic Complexity 1
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_fini
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fb_cma_fbdev_fini
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_restore_mode
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_hotplug_event
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_set_suspend
Cyclomatic Complexity 2
drivers/gpu/drm/drm_fb_cma_helper.c:drm_fbdev_cma_set_suspend_unlocked
drivers/gpu/drm/drm_fb_cma_helper.c: In function 'drm_fbdev_cma_init':
>> drivers/gpu/drm/drm_fb_cma_helper.c:197:2: warning: 'client' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
drm_client_release(client);
^~
vim +/client +197 drivers/gpu/drm/drm_fb_cma_helper.c
162
163 /**
164 * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma
struct
165 * @dev: DRM device
166 * @preferred_bpp: Preferred bits per pixel for the device
167 * @max_conn_count: Maximum number of connectors
168 *
169 * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
170 */
171 struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
172 unsigned int preferred_bpp, unsigned int max_conn_count)
173 {
174 struct drm_fbdev_cma *fbdev_cma;
175 struct drm_fb_helper *fb_helper;
176 struct drm_client_dev *client;
177 int ret;
178
179 fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
180 if (!fbdev_cma)
181 return ERR_PTR(-ENOMEM);
182
183 fb_helper = _cma->fb_helper;
184
185 ret = drm_client_new(dev, _helper->client, "fbdev");
186 if (ret)
187 goto err_free;
188
189 ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
_fb_cma_helper_funcs,
190 preferred_bpp, max_conn_count);
191 if (ret)
192 goto err_client_put;
193
194 return fbdev_cma;
195
196 err_client_put:
> 197 drm_client_release(client);
198 err_free:
199 kfree(fbdev_cma);
200
201 return ERR_PTR(ret);
202 }
203 EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
204
---
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
[Bug 107049] monitor not found in 4.17+ kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107049 --- Comment #8 from Dan Horák --- Created attachment 140365 --> https://bugs.freedesktop.org/attachment.cgi?id=140365=edit Xorg log for 4.17.2-200.fc28 with amdgpu.dc=0 -- 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
[RFC PATCH] misc/mei/hdcp: mei_hdcp_component_registered can be static
Fixes: 0654edaa3690 ("misc/mei/hdcp: Component framework for I915 Interface")
Signed-off-by: kbuild test robot
---
mei_hdcp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ba75502..146a4be 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -34,10 +34,10 @@
#include
#include
-bool mei_hdcp_component_registered;
+static bool mei_hdcp_component_registered;
static struct mei_cl_device *mei_cldev;
-struct i915_hdcp_component_ops mei_hdcp_component_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_component_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = NULL,
.verify_receiver_cert_prepare_km= NULL,
@@ -87,7 +87,7 @@ static const struct component_ops mei_hdcp_component_bind_ops
= {
.unbind = mei_hdcp_component_unbind,
};
-void mei_hdcp_component_init(struct device *dev)
+static void mei_hdcp_component_init(struct device *dev)
{
int ret;
@@ -100,7 +100,7 @@ void mei_hdcp_component_init(struct device *dev)
mei_hdcp_component_registered = true;
}
-void mei_hdcp_component_cleanup(struct device *dev)
+static void mei_hdcp_component_cleanup(struct device *dev)
{
if (!mei_hdcp_component_registered)
return;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 28/40] misc/mei/hdcp: Component framework for I915 Interface
Hi Ramalingam, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20180627] [cannot apply to v4.18-rc2] [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/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180627-174219 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/misc/mei/hdcp/mei_hdcp.c:37:6: sparse: symbol >> 'mei_hdcp_component_registered' was not declared. Should it be static? >> drivers/misc/mei/hdcp/mei_hdcp.c:40:32: sparse: symbol >> 'mei_hdcp_component_ops' was not declared. Should it be static? >> drivers/misc/mei/hdcp/mei_hdcp.c:90:6: sparse: symbol >> 'mei_hdcp_component_init' was not declared. Should it be static? >> drivers/misc/mei/hdcp/mei_hdcp.c:103:6: sparse: symbol >> 'mei_hdcp_component_cleanup' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 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
[Bug 107049] monitor not found in 4.17+ kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107049 --- Comment #7 from Dan Horák --- Created attachment 140364 --> https://bugs.freedesktop.org/attachment.cgi?id=140364=edit Xorg log for 4.18.0-0.rc2.git2.1.fc29 -- 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 09/10] drm/crc: Cleanup crtc_crc_open function
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4 +-
drivers/gpu/drm/drm_debugfs_crc.c | 52 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pipe_crc.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +--
include/drm/drm_crtc.h | 3 +-
8 files changed, 30 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index e43ed064dc46..54056d180003 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -258,8 +258,7 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
/* amdgpu_dm_crc.c */
#ifdef CONFIG_DEBUG_FS
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt);
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *src_name,
size_t *values_cnt);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index dfcca594d52a..e7ad528f5853 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -62,8 +62,7 @@ amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const
char *src_name,
return 0;
}
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt)
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
struct dm_crtc_state *crtc_state = to_dm_crtc_state(crtc->state);
struct dc_stream_state *stream_state = crtc_state->stream;
@@ -99,7 +98,6 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc,
const char *src_name,
return -EINVAL;
}
- *values_cnt = 3;
/* Reset crc_skipped on dm state */
crtc_state->crc_skip_count = 0;
return 0;
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index a7b6d5de81de..08dfe19b6286 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -124,11 +124,9 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
+ if (ret)
+ return ret;
spin_lock_irq(>lock);
@@ -193,12 +191,15 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
return ret;
}
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, crc->source,
-_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source, _cnt);
+ if (ret)
+ return ret;
+
+ if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
+ return -EINVAL;
+
+ if (WARN_ON(values_cnt == 0))
+ return -EINVAL;
spin_lock_irq(>lock);
if (!crc->opened)
@@ -210,30 +211,22 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
if (ret)
return ret;
- ret = crtc->funcs->set_crc_source(crtc, crc->source, _cnt);
- if (ret)
- goto err;
-
- if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
- if (WARN_ON(values_cnt == 0)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
if (!entries) {
ret = -ENOMEM;
- goto err_disable;
+ goto err;
}
spin_lock_irq(>lock);
crc->entries = entries;
crc->values_cnt = values_cnt;
+
[PATCH 07/10] drm/i915/crc: implement verify_crc_source callback
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 108 ++
3 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eaa0663963a5..821754fb49f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12893,6 +12893,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
+ .verify_crc_source = intel_crtc_verify_crc_source,
};
struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6ff2600a3a0..764b53dfe7de 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2156,10 +2156,13 @@ int intel_pipe_crc_create(struct drm_minor *minor);
#ifdef CONFIG_DEBUG_FS
int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
size_t *values_cnt);
+int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *source_name, size_t *values_cnt);
void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
#else
#define intel_crtc_set_crc_source NULL
+#define intel_crtc_verify_crc_source NULL
static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
{
}
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 39a4e4edda07..a37521380f94 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -913,6 +913,114 @@ int intel_pipe_crc_create(struct drm_minor *minor)
return 0;
}
+static int i8xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int i9xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_TV:
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ case INTEL_PIPE_CRC_SOURCE_DP_D:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int vlv_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ case INTEL_PIPE_CRC_SOURCE_DP_D:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ilk_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ivb_crc_source_valid(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ case INTEL_PIPE_CRC_SOURCE_PF:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int
+intel_is_valid_crc_source(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+ if (IS_GEN2(dev_priv))
+ return i8xx_crc_source_valid(dev_priv, source);
+ else if (INTEL_GEN(dev_priv) < 5)
+ return i9xx_crc_source_valid(dev_priv, source);
+ else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ return vlv_crc_source_valid(dev_priv, source);
+ else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
+ return ilk_crc_source_valid(dev_priv, source);
+ else
+ return ivb_crc_source_valid(dev_priv, source);
+}
+
+int
[PATCH 05/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 655950102827..b2f357cb8f7f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2563,6 +2563,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs =
{
.atomic_duplicate_state = dm_crtc_duplicate_state,
.atomic_destroy_state = dm_crtc_destroy_state,
.set_crc_source = amdgpu_dm_crtc_set_crc_source,
+ .verify_crc_source = amdgpu_dm_crtc_verify_crc_source,
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index a29dc35954c9..e43ed064dc46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
#ifdef CONFIG_DEBUG_FS
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt);
+int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *src_name,
+size_t *values_cnt);
void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc);
#else
#define amdgpu_dm_crtc_set_crc_source NULL
+#define amdgpu_dm_crtc_verify_crc_source NULL
#define amdgpu_dm_crtc_handle_crc_irq(x)
#endif
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 52f2c01349e3..dfcca594d52a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source
dm_parse_crc_source(const char *source)
return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID;
}
+int
+amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name,
+size_t *values_cnt)
+{
+ enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name);
+
+ if (source < 0) {
+ DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n",
+src_name, crtc->index);
+ return -EINVAL;
+ }
+
+ *values_cnt = 3;
+ return 0;
+}
+
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt)
{
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] Revert "drm: crc: Wait for a frame before returning from open()"
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. Don't wait for first CRC during crtc_crc_open. It avoids one frame wait during open. If application want to wait after read call, it can use poll/read blocking read() call. Suggested-by: Ville Syrjälä Signed-off-by: Mahesh Kumar Cc: dri-devel@lists.freedesktop.org Cc: Tomeu Vizoso --- drivers/gpu/drm/drm_debugfs_crc.c | 16 1 file changed, 16 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 08dfe19b6286..7aeed89f934a 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -226,24 +226,8 @@ static int crtc_crc_open(struct inode *inode, struct file *filep) if (ret) goto err; - spin_lock_irq(>lock); - /* -* Only return once we got a first frame, so userspace doesn't have to -* guess when this particular piece of HW will be ready to start -* generating CRCs. -*/ - ret = wait_event_interruptible_lock_irq(crc->wq, - crtc_crc_data_count(crc), - crc->lock); - spin_unlock_irq(>lock); - - if (ret) - goto err_disable; - return 0; -err_disable: - crtc->funcs->set_crc_source(crtc, NULL); err: spin_lock_irq(>lock); crtc_crc_cleanup(crc); -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/rockchip/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Changes since V1:
- simplify the verification (Jani N)
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index effecbed2d11..77e91b15ddb4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1138,12 +1138,31 @@ static int vop_crtc_set_crc_source(struct drm_crtc
*crtc,
return ret;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ if (source_name && strcmp(source_name, "auto") != 0)
+ return -EINVAL;
+
+ *values_cnt = 3;
+ return 0;
+}
+
#else
static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name, size_t *values_cnt)
{
return -ENODEV;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ return -ENODEV;
+}
#endif
static const struct drm_crtc_funcs vop_crtc_funcs = {
@@ -1156,6 +1175,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
.set_crc_source = vop_crtc_set_crc_source,
+ .verify_crc_source = vop_crtc_verify_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] drm/i915/crc: implement get_crc_sources callback
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Changes since V1:
- Return array of crc sources
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pipe_crc.c | 7 +++
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 821754fb49f1..b7951b3587e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12894,6 +12894,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
.verify_crc_source = intel_crtc_verify_crc_source,
+ .get_crc_sources = intel_crtc_get_crc_sources,
};
struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 764b53dfe7de..99e3b6477d39 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2158,11 +2158,14 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name,
size_t *values_cnt);
int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *source_name, size_t *values_cnt);
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count);
void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
#else
#define intel_crtc_set_crc_source NULL
#define intel_crtc_verify_crc_source NULL
+#define intel_crtc_get_crc_sources NULL
static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
{
}
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index a37521380f94..1dffc346f1bc 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -1001,6 +1001,13 @@ intel_is_valid_crc_source(struct drm_i915_private
*dev_priv,
return ivb_crc_source_valid(dev_priv, source);
}
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count)
+{
+ *count = ARRAY_SIZE(pipe_crc_sources);
+ return pipe_crc_sources;
+}
+
int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char
*source_name,
size_t *values_cnt)
{
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/rcar-du/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15dc9caa128b..24eeaa7e14d7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -756,6 +756,45 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc
*crtc)
rcrtc->vblank_enable = false;
}
+static int rcar_du_crtc_verify_crc_source(struct drm_crtc *crtc,
+ const char *source_name,
+ size_t *values_cnt)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ unsigned int index = 0;
+ unsigned int i;
+ int ret;
+
+ /*
+* Parse the source name. Supported values are "plane%u" to compute the
+* CRC on an input plane (%u is the plane ID), and "auto" to compute the
+* CRC on the composer (VSP) output.
+*/
+ if (!source_name || !strcmp(source_name, "auto")) {
+ goto out;
+ } else if (strstarts(source_name, "plane")) {
+ ret = kstrtouint(source_name + strlen("plane"), 10, );
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
+ if (index == rcrtc->vsp->planes[i].plane.base.id) {
+ index = i;
+ break;
+ }
+ }
+
+ if (i >= rcrtc->vsp->num_planes)
+ return -EINVAL;
+ } else {
+ return -EINVAL;
+ }
+
+out:
+ *values_cnt = 1;
+ return 0;
+}
+
static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name,
size_t *values_cnt)
@@ -861,6 +900,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.enable_vblank = rcar_du_crtc_enable_vblank,
.disable_vblank = rcar_du_crtc_disable_vblank,
.set_crc_source = rcar_du_crtc_set_crc_source,
+ .verify_crc_source = rcar_du_crtc_verify_crc_source,
};
/*
-
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] drm: crc: Introduce get_crc_sources callback
This patch implements a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
Changes Since V1: (Daniel)
- return const pointer to an array of crc sources list
- do validation of sources in CRC-core
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
include/drm/drm_crtc.h| 16
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 2b4a737c5aeb..a7b6d5de81de 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -67,9 +67,27 @@
static int crc_control_show(struct seq_file *m, void *data)
{
struct drm_crtc *crtc = m->private;
+ size_t count;
+
+ if (crtc->funcs->get_crc_sources) {
+ const char *const *sources = crtc->funcs->get_crc_sources(crtc,
+ );
+ size_t values_cnt;
+ int i;
+
+ if (count <= 0 || !sources)
+ goto out;
+
+ seq_puts(m, "[");
+ for (i = 0; i < count; i++)
+ if (!crtc->funcs->verify_crc_source(crtc, sources[i],
+ _cnt))
+ seq_printf(m, "%s ", sources[i]);
+ seq_puts(m, "] ");
+ }
+out:
seq_printf(m, "%s\n", crtc->crc.source);
-
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bae432469616..594326664abe 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -690,6 +690,22 @@ struct drm_crtc_funcs {
* 0 on success or a negative error code on failure.
*/
int (*pre_crc_read)(struct drm_crtc *crtc);
+ /**
+* @get_crc_sources:
+*
+* Driver callback for getting a list of all the available sources for
+* CRC generation.
+*
+* This callback is optional if the driver does not support exporting of
+* possible CRC sources list. CRC-core does the verification of sources.
+*
+* RETURNS:
+*
+* a constant character pointer to the list of all the available CRC
+* sources
+*/
+ const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
+ size_t *count);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] Improve crc-core driver interface
This series improves crc-core <-> driver interface. This series adds following functionality in the crc-core - Now control node will print all the available sources if implemented by driver along with current source. - Setting of sorce will fail if provided source is not supported - cleanup of crtc_crc_open function first allocate memory before enabling CRC generation - Don't block open() call instead wait in crc read call. Following IGT will fail due to crc-core <-> driver interface change igt@kms_pipe_crc_basic@bad-source ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence In nonblocking crc tests we'll get lesser crc's due to skipping crc AMD/Rockchip/rcar code path is not validated and need inputs Changes: - Add dri-devel in Cc Changes rev2: - now get_crc_sources returns a constant pointer to an array of source list and crc-core does the verification Cc: dri-devel@lists.freedesktop.org Mahesh Kumar (10): drm: crc: Introduce verify_crc_source callback drm: crc: Introduce pre_crc_read function 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()" 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 | 78 -- drivers/gpu/drm/i915/intel_display.c | 2 + drivers/gpu/drm/i915/intel_drv.h | 8 +- drivers/gpu/drm/i915/intel_pipe_crc.c | 118 - drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 45 +++- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 26 - include/drm/drm_crtc.h | 47 +++- 10 files changed, 301 insertions(+), 51 deletions(-) -- 2.16.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/10] drm: crc: Introduce verify_crc_source callback
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
include/drm/drm_crtc.h| 15 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 9f8312137cad..c6a725b79ac6 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
struct drm_crtc *crtc = m->private;
struct drm_crtc_crc *crc = >crc;
char *source;
+ size_t values_cnt;
+ int ret = 0;
if (len == 0)
return 0;
@@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (crc->opened) {
@@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
return ret;
}
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source,
+_cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (!crc->opened)
crc->opened = true;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 23eddbccab10..1a6dcbf91744 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -661,6 +661,21 @@ struct drm_crtc_funcs {
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @verify_crc_source:
+*
+* verifies the source of CRC checksums of frames before setting the
+* source for CRC and during crc open.
+*
+* This callback is optional if the driver does not support any CRC
+* generation functionality.
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
+size_t *values_cnt);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/10] drm: crc: Introduce pre_crc_read function
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_debugfs_crc.c | 8
include/drm/drm_crtc.h| 14 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index c6a725b79ac6..2b4a737c5aeb 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -278,6 +278,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
__user *user_buf,
return 0;
}
+ if (crtc->funcs->pre_crc_read) {
+ ret = crtc->funcs->pre_crc_read(crtc);
+ if (ret) {
+ spin_unlock_irq(>lock);
+ return ret;
+ }
+ }
+
/* Nothing to read? */
while (crtc_crc_data_count(crc) == 0) {
if (filep->f_flags & O_NONBLOCK) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a6dcbf91744..bae432469616 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,20 @@ struct drm_crtc_funcs {
*/
int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @pre_crc_read:
+*
+* Driver callback for performing any preparation work required by
+* driver before reading CRC
+*
+* This callback is optional if the driver does not support CRC
+* generation or no prework is required before reading the crc
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*pre_crc_read)(struct drm_crtc *crtc);
/**
* @atomic_print_state:
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!
Hi Russell, Am Dienstag, den 26.06.2018, 17:48 +0200 schrieb Lucas Stach: > Hi Russell, > > Am Dienstag, den 26.06.2018, 16:36 +0100 schrieb Russell King - ARM > Linux: > > On Tue, Jun 26, 2018 at 09:17:26AM +0100, Russell King - ARM Linux > > wrote: > > > On Tue, Jun 19, 2018 at 02:28:46PM +0200, Lucas Stach wrote: > > > > Agreed. I'll look into bringing back the process detection for > > > > 4.17 > > > > stable. > > > > > > > > I'm still curious why the GC600 on the Dove is that slow. With > > > > performance like this moving a big(ish) window on the screen > > > > must > > > > be a > > > > horrible user experience. > > > > > > This doesn't seem to be the cause - it seems that there's > > > something > > > going on with 4.17 that really is causing the Dove GC600 to get > > > stuck. > > > Reverting all the drivers/gpu/drm/etnaviv changes back to the > > > 4.16 > > > state while keeping everything else the same results in no hangs, > > > whereas increasing the timeout with 4.17 still results in hangs. > > > > > > I'll try to find some time to bisect. > > > > Sorry, it seems that my attempts to change what was running on the > > system were ineffective (due to the etnaviv module loaded from the > > initramfs, not from the fs copy I was updating.) Extending the > > timeout to 5 seconds does indeed stop the issue. > > Thanks for confirming that the issue is caused by the removed > progress > check. > > > More importantly, it stops some memory corruption I've observed as > > well, caused by etnaviv freeing buffers when it thinks the GPU has > > timed out while the GPU is still writing to them. > > Urgh, that is really bad. I'll get a fix out of the door tomorrow. I've just sent a patch do to this. Can you please confirm that this fixes your issue on GC600? Thanks, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: bring back progress check in job timeout handler
When the hangcheck handler was replaced by the DRM scheduler timeout
handling we dropped the forward progress check, as this might allow
clients to hog the GPU for a long time with a big job.
It turns out that even reasonably well behaved clients like the
Armada Xorg driver occasionally trip over the 500ms timeout. Bring
back the forward progress check to get rid of the userspace regression.
We would still like to fix userspace to submit smaller batches
if possible, but that is for another day.
Fixes: 6d7a20c07760 (drm/etnaviv: replace hangcheck with scheduler timeout)
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 24
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index dd430f0f8ff5..90f17ff7888e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -131,6 +131,9 @@ struct etnaviv_gpu {
struct work_struct sync_point_work;
int sync_point_event;
+ /* hang detection */
+ u32 hangcheck_dma_addr;
+
void __iomem *mmio;
int irq;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index a74eb57af15b..50d6b88cb7aa 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -10,6 +10,7 @@
#include "etnaviv_gem.h"
#include "etnaviv_gpu.h"
#include "etnaviv_sched.h"
+#include "state.xml.h"
static int etnaviv_job_hang_limit = 0;
module_param_named(job_hang_limit, etnaviv_job_hang_limit, int , 0444);
@@ -85,6 +86,29 @@ static void etnaviv_sched_timedout_job(struct drm_sched_job
*sched_job)
{
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *gpu = submit->gpu;
+ u32 dma_addr;
+ int change;
+
+ /*
+* If the GPU managed to complete this jobs fence, the timout is
+* spurious. Bail out.
+*/
+ if (fence_completed(gpu, submit->out_fence->seqno))
+ return;
+
+ /*
+* If the GPU is still making forward progress on the front-end (which
+* should never loop) we shift out the timeout to give it a chance to
+* finish the job.
+*/
+ dma_addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
+ change = dma_addr - gpu->hangcheck_dma_addr;
+ if (change < 0 || change > 16) {
+ gpu->hangcheck_dma_addr = dma_addr;
+ schedule_delayed_work(_job->work_tdr,
+ sched_job->sched->timeout);
+ return;
+ }
/* block scheduler */
kthread_park(gpu->sched.thread);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107049] monitor not found in 4.17+ kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107049 --- Comment #6 from Ben Crocker --- Dan, Could you please also post the respective /var/log/Xorg.* logs? 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
Re: [PATCH v5 16/40] drm/i915: Implement HDCP2.2 repeater authentication
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc2 next-20180627]
[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/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180627-174219
base: git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/i915/i915_drv.h:3674:16: sparse: expression using
sizeof(void)
>> drivers/gpu/drm/i915/intel_hdcp.c:1451:30: sparse: incorrect type in
>> assignment (different base types) @@expected restricted __be16
>> [assigned] [usertype] k @@got e] k @@
drivers/gpu/drm/i915/intel_hdcp.c:1451:30:expected restricted __be16
[assigned] [usertype] k
drivers/gpu/drm/i915/intel_hdcp.c:1451:30:got int
drivers/gpu/drm/i915/intel_hdcp.c:1890:6: sparse: symbol
'is_hdcp2_supported' was not declared. Should it be static?
vim +1451 drivers/gpu/drm/i915/intel_hdcp.c
1432
1433 static
1434 int hdcp2_propagate_stream_management_info(struct intel_connector
*connector)
1435 {
1436 struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
1437 struct intel_hdcp *hdcp = >hdcp;
1438 union {
1439 struct hdcp2_rep_stream_manage stream_manage;
1440 struct hdcp2_rep_stream_ready stream_ready;
1441 } msgs;
1442 const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
1443 int ret;
1444
1445 /* Prepare RepeaterAuth_Stream_Manage msg */
1446 msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
1447 reverse_endianness(msgs.stream_manage.seq_num_m,
HDCP_2_2_SEQ_NUM_LEN,
1448 (u8 *)>seq_num_m);
1449
1450 /* K no of streams is fixed as 1. Stored as big-endian. */
> 1451 msgs.stream_manage.k = __swab16(1);
1452
1453 /* For HDMI this is forced to be 0x0. For DP SST also this is
0x0. */
1454 msgs.stream_manage.streams[0].stream_id = 0;
1455 msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
1456
1457 /* Send it to Repeater */
1458 ret = shim->write_2_2_msg(intel_dig_port, _manage,
1459sizeof(msgs.stream_manage));
1460 if (ret < 0)
1461 return ret;
1462
1463 ret = shim->read_2_2_msg(intel_dig_port,
HDCP_2_2_REP_STREAM_READY,
1464 _ready,
sizeof(msgs.stream_ready));
1465 if (ret < 0)
1466 return ret;
1467
1468 hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
1469 hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
1470
1471 ret = hdcp2_verify_mprime(connector, _ready);
1472 if (ret < 0)
1473 return ret;
1474
1475 hdcp->seq_num_m++;
1476
1477 if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
1478 DRM_DEBUG_KMS("seq_num_m roll over.\n");
1479 return -1;
1480 }
1481
1482 return 0;
1483 }
1484
---
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: [REGRESSION] 4.18-rc2: X61s thinkpad display unusable after xlock & lid close
On Tue, Jun 26, 2018 at 05:05:48PM -0700, Vito Caputo wrote: > Hello, > > Beginning with 4.18, when I lock my X server using the `xlock` command, > and close the lid, upon reopening the lid I am not presented with the > xlock UI. > > The system is not hung. If I blindly enter the password, I get an > intact and functional pointer but none of the desktop is displayed. I > can move the pointer, and cycling window focus generates some random > noise occasionally, but it's all nonsensical. No windows are > discernable, it's just blackness with ephemeral noise on window cycles, > and a movable pointer. > > The system does not suspend on lid close, with "HandleLidSwitch=ignore" > in logind.conf. So this is a bit odd, since I don't observe this when I > just run `xlock` but don't close/open the lid before unlocking. > > This is on Debian 9.4 amd64, the hardware is a 1.8Ghz X61s ThinkPad, > kernel config attached. I'm using the modesetting Xorg driver on i915 > KMS. Ah, a Thinkpad with lid notifier. Now were getting somewhere :) Can you pls test the stuff I listed here https://bugs.freedesktop.org/show_bug.cgi?id=105902#c5 ? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107045] [4.18rc2] RX470 dGPU on hybrid laptop freezes screen after use
https://bugs.freedesktop.org/show_bug.cgi?id=107045 --- Comment #7 from Michel Dänzer --- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/lib/str_error_r.c?id=854e55ad289efe7991f0ada85d5846f5afb9 is required for building with GCC 8. -- 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 v4 0/3] console/fbcon: Add support for deferred console takeover
On Wed, Jun 27, 2018 at 1:13 PM, Hans de Goede wrote: > Hi, > > > On 27-06-18 11:47, Bartlomiej Zolnierkiewicz wrote: >> >> On Wednesday, June 27, 2018 11:15:20 AM Daniel Vetter wrote: >>> >>> On Tue, Jun 26, 2018 at 08:36:09PM +0200, Hans de Goede wrote: Hi All, Here is v4 of my patch-set, to delay fbcon taking over the console (and binding to fbdev devices) until there actually is some text output to the console. This is intended for use with the "quiet" cmdline option, in combination with a bootloader which leaves the vendor's logo / EFI bootgraphics put up by the firmware intact on the EFI framebuffer. The end goal here is a boot where the firmware shows its boot graphics and these stay in place for a couple of seconds until the GUI loads and the GUI then smoothly takes over the framebuffer without any distruptions. This patch-set spans 2 subsystems. Petr, the printk subsys change is really trivial (1 line addition) can we get your Acked-by for merging all 3 patches through the fbdev tree? Changelog: Changes in v4: -Keep the comments about which fbcon functions need locks in place Changes in v3: -Export is_console_locke() for use in modules (as fbcon may be built as a .ko) -Use WARN_CONSOLE_UNLOCKED() in several places in the fbcon code to assert proper locking (requested by Daniel) -Unregister the fbcon-dummycon-output-notifier on fbcon_exit() (req. by Daniel) -Document the fbcon=nodefer commandline option (req. by Emil) Changes in v2: -Check the whole string when checking for erases in putcs, instead of just the first char -Make dummycon_blank return 1, so that a redraw gets triggered and any text rendered while blanked gets output so that it can trigger a deferred takeover if one is pending >>> >>> >>> Wrt merging I think it'd be best if we stuff this into drm-misc-next - >>> that will increase testing by gpu drivers a lot, instead of a suprise >>> when >>> the fbdev pull lands in upstream. >>> >>> Bart, is that ok with you? >> >> >> Not really, since there are efifb changes in the queue which depend >> on this series I would really prefer to merge all patches through >> fbdev tree. >> >> Also fbdev tree is pulled into -next kernels so testing coverage >> should be okay (I assume that everybody are testing -next kernels in >> addition to their own branches :-).. Ime this is a rather unrealistic assumption ... > If you are talking about the "efifb: Copy the ACPI BGRT boot graphics to the > framebuffer" series, I could push those to drm-misc-next too (once acked). > > I think most GPU driver developers are running drm-tip and not > -next, so putting things in drm-misc-next would give the changes somewhat > more test-exposure on a wider range of GPUs I believe. Where as -next > testing will likely be more server use-case oriented. > > Alternatively you could merge things in the fbdev tree, do an > unmutable branch and then that could be merged into drm-misc-next by > the drm-misc-next maintainers. > > Note either way is fine with me. This is up to you and Daniel. Yeah pull request for a topic branch works too. -Daniel -- 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: [Intel-gfx] [PATCH 04/10] drm/rockchip/crc: Implement verify_crc_source callback
Hi,
On 6/27/2018 5:30 PM, Jani Nikula wrote:
On Tue, 26 Jun 2018, Mahesh Kumar wrote:
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c9222119767d..ea4884ac4cb0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1138,12 +1138,32 @@ static int vop_crtc_set_crc_source(struct drm_crtc
*crtc,
return ret;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ if ((source_name && strcmp(source_name, "auto") == 0) || !source_name) {
Drive-by review:
IOW,
if (!source_name || strcmp(source_name, "auto") == 0)
Better yet, reverse the logic,
if (source_name && strcmp(source_name, "auto") != 0)
return -EINVAL;
*values_cnt = 3;
return 0;
thanks for review,
Will reverse the logic as suggested.
-Mahesh
BR,
Jani.
+ *values_cnt = 3;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
#else
static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name, size_t *values_cnt)
{
return -ENODEV;
}
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+ size_t *values_cnt)
+{
+ return -ENODEV;
+}
#endif
static const struct drm_crtc_funcs vop_crtc_funcs = {
@@ -1156,6 +1176,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
.set_crc_source = vop_crtc_set_crc_source,
+ .verify_crc_source = vop_crtc_verify_crc_source,
};
static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #12 from Andrey Grodzovsky --- (In reply to dwagner from comment #2) > Just to mention this once again: These system crashes still occur, and way > too frequently to consider the amdgpu driver stable enough for professional > use. Sample dmesg output from today: > > Feb 24 18:26:55 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, > last signaled seq=5430589, last emitted seq=5430591 > Feb 24 18:26:55 [drm] IP block:gmc_v8_0 is hung! > Feb 24 18:26:55 [drm] IP block:gfx_v8_0 is hung! > Feb 24 18:27:02 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 > timeout, last signaled seq=185928, last emitted seq=185930 > Feb 24 18:27:02 [drm] IP block:gmc_v8_0 is hung! > Feb 24 18:27:02 [drm] IP block:gfx_v8_0 is hung! > Feb 24 18:27:05 [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* > [CRTC:43:crtc-0] hw_done or flip_done timed out Can you load the kernel with grub command line amdgpu.vm_update_mode=3 to force CPU VM update mode and see if this helps ? -- 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 199749] amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 --- Comment #24 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to notsyncing from comment #23) > In fact there is no specified graphic work. I just put an Android source > compilation running and go to bed, besides only firefox and dolphin running. > The next morning, I found the machine has already freezed. Still no log. The > log I posted is just a lucky one. > > Would you mind telling me if the umr had some system-wide debugging methods? > Or should I make a netconsole to see if there was anything? UMR is system wide any way, it's memory/registers/HW debugging tool. you can provide the UMR outputs I asked before once the freeze happened assuming you still have SSH access (which seems like you don't). Since the memory faults you experience are clearly due to some graphic rendering activity maybe you could try to isolate the app which triggers it, repeat what you do but close both firefox and dolphin and check if this still happens. If not try to find which of them was causing this and then we can run it with MESA debug flags. -- 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] drm/rockchip: vop: fixup linebuffer mode calc error
Hi Sandy, Am Dienstag, 26. Juni 2018, 10:16:44 CEST schrieb Sandy Huang: > linebuffer mode should be LB_YUV_3840X5 when width is bigger > than 1280 in yuv mode. > seperate yuv and rgb case make the scl_vop_cal_lb_mode() logic > is clearer. > > Signed-off-by: Sandy Huang applied to drm-misc-next Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] drm/rockchip: Use drm_crtc_mask()
Am Dienstag, 26. Juni 2018, 21:47:13 CEST schrieb Ville Syrjala: > From: Ville Syrjälä > > Use drm_crtc_mask() where appropriate. > > Cc: Sandy Huang > Cc: "Heiko Stübner" > Signed-off-by: Ville Syrjälä thanks for that small cleanup, applied to drm-misc-next Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/etnaviv: Check for platform_device_register_simple() failure
Am Mittwoch, den 27.06.2018, 10:07 -0300 schrieb Fabio Estevam:
> > From: Fabio Estevam
>
> platform_device_register_simple() may fail, so we should better
> check its return value and propagate it in the case of error.
>
> > Cc:
> Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT
> node")
> Signed-off-by: Fabio Estevam
Thanks Fabio, both applied to etnaviv/fixes.
Regards,
Lucas
> ---
> Changes since v3:
> - Only set etnaviv_drm when platform_device_register_simple()
> succeeds (Phillip)
>
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index e5013a9..f8d264a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -631,8 +631,11 @@ static struct platform_driver etnaviv_platform_driver = {
> > },
> };
>
> +static struct platform_device *etnaviv_drm;
> +
> static int __init etnaviv_init(void)
> {
> > + struct platform_device *pdev;
> > int ret;
> > struct device_node *np;
>
> @@ -644,7 +647,7 @@ static int __init etnaviv_init(void)
>
> > ret = platform_driver_register(_platform_driver);
> > if (ret != 0)
> > - platform_driver_unregister(_gpu_driver);
> > + goto unregister_gpu_driver;
>
> > /*
> > * If the DT contains at least one available GPU device, instantiate
> @@ -653,12 +656,24 @@ static int __init etnaviv_init(void)
> > for_each_compatible_node(np, NULL, "vivante,gc") {
> > if (!of_device_is_available(np))
> > continue;
> -
> > - platform_device_register_simple("etnaviv", -1, NULL, 0);
> > + pdev = platform_device_register_simple("etnaviv", -1,
> > + NULL, 0);
> > + if (IS_ERR(pdev)) {
> > + ret = PTR_ERR(pdev);
> > + of_node_put(np);
> > + goto unregister_platform_driver;
> > + }
> > + etnaviv_drm = pdev;
> > of_node_put(np);
> > break;
> > }
>
> > + return 0;
> +
> +unregister_platform_driver:
> > + platform_driver_unregister(_platform_driver);
> +unregister_gpu_driver:
> > + platform_driver_unregister(_gpu_driver);
> > return ret;
> }
> module_init(etnaviv_init);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/etnaviv: Check for platform_device_register_simple() failure
On Wed, 2018-06-27 at 10:07 -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> platform_device_register_simple() may fail, so we should better
> check its return value and propagate it in the case of error.
>
> Cc:
> Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT
> node")
> Signed-off-by: Fabio Estevam
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 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/mi0283qt.c | 1 -
drivers/gpu/drm/tinydrm/st7586.c| 1 -
drivers/gpu/drm/tinydrm/st7735r.c | 1 -
5 files changed, 1 insertion(+), 6 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 = _fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.name = "ili9225",
.desc = "Ilitek ILI9225",
.date = "20171106",
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 = _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 = _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 = _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 v3 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,
_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, _helper->client, "fbdev",
_fbdev_client_funcs);
+ if (ret) {
+ kfree(fb_helper);
+ return ret;
+ }
+
+ fb_helper->preferred_bpp = preferred_bpp;
+
+ drm_fbdev_client_hotplug(_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 symbols. At
[PATCH v3 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 5f88c83d173e..27eda18abbf6 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 v3 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(>clientlist_mutex);
+ list_for_each_entry(client, >clientlist, list)
+ drm_printf(, "%s\n", client->name);
+ mutex_unlock(>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 v3 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 | 361 +---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 43 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..9345fb26d45a 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 _framebuffer_funcs.dirty callback is set, fb_deferred_io will be
- * set up automatically. _framebuffer_funcs.dirty is called by
- * drm_fb_helper_deferred_io() in process context ( 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,
- * _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->fbdefio = fbdefio;
-
[PATCH v3 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(>clientlist_mutex);
+ registered = dev->registered;
+ if (registered)
+ list_add(>list, >clientlist);
+ mutex_unlock(>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(>clientlist_mutex);
+ list_for_each_entry_safe(client, tmp, >clientlist, list) {
+ list_del(>list);
+ if (client->funcs && client->funcs->unregister) {
+ client->funcs->unregister(client);
+ } else {
+ drm_client_release(client);
+ kfree(client);
+ }
+ }
+ mutex_unlock(>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(>clientlist_mutex);
+ list_for_each_entry(client, >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(>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(>clientlist_mutex);
+ list_for_each_entry(client, >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(>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 67ac793a7108..00172a3da62c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
[PATCH v3 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(>filelist_mutex);
+ list_add(>lhead, >filelist_internal);
+ mutex_unlock(>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(>filelist_mutex);
+ list_del(>file->lhead);
+ mutex_unlock(>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);
+
+ return 0;
+}
[PATCH v3 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(>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, _copy);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, _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(_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 size
+ *
+ * This
[PATCH v3 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. The only change this time is reworking client removal (again). Drop reference counting, only allow the driver to remove a client. Noralf. 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 | 380 +++--- 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/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 +++ 20 files changed, 1011 insertions(+), 352 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 v3 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 454ff0804642..78854b52676c 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -249,6 +249,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/2] drm/etnaviv: Check for platform_device_register_simple() failure
From: Fabio Estevam
platform_device_register_simple() may fail, so we should better
check its return value and propagate it in the case of error.
Cc:
Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT node")
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Only set etnaviv_drm when platform_device_register_simple()
succeeds (Phillip)
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index e5013a9..f8d264a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -631,8 +631,11 @@ static struct platform_driver etnaviv_platform_driver = {
},
};
+static struct platform_device *etnaviv_drm;
+
static int __init etnaviv_init(void)
{
+ struct platform_device *pdev;
int ret;
struct device_node *np;
@@ -644,7 +647,7 @@ static int __init etnaviv_init(void)
ret = platform_driver_register(_platform_driver);
if (ret != 0)
- platform_driver_unregister(_gpu_driver);
+ goto unregister_gpu_driver;
/*
* If the DT contains at least one available GPU device, instantiate
@@ -653,12 +656,24 @@ static int __init etnaviv_init(void)
for_each_compatible_node(np, NULL, "vivante,gc") {
if (!of_device_is_available(np))
continue;
-
- platform_device_register_simple("etnaviv", -1, NULL, 0);
+ pdev = platform_device_register_simple("etnaviv", -1,
+ NULL, 0);
+ if (IS_ERR(pdev)) {
+ ret = PTR_ERR(pdev);
+ of_node_put(np);
+ goto unregister_platform_driver;
+ }
+ etnaviv_drm = pdev;
of_node_put(np);
break;
}
+ return 0;
+
+unregister_platform_driver:
+ platform_driver_unregister(_platform_driver);
+unregister_gpu_driver:
+ platform_driver_unregister(_gpu_driver);
return ret;
}
module_init(etnaviv_init);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
