Re: [PATCH 2/7] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
On 29.10.2018 12:46, Tomi Valkeinen wrote: > DP1_SRCCTRL register and PHY_2LANE field did not have matching defines. > Add these. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/bridge: tc358767: add bus flags
On 29.10.2018 12:46, Tomi Valkeinen wrote: > tc358767 driver does not set DRM bus_flags, even if it does configures > the polarity settings into its registers. This means that the DPI source > can't configure the polarities correctly. > > Add sync flags accordingly. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/bridge: tc358767: fix single lane configuration
On 29.10.2018 12:46, Tomi Valkeinen wrote: > PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use. > > Set PHY_2LANE only when 2 lanes are used. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/bridge: tc358767: reject modes which require too much BW
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> The current driver accepts any videomode with pclk < 154MHz. This is not
> correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
> supported.
>
> Add code to reject modes that require more bandwidth that is available.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index ab299f4debfa..b026b5ef7378 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1114,10 +1114,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
> *bridge,
> static enum drm_mode_status tc_connector_mode_valid(struct drm_connector
> *connector,
> struct drm_display_mode *mode)
> {
> + struct tc_data *tc = connector_to_tc(connector);
> + u32 req, avail;
> + u32 bits_per_pixel = 24;
> +
> /* DPI interface clock limitation: upto 154 MHz */
> if (mode->clock > 154000)
> return MODE_CLOCK_HIGH;
>
> + req = mode->clock * bits_per_pixel / 8 / 1000;
> + avail = tc->link.base.num_lanes * tc->link.base.rate / 1000;
You can remove "/ 1000" from both lines.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> +
> + if (req > avail)
> + return MODE_BAD;
> +
> return MODE_OK;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/bridge: tc358767: fix output H/V syncs
On 29.10.2018 12:47, Tomi Valkeinen wrote: > The H and V syncs of the DP output are always set to active high. This > patch fixes the syncs by configuring them according to the videomode. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/bridge/tc358767.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index b026b5ef7378..be013bd7b30b 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -726,7 +726,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) > > tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); > > - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); > + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | > + ((mode->flags & DRM_MODE_FLAG_NHSYNC) ? (1 << 15) : 0) | > + ((mode->flags & DRM_MODE_FLAG_NVSYNC) ? (1 << 31) : 0)); Defines for sync flags would be better. Anyway: Reviewed-by: Andrzej Hajda -- Regards Andrzej > > tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | >DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/bridge: tc358767: use DP connector if no panel set
On 29.10.2018 12:47, Tomi Valkeinen wrote: > tc358767 driver sets the connector type always to eDP. > > This patch sets the type to DP if there is no panel defined, which > implies that there's a DP connector on the board. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/bridge/tc358767.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index be013bd7b30b..db93d927cb9a 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -1207,7 +1207,8 @@ static int tc_bridge_attach(struct drm_bridge *bridge) > /* Create eDP connector */ > drm_connector_helper_add(>connector, _connector_helper_funcs); > ret = drm_connector_init(drm, >connector, _connector_funcs, > - DRM_MODE_CONNECTOR_eDP); > + tc->panel ? DRM_MODE_CONNECTOR_eDP : > + DRM_MODE_CONNECTOR_DisplayPort); > if (ret) > return ret; > Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FOSDEM 2019: Graphics DevRoom: Call for speakers.
On Mon, Nov 19, 2018 at 08:17:32AM +0100, Luc Verhaegen wrote: > Hi, > > At FOSDEM on saturday the 3rd of february 2018, there will be another > graphics DevRoom. URL: https://fosdem.org/2018/ That should of course read: At FOSDEM on saturday the 2nd of february 2019, there will be another graphics DevRoom. URL: https://fosdem.org/2019/ Eejit Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> Initially DP0_SRCCTRL is set to a static value which includes
> DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
> 1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
>
> This patch changes the configuration as follows:
>
> Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
> value.
>
> DP1_SRCCTRL needs to bits to be set to the same value as DP0_SRCCTRL:
s/to/two/
> SSCG and BW27. All other bits can be zero.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index fee53422c31f..ab299f4debfa 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -836,12 +836,11 @@ static int tc_main_link_setup(struct tc_data *tc)
> if (!tc->mode)
> return -EINVAL;
>
> - /* from excel file - DP0_SrcCtrl */
> - tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
> - DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
> - DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
> - /* from excel file - DP1_SrcCtrl */
> - tc_write(DP1_SRCCTRL, 0x3083);
> + tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
> + /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
> + tc_write(DP1_SRCCTRL,
> + (tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
> + ((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
Wouldn't be better then to modify tc_srcctrl to support DP0 and DP1:
tc_write(DP0_SRCCTRL, tc_srcctrl(tc, 0));
tc_write(DP1_SRCCTRL, tc_srcctrl(tc, 1));
Just suggestion.
With or without this change:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
Regards
Andrzej
>
> rate = clk_get_rate(tc->refclk);
> switch (rate) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM 2019: Graphics DevRoom: Call for speakers.
Hi, At FOSDEM on saturday the 3rd of february 2018, there will be another graphics DevRoom. URL: https://fosdem.org/2018/ The focus of this DevRoom is of course the same as the previous editions, namely: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management, low level toolkit stuff, and other areas which i might have overlooked above are accepted. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. We have the devroom from 10:30 til 19:00, giving us 8h30, so eight 50 minute talkes and one 20 minute talk are available. Talk Submission: Like the last few years, the pentabarf system will be used for talk submission. https://penta.fosdem.org/submission/FOSDEM19 Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with a sliding schedule which only gets filled out on the last day. Upwards of 1 people are visiting this event, and most of them get a printed booklet or use the schedule on the FOSDEM website or an app for their phone to figure out what to watch or participate in next. So please put some effort in your talk submission and details. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, if you are unsure on whether you can come or not (this is FOSDEM, why are you not there anyway?), please wait with submitting your talk until you do. When in pentabarf, please give the abstract and description, for both the event and the speaker, some thought. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY after a few days. As for deadlines, the fosdem organizers want to have a finished schedule by the 14th of december. Don't count on this deadline: first come first serve! The worst slots will be assigned to those who come last, which could be pretty dire given that there is the traditional FOSDEM beer event the night before ;) Please try to re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password If there are any issues, just poke me here or on IRC. Necessary information: -- Below is a list of what i need to see filled in in pentabarf when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots (which are on saturday afternoon) are for the earliest submissions. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. Remember, i will only schedule your talk after the basics are somewhat filled in (you still can change them until december 14th). I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email. That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105982] Plugging HDMI cable hits [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout
https://bugs.freedesktop.org/show_bug.cgi?id=105982 jian-h...@endlessm.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from jian-h...@endlessm.com --- I am not sure. But I have tried 4.18 kernel and cannot reproduce this issue again. By the way, it is Xorg in use. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panel: Set max rate for Innolux p079x panels
On 18.11.2018 22:36, Linus Walleij wrote: > After adding the hs_rate and lp_rate fields to the DSI device > we need to populate these accordingly so display drivers can > respect them. > > Cc: Andrzej Hajda > Cc: Chris Zhong > Cc: Lin Huang > Cc: Heiko Stuebner > Tested-by: Heiko Stuebner > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Collect Heiko's Test tag > --- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c > b/drivers/gpu/drm/panel/panel-innolux-p079zca.c > index ca4ae45dd307..2013cd3c58ba 100644 > --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c > +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c > @@ -518,6 +518,9 @@ static int innolux_panel_probe(struct mipi_dsi_device > *dsi) > dsi->mode_flags = desc->flags; > dsi->format = desc->format; > dsi->lanes = desc->lanes; > + /* This is presumably the HS rate */ > + dsi->hs_rate = desc->mode->clock * 1000; > + /* FIXME: LP rate not specified */ Hmm specs says explicitly 10MHz [1], table 3.6.1.2, symbol FDSICLK_LP. [1]: http://sqkj.splcd.com/Img/Spec/P079ZCZ-3Z2(V06)2015-06-10.pdf -- Regards Andrzej > > err = innolux_panel_add(dsi, desc); > if (err < 0) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panel: Set max rate for Ilitek ILI9881C
On 18.11.2018 22:31, Linus Walleij wrote: > After adding the hs_rate and lp_rate fields to the DSI device > we need to populate these accordingly so display drivers can > respect them. > > This figure for HS rate comes from the ILI9881C manual, the > calculation is explained in the comment. > > Cc: Daniel Vetter > Cc: Andrzej Hajda > Acked-by: Maxime Ripard > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Add LP speed after Andrzej's observation. > - Collect Maxime's ACK (hope it's fine also with the LP speed) > --- > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c > b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c > index 3ad4a46c4e94..bd276c666318 100644 > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c > @@ -465,6 +465,19 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device > *dsi) > dsi->mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE; > dsi->format = MIPI_DSI_FMT_RGB888; > dsi->lanes = 4; > + /* > + * The datasheet (table 39) specifies "limited clock channel speed" > + * for 4 lanes as 550 Mbps for RGB888. As this is 4 bits at the time, > + * the maximum HS frequency is 550/4 = 137.5 MHz. > + */ > + dsi->hs_rate = 13750; > + /* > + * Table 42 says: "Length of LP-00, LP-01, LP-10 or LP-11 periods": > + * min 50ns, max 75ns. 1/50ns = max LPM rate = 20.000.000Hz. > + * Since LP transmissions are to periods per bit, this should be s/to/two/ Reviewed-by: Andrzej Hajda -- Regards Andrzej > + * 10 MHz. > + */ > + dsi->lp_rate = 1000; > > return mipi_dsi_attach(dsi); > } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/12] drm/mediatek: Add support for mmsys through a pdev
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the same
> device tree compatible.
Looks good to me except one coding style preference.
Reviewed-by: CK Hu
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 99dd612a6683..18fc761ba94f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -199,6 +199,7 @@ static const struct mtk_mmsys_driver_data
> mt2701_mmsys_driver_data = {
> .ext_path = mt2701_mtk_ddp_ext,
> .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
> .shadow_register = true,
> + .clk_drv_name = "clk-mt2701-mm",
> };
>
> static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> @@ -215,6 +216,7 @@ static const struct mtk_mmsys_driver_data
> mt8173_mmsys_driver_data = {
> .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> .ext_path = mt8173_mtk_ddp_ext,
> .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> + .clk_drv_name = "clk-mt8173-mm",
> };
>
> static int mtk_drm_kms_init(struct drm_device *drm)
> @@ -473,6 +475,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
> if (IS_ERR(private->config_regs))
> return PTR_ERR(private->config_regs);
>
> + /*
> + * For legacy reasons we need to probe the clock driver via
> + * a platfomr device. This is outdated and should not be used
> + * in newer SoCs.
> + */
> + if (private->data->clk_drv_name) {
> + private->clk_dev = platform_device_register_data(dev,
> + private->data->clk_drv_name, -1,
> + NULL, 0);
> +
> + if (IS_ERR(private->clk_dev)) {
> + pr_err("failed to register %s platform device\n",
> + private->data->clk_drv_name);
I would like to align to the right of '('.
Regards,
CK
> +
> + return PTR_ERR(private->clk_dev);
> + }
> + }
> +
> /* Iterate over sibling DISP function blocks */
> for_each_child_of_node(dev->of_node->parent, node) {
> const struct of_device_id *of_id;
> @@ -577,6 +597,9 @@ static int mtk_drm_remove(struct platform_device *pdev)
> for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
> of_node_put(private->comp_node[i]);
>
> + if (private->clk_dev)
> + platform_device_unregister(private->clk_dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index ab0adbd7d4ee..515ac4cae922 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -37,11 +37,13 @@ struct mtk_mmsys_driver_data {
> unsigned int third_len;
>
> bool shadow_register;
> + const char *clk_drv_name;
> };
>
> struct mtk_drm_private {
> struct drm_device *drm;
> struct device *dma_dev;
> + struct platform_device *clk_dev;
>
> unsigned int num_pipes;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the clocks. Omit this error on
> the defered probe path.
This patch looks good to me, but you have not modified the sub driver in
HDMI path. We could let HDMI path print the warning and someone send
another patch later, or you modify for HDMI path in this patch.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 +++-
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 +++-
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 +++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
> drivers/gpu/drm/mediatek/mtk_dsi.c| 6 --
> 5 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index f609b62b8be6..1ea3178d4c18 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -126,7 +126,9 @@ static int mtk_disp_color_probe(struct platform_device
> *pdev)
> ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
> _disp_color_funcs);
> if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);
I would like one more blank line here.
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 28d191192945..5ebbcaa4e70e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -293,7 +293,9 @@ static int mtk_disp_ovl_probe(struct platform_device
> *pdev)
> ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
> _disp_ovl_funcs);
> if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);
I would like to align to the right of '('.
Regards,
CK
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cffe345a..59a08ed5fea5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -295,7 +295,9 @@ static int mtk_disp_rdma_probe(struct platform_device
> *pdev)
> ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
> _disp_rdma_funcs);
> if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index b06cd9d4b525..b76a2d071a97 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -566,7 +566,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>
> ddp->clk = devm_clk_get(dev, NULL);
> if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> + if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get clock\n");
> return PTR_ERR(ddp->clk);
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 90109a0d6fff..cc6de75636c3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1103,14 +1103,16 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> dsi->engine_clk = devm_clk_get(dev, "engine");
> if (IS_ERR(dsi->engine_clk)) {
> ret = PTR_ERR(dsi->engine_clk);
> - dev_err(dev, "Failed to get engine clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get engine clock: %d\n", ret);
> return ret;
> }
>
> dsi->digital_clk = devm_clk_get(dev, "digital");
> if (IS_ERR(dsi->digital_clk)) {
> ret = PTR_ERR(dsi->digital_clk);
> - dev_err(dev, "Failed to get digital clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get digital clock: %d\n", ret);
> return ret;
> }
>
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #46 from Kent Ross --- Created attachment 142511 --> https://bugs.freedesktop.org/attachment.cgi?id=142511=edit dmesg logs for failure Other items of potential relevance: I have two screens, one at 3840x2160 and one at 2560x1600. When I've experienced this failure (I haven't tried a wide variety of applications) it it is with games that do not have exclusive control of the screen, running in the desktop compositor. The second screen also freezes, but other applications that are running on the other screen -- such as a Chrome window playing streaming video -- will have their audio continue uninterrupted. -- 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 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #45 from Kent Ross --- This happens to me as well. I first noticed it occurring when I had a double-GPU setup, but since then I have completely reinstalled with only the AMD gpu (a Vega 64) and it still happens. The failures are similar to those bernhardu notes. I have not had a failure simply using Chrome and desktop applications yet, but it is typically reproducible between 5 and 60 minutes in a 3D game like Dota 2. I suspected it might be related to memory stability, but the machine it happens on happily passes both memtest and mprime. The lockup still occurs even when the memory is underclocked by 25% (retaining the same timings and voltage, so that's a full 25% overhead for every command). I have: - Intel 7980XE cpu - Ubuntu Cosmic, linux-image-4.18.0-11-generic - default amdgpu drivers I have also tried updated amdgpu packages from ppa:oibaf/graphics-drivers; the failure is the same. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #45 from rro...@gmail.com --- (In reply to bmilreu from comment #43) > If devs want an easy test case, use these links for reproducing it in > chromium: > > https://www.vsynctester.com/ > https://www.testufo.com/photo > https://www.slither.io > > move the cursor around, move/resize some windows. you will notice it > > the vsync/cursor stutters and frame-skips are pretty noticeable with dc=1 on > all three links > > KWin, compton, TearFree, mutter, xfwm4 all have the same problems. I just tried dc=1 and I only seem to have a problem if I use TearFree. Things are totally fine without TearFree. To be clear about what I'm doing here right now: I made sure DC is enabled: $ systool -vm amdgpu | grep dc dc = "1" $ dmesg | grep -i display [1.014297] [drm] Display Core initialized with v3.1.59! I removed TearFree from my X config: $ cat /etc/X11/xorg.conf.d/20-amdgpu.conf Section "OutputClass" Identifier "my amdgpu settings" MatchDriver "amdgpu" Option "DRI" "3" EndSection And I started Compton like this to make sure it's a clean config: $ compton --config /dev/null --backend glx --vsync opengl With this setup, I don't seem to have any stutter. I visited the websites you mention in a Chromium window, then opened another window and tried moving things around and resizing. It behaves fine, same as what I know from normally using dc=0. Kernel is 4.19.2, Mesa 18.2.4, Xorg 1.20.3, the GPU is a RX480, monitor is 60 Hz. After I had typed this, I have now added TearFree to the X config and restarted X: $ cat /etc/X11/xorg.conf.d/20-amdgpu.conf Section "OutputClass" Identifier "my amdgpu settings" MatchDriver "amdgpu" Option "TearFree" "true" Option "DRI" "3" EndSection Now, with TearFree enabled, things are super terrible. Trying to move a window around has extreme stutter, it seems to drop frames. If I restart Compton with "GALLIUM_HUD=fps" and then try moving a window around in circles, I can see it stays below 40 fps instead of hitting the 60 fps that it should be running at. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #44 from Brandon Wright --- You're too late, I already tried it. But as you say, there's no improvement. -- 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: [PULL] drm-intel-next for v4.21/v5.1
On Fri, 2 Nov 2018 at 20:21, Jani Nikula wrote: > > > Hi Dave - > > I just tagged this minutes ago, but I'm sending this now because I'll be > out for about a week. I don't expect you to pull this until some time > after -rc1 anyway. I'm asking Joonas and Rodrigo to tell you if this > one's a go or a no go. > > There's a couple of backmerges in there, and I'd probably like to do > another one once you've backmerged from Linus. > > I suck at making myself write proper changelogs. It's a random unordered > jumble, I'm afraid. One of these days I'll learn to do it > right. Promise! So I haven't pulled this for a couple of reasons, mostly my fault, but it would be nice if you could regenerate it with more of drm-intel-next-queued pull in. To explain further: a) I rebased drm-next to v4.20-rc3 because I was away last week and had failed to merge anything. b) I pulled drm-misc-next + amdgpu (nothing major here). c) I pulled this and got a conflict that nobody else has resolved in intel_sprite.c and realised it was a pain to resolve with this merge. intel_sprite.c got a fix in drm-fixes 27971d613fcb5b6ad96320bc4f2c90f4d4fde768drm/i915: Clean up skl_program_scaler() This isn't in this pull request, it's only in drm-intel-next-queued, so I have to create a new merge state that has never occured anywhere else, and if I just wait for the next i915 pull has no need to exist here, the merge looked minorly complicated and it seems likely I'd probably get it wrong, when waiting will just make it all happen. So please send me an updated pull and sorry for the delay that caused the noise. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #43 from bmil...@gmail.com --- (In reply to Brandon Wright from comment #42) > This is pretty serious. Just moving the mouse cursor around while something > slightly GPU-heavy is running at 60hz can produce frame-skipping. > > I switched the display core off with amdgpu.dc=0 and everything got > significantly smoother and chromium doesn't chug on heavy pages any more. > > I'm using 4.19.x. I haven't tried the drm-next-4.21-wip tree yet. Dont need to try drm-next-4.21-wip, just did and it still has the issue If devs want an easy test case, use these links for reproducing it in chromium: https://www.vsynctester.com/ https://www.testufo.com/photo https://www.slither.io move the cursor around, move/resize some windows. you will notice it the vsync/cursor stutters and frame-skips are pretty noticeable with dc=1 on all three links KWin, compton, TearFree, mutter, xfwm4 all have the same problems. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #42 from Brandon Wright --- This is pretty serious. Just moving the mouse cursor around while something slightly GPU-heavy is running at 60hz can produce frame-skipping. I switched the display core off with amdgpu.dc=0 and everything got significantly smoother and chromium doesn't chug on heavy pages any more. I'm using 4.19.x. I haven't tried the drm-next-4.21-wip tree yet. -- 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 108709] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
https://bugs.freedesktop.org/show_bug.cgi?id=108709 --- Comment #5 from mikhail.v.gavri...@gmail.com --- Chris, I am appreciate your work. Hope to see this patch as soon as possible in mainline. -- 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 108709] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
https://bugs.freedesktop.org/show_bug.cgi?id=108709 --- Comment #3 from mikhail.v.gavri...@gmail.com --- Created attachment 142508 --> https://bugs.freedesktop.org/attachment.cgi?id=142508=edit dmesg 4.20.0-0.rc2.git2.1 before Chris patch -- 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 108709] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
https://bugs.freedesktop.org/show_bug.cgi?id=108709 --- Comment #4 from mikhail.v.gavri...@gmail.com --- Created attachment 142509 --> https://bugs.freedesktop.org/attachment.cgi?id=142509=edit dmesg 4.20.0-0.rc2.git2.1 after Chris patch -- 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 108709] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
https://bugs.freedesktop.org/show_bug.cgi?id=108709 --- Comment #2 from mikhail.v.gavri...@gmail.com --- Yes, your patch fix this issue, thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #46 from tempel.jul...@gmail.com --- As a workaround, a timer job/script writing every few seconds might do the trick. -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #45 from bmil...@gmail.com --- A temporary way to at least lock mclck forever would be great until this is fixed. There is no sane way to do it permanently (some events switch it back to auto, IE resolution changes and sleep/wake) -- 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] drm/panel: Add a driver for the TPO TPG110
On Sun, Nov 18, 2018 at 08:30:39PM +0100, Linus Walleij wrote: > The TPO (Toppoly) TPG110 is a pretty generic display driver > similar in vein to the Ilitek 93xx devices. It is not a panel > per se but a driver used with several low-cost noname panels. > > This is used on the Nomadik NHK15 combined with a OSD > OSD057VA01CT display for WVGA 800x480. > > The driver is pretty minimalistic right now but can be > extended to handle non-default polarities, gamma correction > etc. > > The driver is based on the baked-in code in > drivers/video/fbdev/amba-clcd-nomadik.c which will be > decomissioned once this us upstream. > > Cc: Sam Ravnborg > Signed-off-by: Linus Walleij Acked-by: Sam Ravnborg Thanks for addressing my nits. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108493] Unigine Heaven at 4K crashes amdgpu and causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=108493 --- Comment #16 from Timur Kristóf --- Hi, After some more experimentation it seems that increasing the highest mclk voltage above 900 mV and setting all other voltages in pp_od_clk_voltage in such a way that they remain below 1000 mV, is a viable workaround that makes the GPU stable. Here is what I do to achieve this: echo "2" > /sys/class/drm/card0/device/pp_sclk_od echo "2" > /sys/class/drm/card0/device/pp_mclk_od echo "s 0 300 750" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 1 588 765" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 2 952 900" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 3 1041 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 4 1106 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 5 1168 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 6 1209 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "s 7 1244 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "m 0 300 750" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "m 1 1000 850" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "m 2 1750 970" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage After running this script, I can play on the GPU for several hours and I don't see the hang happening anymore. -- 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 v2] drm/panel: Set max rate for Innolux p079x panels
After adding the hs_rate and lp_rate fields to the DSI device we need to populate these accordingly so display drivers can respect them. Cc: Andrzej Hajda Cc: Chris Zhong Cc: Lin Huang Cc: Heiko Stuebner Tested-by: Heiko Stuebner Signed-off-by: Linus Walleij --- ChangeLog v1->v2: - Collect Heiko's Test tag --- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c b/drivers/gpu/drm/panel/panel-innolux-p079zca.c index ca4ae45dd307..2013cd3c58ba 100644 --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c @@ -518,6 +518,9 @@ static int innolux_panel_probe(struct mipi_dsi_device *dsi) dsi->mode_flags = desc->flags; dsi->format = desc->format; dsi->lanes = desc->lanes; + /* This is presumably the HS rate */ + dsi->hs_rate = desc->mode->clock * 1000; + /* FIXME: LP rate not specified */ err = innolux_panel_add(dsi, desc); if (err < 0) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Set max rate for Innolux p079x panels
On Wed, Nov 14, 2018 at 3:31 PM Heiko Stübner wrote: > Am Mittwoch, 14. November 2018, 12:42:54 CET schrieb Linus Walleij: > > After adding the hs_rate and lp_rate fields to the DSI device > > we need to populate these accordingly so display drivers can > > respect them. > > > > Cc: Andrzej Hajda > > Cc: Chris Zhong > > Cc: Lin Huang > > Cc: Heiko Stuebner > > Signed-off-by: Linus Walleij > > While my understanding of DSI is marginal, the display on my > scarlet (p097pfg variant in the driver) still comes up, so > > Tested-by: Heiko Stuebner It's mainly that we want displays to report their speed capabilities. It is up to the display drivers to make use of it to throttle the lanes, I think they all use some safe default as of now. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panel: Set max rate for Ilitek ILI9881C
After adding the hs_rate and lp_rate fields to the DSI device we need to populate these accordingly so display drivers can respect them. This figure for HS rate comes from the ILI9881C manual, the calculation is explained in the comment. Cc: Daniel Vetter Cc: Andrzej Hajda Acked-by: Maxime Ripard Signed-off-by: Linus Walleij --- ChangeLog v1->v2: - Add LP speed after Andrzej's observation. - Collect Maxime's ACK (hope it's fine also with the LP speed) --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c index 3ad4a46c4e94..bd276c666318 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c @@ -465,6 +465,19 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi) dsi->mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE; dsi->format = MIPI_DSI_FMT_RGB888; dsi->lanes = 4; + /* +* The datasheet (table 39) specifies "limited clock channel speed" +* for 4 lanes as 550 Mbps for RGB888. As this is 4 bits at the time, +* the maximum HS frequency is 550/4 = 137.5 MHz. +*/ + dsi->hs_rate = 13750; + /* +* Table 42 says: "Length of LP-00, LP-01, LP-10 or LP-11 periods": +* min 50ns, max 75ns. 1/50ns = max LPM rate = 20.000.000Hz. +* Since LP transmissions are to periods per bit, this should be +* 10 MHz. +*/ + dsi->lp_rate = 1000; return mipi_dsi_attach(dsi); } -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm/panel: Add a driver for the TPO TPG110
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is pretty minimalistic right now but can be
extended to handle non-default polarities, gamma correction
etc.
The driver is based on the baked-in code in
drivers/video/fbdev/amba-clcd-nomadik.c which will be
decomissioned once this us upstream.
Cc: Sam Ravnborg
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Assign proper bus_flags.
- This is now the only remaining patch.
ChangeLog v3->v4:
- Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
ChangeLog v2->v3:
- Rewrite as an SPI child device.
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 511 +++
4 files changed, 529 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f4855974f325..6905d002cf17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4751,6 +4751,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
+DRM DRIVER FOR TPO TPG110 PANELS
+M: Linus Walleij
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
+F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+
DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
M: Dave Airlie
R: Sean Paul
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30a33b3..b2c8b02894b1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,14 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TPO_TPG110
+ tristate "TPO TPG 800x400 panel"
+ depends on OF && SPI && GPIOLIB
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for TPO TPG110
+ 400CH LTPS TFT LCD Single Chip Digital Driver for up to
+ 800x400 LCD panels.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9d13af..9b3a0629d255 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
new file mode 100644
index ..99bf4b274ef1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
+ * Digital Driver.
+ *
+ * This chip drives a TFT LCD, so it does not know what kind of
+ * display is actually connected to it, so the width and height of that
+ * display needs to be supplied from the machine configuration.
+ *
+ * Author:
+ * Linus Walleij
+ */
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define TPG110_TEST0x00
+#define TPG110_CHIPID 0x01
+#define TPG110_CTRL1 0x02
+#define TPG110_RES_MASKGENMASK(2, 0)
+#define TPG110_RES_800X480 0x07
+#define TPG110_RES_640X480 0x06
+#define TPG110_RES_480X272 0x05
+#define TPG110_RES_480X640 0x04
+#define TPG110_RES_480X272_D 0x01 /* Dual scan: outputs 800x480 */
+#define TPG110_RES_400X240_D 0x00 /* Dual scan: outputs 800x480 */
+#define TPG110_CTRL2 0x03
+#define TPG110_CTRL2_PMBIT(0)
+#define TPG110_CTRL2_RES_PM_CTRL BIT(7)
+
+/**
+ * struct tpg110_panel_mode - lookup struct for the supported modes
+ */
+struct tpg110_panel_mode {
+ /**
+* @name: the name of this panel
+*/
+ const char *name;
+ /**
+* @magic: the magic value from the detection register
+*/
+ u32 magic;
+ /**
+* @mode: the DRM display mode for this panel
+*/
+ struct drm_display_mode mode;
+ /**
+* @bus_flags: the DRM bus flags for this panel e.g. inverted clock
+*/
+ u32 bus_flags;
+};
+
+/**
+ * struct tpg110 - state container for the
[Bug 105113] [hawaii, radeonsi, clover] Running Piglit cl/program/execute/{, tail-}calls{, -struct, -workitem-id}.cl cause GPU VM error and ring stalled GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=105113 --- Comment #7 from Jan Vesely --- (In reply to Maciej S. Szmigiero from comment #6) > There are really two issues at play here: > 1) If the LLVM-generated code cannot be run properly then it should be simply > rejected by whatever is actually in charge of submitting it to the GPU (I > guess > this would be Mesa?). > This way an application will know it cannot use OpenCL for computation, at > least > not with this compute kernel. > > Instead, it currently looks like many of these test run but give incorrect > results, which is obviously rather bad. Do you have an example of this? clover should return OUT_OF_RESOURCES error when the compute state creation fails (like in the presence of code relocations). It does not change the content of the buffer, so it will return whatever was stored in the buffer on creation. > 2) Some (previous) Mesa + LLVM versions generate a command stream that > crashes the GPU and, as far as I can remember, sometimes even lockup the > whole machine. > > It should not be possible to crash the GPU, regardless how incorrect a > command stream that userspace sends to it is - because otherwise it is > possible for > an unprivileged user with GPU access to DoS the machine. This is a separate issue. GPU hangs are generally addressed via gpu reset which should be enabled for gfx8/9 GPUs in recent amdgpu.ko [0] [0] https://patchwork.freedesktop.org/patch/257994/ -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #44 from tempel.jul...@gmail.com --- I have this issue also without amdgpu.ppfeaturemask=0x. amdgpu.dc 0 or 1 doesn't make a difference for me. -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #43 from afm --- OK really sorry for the noise on this ticket. It seems I did this to myself with featuremask 0xfff . All is working without it. (i had been using watman gtk) -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #42 from afm --- Just to add. I noticed the corruption during the plymouth boot screen too. After just waking the monitors from DPMS i got corruption until I echo'd 0 again. -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #41 from afm --- RX 570 1002:67df [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) Kernel: 4.19.2-300.fc29.x86_64 1920x1080 59.93*+ Lots of strange flickering and black lines with dc=1. Strange ghosting and screen corruption with dc=0 echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk Fixes the issue. echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk Produces screen corruption for half a second on each change. Across all 3 monitors. -- 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 108778] [R9 390] amdgpu: Fatal error during GPU init 4.20-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=108778 --- Comment #2 from erhar...@mailbox.org --- Created attachment 142507 --> https://bugs.freedesktop.org/attachment.cgi?id=142507=edit dmesg (4.18.19, 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 108778] [R9 390] amdgpu: Fatal error during GPU init 4.20-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=108778 --- Comment #1 from erhar...@mailbox.org --- Created attachment 142506 --> https://bugs.freedesktop.org/attachment.cgi?id=142506=edit dmesg (4.19.2, non-working) Same here on kernel 4.19.2 with a R9 390. The other 2 cards in my system (R9 Nano) are working fine. inxi -G Graphics: Card-1: Advanced Micro Devices [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] Card-2: Advanced Micro Devices [AMD/ATI] Hawaii PRO [Radeon R9 290/390] Card-3: Advanced Micro Devices [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] Display Server: X.Org 1.20.0 drivers: ati,amdgpu (unloaded: modesetting,radeon) Resolution: 1280x800@60.00hz OpenGL: renderer: llvmpipe (LLVM 6.0, 128 bits) version: 3.3 Mesa 18.2.4 This is a regression, as the R9 390 works fine on kernel 4.18.19. -- 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 108037] Turning monitors off and on again makes the kernel panic and system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=108037 --- Comment #10 from Öyvind Saether --- I turned off freesync on one monitor and have been using Section "Extensions" Option "DPMS" "Disable" EndSection in /etc/X11/xorg.conf.d/20-amdgpu.conf which appears to prevent this from happening. Tried commenting "DPMS" "Disable" on kernel 4.19.2-ChaeKyung to see what would happen. The box froze when I turned monitors off for some time and turned them back on again. This is clearly still a bug in 4.19.2 which is unfortunate since that kernel is a LTS kernel. -- 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 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
On 11/12, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> 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 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -412,10 +412,7 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
> }
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index
Re: Question about implicit fence sync in display DRM drivers
add ".prepare_fb = drm_gem_fb_prepare_fb," in "drm_plane_helper_funcs" solve my flicker problem on Allwinner A64. Thanks, Qiang On Sun, Nov 18, 2018 at 8:14 PM Qiang Yu wrote: > > I find the reservation object will be created when: dma_buf_export > if no reservation object created when buffer object creation. > > And the implicit fence can be synced before display in: drm_gem_fb_prepare_fb > but seems most display driver doesn't call this function. > > Regards, > Qiang > On Sun, Nov 18, 2018 at 10:43 AM Qiang Yu wrote: > > > > Hi Eric and Wladimir, > > > > GPU driver like VC4, Etnaviv and Lima only do rendering and left display > > to other DRM display drivers. So there should be a render/display sync > > problem for these drivers. > > > > As I know, there are two ways: implicit and explicit described here: > > https://www.collabora.com/news-and-blog/blog/2016/09/13/mainline-explicit-fencing-part-1/ > > > > The implicit way need the display DRM driver wait on the reservation object > > associated with that framebuffer before display it, the reservation > > object contains > > fence which is added by render DRM driver to indicate render finish: > > https://www.phoronix.com/scan.php?page=news_item=AMDGPU-Intel-4.9-PRIME-Ex-Patch > > > > I investigate a bit into these DRM display drivers using CMA GEM helpers, > > seems there's no reservation object at all, so it should be impossible to > > support implicit sync. > > > > Although explicit way is better, there are still some apps not support it > > like > > kodi-gbm. So how do VC4+PL111 and Etnaviv+IMX solve this sync problem, > > and do these drivers support implicit sync? > > > > Thanks, > > Qiang ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Question about implicit fence sync in display DRM drivers
I find the reservation object will be created when: dma_buf_export if no reservation object created when buffer object creation. And the implicit fence can be synced before display in: drm_gem_fb_prepare_fb but seems most display driver doesn't call this function. Regards, Qiang On Sun, Nov 18, 2018 at 10:43 AM Qiang Yu wrote: > > Hi Eric and Wladimir, > > GPU driver like VC4, Etnaviv and Lima only do rendering and left display > to other DRM display drivers. So there should be a render/display sync > problem for these drivers. > > As I know, there are two ways: implicit and explicit described here: > https://www.collabora.com/news-and-blog/blog/2016/09/13/mainline-explicit-fencing-part-1/ > > The implicit way need the display DRM driver wait on the reservation object > associated with that framebuffer before display it, the reservation > object contains > fence which is added by render DRM driver to indicate render finish: > https://www.phoronix.com/scan.php?page=news_item=AMDGPU-Intel-4.9-PRIME-Ex-Patch > > I investigate a bit into these DRM display drivers using CMA GEM helpers, > seems there's no reservation object at all, so it should be impossible to > support implicit sync. > > Although explicit way is better, there are still some apps not support it like > kodi-gbm. So how do VC4+PL111 and Etnaviv+IMX solve this sync problem, > and do these drivers support implicit sync? > > Thanks, > Qiang ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm: remove no longer needed drm-get-put coccinelle script
On Thu, 15 Nov 2018, Fernando Ramos wrote: > The coccinelle script was used to rename some (deprecated) functions > which no longer exist now. > > Signed-off-by: Fernando Ramos Acked-by: Julia Lawall > --- > scripts/coccinelle/api/drm-get-put.cocci | 78 > 1 file changed, 78 deletions(-) > delete mode 100644 scripts/coccinelle/api/drm-get-put.cocci > > diff --git a/scripts/coccinelle/api/drm-get-put.cocci > b/scripts/coccinelle/api/drm-get-put.cocci > deleted file mode 100644 > index 3a09c97ad87d.. > --- a/scripts/coccinelle/api/drm-get-put.cocci > +++ /dev/null > @@ -1,78 +0,0 @@ > -// SPDX-License-Identifier: GPL-2.0 > -/// > -/// Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and > -/// drm_*_unreference() helpers. > -/// > -// Confidence: High > -// Copyright: (C) 2017 NVIDIA Corporation > -// Options: --no-includes --include-headers > -// > - > -virtual patch > -virtual report > - > -@depends on patch@ > -expression object; > -@@ > - > -( > -- drm_connector_reference(object) > -+ drm_connector_get(object) > -| > -- drm_connector_unreference(object) > -+ drm_connector_put(object) > -| > -- drm_framebuffer_reference(object) > -+ drm_framebuffer_get(object) > -| > -- drm_framebuffer_unreference(object) > -+ drm_framebuffer_put(object) > -| > -- drm_gem_object_reference(object) > -+ drm_gem_object_get(object) > -| > -- drm_gem_object_unreference(object) > -+ drm_gem_object_put(object) > -| > -- __drm_gem_object_unreference(object) > -+ __drm_gem_object_put(object) > -| > -- drm_gem_object_unreference_unlocked(object) > -+ drm_gem_object_put_unlocked(object) > -| > -- drm_dev_unref(object) > -+ drm_dev_put(object) > -) > - > -@r depends on report@ > -expression object; > -position p; > -@@ > - > -( > -drm_connector_unreference@p(object) > -| > -drm_connector_reference@p(object) > -| > -drm_framebuffer_unreference@p(object) > -| > -drm_framebuffer_reference@p(object) > -| > -drm_gem_object_unreference@p(object) > -| > -drm_gem_object_reference@p(object) > -| > -__drm_gem_object_unreference(object) > -| > -drm_gem_object_unreference_unlocked(object) > -| > -drm_dev_unref@p(object) > -) > - > -@script:python depends on report@ > -object << r.object; > -p << r.p; > -@@ > - > -msg="WARNING: use get/put helpers to reference and dereference %s" % (object) > -coccilib.report.print_report(p[0], msg) > -- > 2.19.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: change i915_sw_fence license to MIT
On Wed, Oct 31, 2018 at 08:43:03AM +, Chris Wilson wrote: > Quoting Jonathan Gray (2018-10-31 00:56:12) > > Chris Wilson said Intel is willing to change the license of these files > > to MIT. > > > > Signed-off-by: Jonathan Gray > Reviewed-by: Chris Wilson > -Chris Still looking to get this merged/reviewed by one of the i915 maintainers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
