Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote: > this series tries to actually turn vm_fault_t into a type that can be > typechecked and checks the fallout instead of sprinkling random > annotations without context. Yes, why should we have small tasks that newcomers can do when the mighty Christoph Hellwig can swoop in and take over from them? Seriously, can't your talents find a better use than this? > The first one fixes a real bug in orangefs, the second and third fix > mismatched existing vm_fault_t annotations on the same function, the > fourth removes an unused export that was in the chain. The remainder > until the last one do some not quite trivial conversions, and the last > one does the trivial mass annotation and flips vm_fault_t to a __bitwise > unsigned int - the unsigned means we also get plain compiler type > checking for the new ->fault signature even without sparse. Yes, that was (part of) the eventual goal. Well done. Would you like a biscuit? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/26] drm/bridge: cdns-dsi: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c index c255fc3e1be5..e9be5c3f0284 100644 --- a/drivers/gpu/drm/bridge/cdns-dsi.c +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -1548,8 +1548,8 @@ static int cdns_dsi_drm_probe(struct platform_device *pdev) * CDNS_DPI_INPUT. */ input->id = CDNS_DPI_INPUT; + input->bridge.odev = &pdev->dev; input->bridge.funcs = &cdns_dsi_bridge_funcs; - input->bridge.of_node = pdev->dev.of_node; /* Mask all interrupts before registering the IRQ handler. */ writel(0, dsi->regs + MCTL_MAIN_STS_CTL); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support
On Wed, May 16, 2018 at 10:59 AM, Sergei Shtylyov
wrote:
> Hello!
>
> On 5/16/2018 10:54 AM, Simon Horman wrote:
>
>>> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
>>>
>>> Signed-off-by: Ulrich Hecht
>>> ---
>>> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> index 3d2d3bb..58fb9f8 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
>>> rcar_lvds_r8a77970_info = {
>>> .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
>>> };
>>> +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
>>> + .gen = 3,
>>> + .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
>>> +};
>>
>>
>> This new structure seems to be identical to rcar_lvds_r8a77970_info.
>
>> Could we consolidate somehow?
>
>In my book, that one has 2 quirk flags. What tree are you looking at?
IIRC the other one was for the PLL, which is not supported yet.
CU
Uli
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/adreno: Add power management functions for system sleep
When a msm8016 based system is woken up from suspend, the firmware in
the adreno device hangs.
[ 83.903416] qcom-iommu-ctx 1f09000.iommu-ctx: Unhandled context fault:
fsr=0x202, iova=0x, fsynr=0x2, cb=1
[ 85.853633] msm 1a0.mdss: A306: hangcheck detected gpu lockup rb 0!
[ 85.853661] msm 1a0.mdss: A306: completed fence: 370
[ 85.859073] msm 1a0.mdss: A306: submitted fence: 372
[ 85.865113] msm 1a0.mdss: A306: hangcheck recover!
Fix this by adding pm_runtime_force_suspend/pm_runtime_force_resume
as sleep ops.
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea2a007..12d87ccdec53 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -357,6 +357,7 @@ static int adreno_suspend(struct device *dev)
#endif
static const struct dev_pm_ops adreno_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(adreno_suspend, adreno_resume, NULL)
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/26] drm/bridge: vga-dac: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 9837c8d69e69..95cce18e8943 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -205,8 +205,8 @@ static int dumb_vga_probe(struct platform_device *pdev) } } + vga->bridge.odev = &pdev->dev; vga->bridge.funcs = &dumb_vga_bridge_funcs; - vga->bridge.of_node = pdev->dev.of_node; vga->bridge.timings = of_device_get_match_data(&pdev->dev); drm_bridge_add(&vga->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/26] drm/bridge: lvds-encoder: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/lvds-encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c b/drivers/gpu/drm/bridge/lvds-encoder.c index 75b0d3f6e4de..a80eec17b13b 100644 --- a/drivers/gpu/drm/bridge/lvds-encoder.c +++ b/drivers/gpu/drm/bridge/lvds-encoder.c @@ -83,7 +83,7 @@ static int lvds_encoder_probe(struct platform_device *pdev) * but we need a bridge attached to our of_node for our user * to look up. */ - lvds_encoder->bridge.of_node = pdev->dev.of_node; + lvds_encoder->bridge.odev = &pdev->dev; lvds_encoder->bridge.funcs = &funcs; drm_bridge_add(&lvds_encoder->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/26] drm/exynos: mic: provide an owner .odev device for the bridge
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c index 2174814273e2..f9ff8d3ec937 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c @@ -417,8 +417,8 @@ static int exynos_mic_probe(struct platform_device *pdev) platform_set_drvdata(pdev, mic); + mic->bridge.odev = dev; mic->bridge.funcs = &mic_bridge_funcs; - mic->bridge.of_node = dev->of_node; drm_bridge_add(&mic->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/16/2018 2:23 PM, Sinan Kaya wrote:
> + if (win_start <= base && win_end >= base + win_size - 1) {
> + base += window->offset;
> + break;
> + }
I should probably add window->offset!=0 to the if statement in order not to
break non-translating case.
Any other comments?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/26] drm/bridge: sii8620: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/sil-sii8620.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c index 7ab36042a822..8e35578b0488 100644 --- a/drivers/gpu/drm/bridge/sil-sii8620.c +++ b/drivers/gpu/drm/bridge/sil-sii8620.c @@ -2387,8 +2387,8 @@ static int sii8620_probe(struct i2c_client *client, i2c_set_clientdata(client, ctx); + ctx->bridge.odev = dev; ctx->bridge.funcs = &sii8620_bridge_funcs; - ctx->bridge.of_node = dev->of_node; drm_bridge_add(&ctx->bridge); if (!ctx->extcon) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/26] drm/bridge: analogix-anx78xx: provide an owner .odev device
It gets rid of an #if and the .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index b49043866be6..1d6620aedbdb 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -1332,10 +1332,6 @@ static int anx78xx_i2c_probe(struct i2c_client *client, mutex_init(&anx78xx->lock); -#if IS_ENABLED(CONFIG_OF) - anx78xx->bridge.of_node = client->dev.of_node; -#endif - anx78xx->client = client; i2c_set_clientdata(client, anx78xx); @@ -1433,6 +1429,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client, goto err_poweroff; } + anx78xx->bridge.odev = &client->dev; anx78xx->bridge.funcs = &anx78xx_bridge_funcs; drm_bridge_add(&anx78xx->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/26] drm/bridge: nxp-ptn3460: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c b/drivers/gpu/drm/bridge/nxp-ptn3460.c index d64a3283822a..fa832f32b518 100644 --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c @@ -329,8 +329,8 @@ static int ptn3460_probe(struct i2c_client *client, return ret; } + ptn_bridge->bridge.odev = dev; ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs; - ptn_bridge->bridge.of_node = dev->of_node; drm_bridge_add(&ptn_bridge->bridge); i2c_set_clientdata(client, ptn_bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 05/16/2018 01:23 PM, Sinan Kaya wrote: + win_start = window->res->start - window->offset; Can you guarantee that window->res->start is always >= window->offset? + win_size = window->res->end - window->res->start + 1; Use resource_size() instead. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 21/26] drm/msm: specify the owner .odev of the bridges
This will become mandatory. Signed-off-by: Peter Rosin --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 + drivers/gpu/drm/msm/edp/edp_bridge.c | 1 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 + 3 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index 4cb1cb68878b..1668e8abe5c1 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -710,6 +710,7 @@ struct drm_bridge *msm_dsi_manager_bridge_init(u8 id) encoder = msm_dsi->encoder; bridge = &dsi_bridge->base; + bridge->odev = msm_dsi->dev->dev; bridge->funcs = &dsi_mgr_bridge_funcs; ret = drm_bridge_attach(encoder, bridge, NULL); diff --git a/drivers/gpu/drm/msm/edp/edp_bridge.c b/drivers/gpu/drm/msm/edp/edp_bridge.c index 931a5c97cccf..4c56e29c57b7 100644 --- a/drivers/gpu/drm/msm/edp/edp_bridge.c +++ b/drivers/gpu/drm/msm/edp/edp_bridge.c @@ -104,6 +104,7 @@ struct drm_bridge *msm_edp_bridge_init(struct msm_edp *edp) edp_bridge->edp = edp; bridge = &edp_bridge->base; + bridge->odev = edp->dev->dev; bridge->funcs = &edp_bridge_funcs; ret = drm_bridge_attach(edp->encoder, bridge, NULL); diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c index 7e357077ed26..aa6dd1bc5dc0 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c @@ -293,6 +293,7 @@ struct drm_bridge *msm_hdmi_bridge_init(struct hdmi *hdmi) hdmi_bridge->hdmi = hdmi; bridge = &hdmi_bridge->base; + bridge->odev = hdmi->dev->dev; bridge->funcs = &msm_hdmi_bridge_funcs; ret = drm_bridge_attach(hdmi->encoder, bridge, NULL); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support
On Tue, May 15, 2018 at 02:20:37PM +0200, Ulrich Hecht wrote:
> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
>
> Signed-off-by: Ulrich Hecht
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 3d2d3bb..58fb9f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
> rcar_lvds_r8a77970_info = {
> .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
> };
>
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
> +};
This new structure seems to be identical to rcar_lvds_r8a77970_info.
Could we consolidate somehow?
> +
> static const struct of_device_id rcar_lvds_of_table[] = {
> { .compatible = "renesas,r8a7743-lvds", .data = &rcar_lvds_gen2_info },
> { .compatible = "renesas,r8a7790-lvds", .data = &rcar_lvds_r8a7790_info
> },
> @@ -519,6 +524,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
> { .compatible = "renesas,r8a7795-lvds", .data = &rcar_lvds_gen3_info },
> { .compatible = "renesas,r8a7796-lvds", .data = &rcar_lvds_gen3_info },
> { .compatible = "renesas,r8a77970-lvds", .data =
> &rcar_lvds_r8a77970_info },
> + { .compatible = "renesas,r8a77995-lvds", .data =
> &rcar_lvds_r8a77995_info },
> { }
> };
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/26] drm/bridge: ps8622: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/parade-ps8622.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c b/drivers/gpu/drm/bridge/parade-ps8622.c index 81198f5e9afa..957420a1c924 100644 --- a/drivers/gpu/drm/bridge/parade-ps8622.c +++ b/drivers/gpu/drm/bridge/parade-ps8622.c @@ -595,8 +595,8 @@ static int ps8622_probe(struct i2c_client *client, ps8622->bl->props.brightness = PS8622_MAX_BRIGHTNESS; } + ps8622->bridge.odev = dev; ps8622->bridge.funcs = &ps8622_bridge_funcs; - ps8622->bridge.of_node = dev->of_node; drm_bridge_add(&ps8622->bridge); i2c_set_clientdata(client, ps8622); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/26] device link, bridge supplier <-> drm device
Hi! It was noted by Russell King [1] that bridges (not using components) might disappear unexpectedly if the owner of the bridge was unbound. Jyri Sarha had previously noted the same thing with panels [2]. Jyri came up with using device links to resolve the panel issue, which was also my (independent) reaction to the note from Russell. This series builds up to the addition of that link in the last patch, but in my opinion the other 25 patches do have merit on their own. The last patch needs testing, while the others look trivial. Jyri, are you able to test? That said, I might have missed some subtlety. Oh, and the reason I'm pushing this is of course so that the issue noted by Russell in [1] is addressed which in turn means that the tda998x bridge driver can be patched according to that series without objection (hopefully) and then used from the atmel-hlcdc driver (and other drivers that are not componentized). Changes since v2https://lkml.org/lkml/2018/5/4/443 - Russell King spells his name this way. Sorry! - Add review tag from Andrzej Hajda (patches 1, 25 and 26). - Add ack tag from Daniel Vetter (patches 1, 24, 25 and 26). - Mention the interaction with the rockchip_lvds driver in the commit message for patch 1. - Change the comment for the new @link member in patch 26, so that a symmetric relationchip between cunsumer/supplier isn't implied. Changes since v1https://lkml.org/lkml/2018/4/26/1018 - rename .owner to .odev to not get mixed up with the module owner. - added patches for new recent drivers thc63lvd1024 and cdns-dsi - fix for problem in the rockchip_lvds driver reported by 0day - added a WARN in drm_bridge_add if there is no .odev owner device Cheers, Peter [1] https://lkml.org/lkml/2018/4/23/769 [2] https://www.spinics.net/lists/dri-devel/msg174275.html Peter Rosin (26): drm/bridge: allow optionally specifying an owner .odev device drm/bridge: adv7511: provide an owner .odev device drm/bridge/analogix: core: specify the owner .odev of the bridge drm/bridge: analogix-anx78xx: provide an owner .odev device drm/bridge: cdns-dsi: provide an owner .odev device drm/bridge: vga-dac: provide an owner .odev device drm/bridge: lvds-encoder: provide an owner .odev device drm/bridge: megachips-stdp-ge-b850v3-fw: provide an owner .odev device drm/bridge: nxp-ptn3460: provide an owner .odev device drm/bridge: panel: provide an owner .odev device drm/bridge: ps8622: provide an owner .odev device drm/bridge: sii902x: provide an owner .odev device drm/bridge: sii9234: provide an owner .odev device drm/bridge: sii8620: provide an owner .odev device drm/bridge: synopsys: provide an owner .odev device for the bridges drm/bridge: tc358767: provide an owner .odev device drm/bridge: thc63lvd1024: provide an owner .odev device drm/bridge: ti-tfp410: provide an owner .odev device drm/exynos: mic: provide an owner .odev device for the bridge drm/mediatek: hdmi: provide an owner .odev device for the bridge drm/msm: specify the owner .odev of the bridges drm/rcar-du: lvds: provide an owner .odev device for the bridge drm/sti: provide an owner .odev device for the bridges drm/bridge: remove the .of_node member drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach drm/bridge: establish a link between the bridge supplier and consumer drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 + drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- drivers/gpu/drm/bridge/lvds-encoder.c | 2 +- .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c | 4 +--- drivers/gpu/drm/bridge/parade-ps8622.c | 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/sii9234.c | 2 +- drivers/gpu/drm/bridge/sil-sii8620.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +--- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +--- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c | 2 +- drivers/gpu/drm/drm_bridge.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_mic.c| 2 +- drivers/gpu/drm/mediatek/mtk_hdmi.c| 2 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 + drivers/gpu/drm/msm/edp/edp_bridge.c | 1 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 + drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 +- drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +- drivers/gpu/drm/sti/sti_d
[PATCH v3 10/26] drm/bridge: panel: provide an owner .odev device
It gets rid of an #ifdef and the .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/panel.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 6d99d4a3beb3..f43d77b5ed20 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -169,10 +169,8 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel, panel_bridge->connector_type = connector_type; panel_bridge->panel = panel; + panel_bridge->bridge.odev = panel->dev; panel_bridge->bridge.funcs = &panel_bridge_bridge_funcs; -#ifdef CONFIG_OF - panel_bridge->bridge.of_node = panel->dev->of_node; -#endif drm_bridge_add(&panel_bridge->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index 59a11026dceb..d8c7d93d0a87 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev) mtk_hdmi_register_audio_driver(dev); + hdmi->bridge.odev = &pdev->dev; hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs; - hdmi->bridge.of_node = pdev->dev.of_node; drm_bridge_add(&hdmi->bridge); ret = mtk_hdmi_clk_enable_audio(hdmi); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/26] drm/bridge: sii902x: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/sii902x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..894525b05985 100644 --- a/drivers/gpu/drm/bridge/sii902x.c +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -427,8 +427,8 @@ static int sii902x_probe(struct i2c_client *client, return ret; } + sii902x->bridge.odev = dev; sii902x->bridge.funcs = &sii902x_bridge_funcs; - sii902x->bridge.of_node = dev->of_node; drm_bridge_add(&sii902x->bridge); i2c_set_clientdata(client, sii902x); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/26] drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c index 7ccadba7c98c..29d1b5ae5fb6 100644 --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c @@ -313,8 +313,8 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client *stdp4028_i2c, i2c_set_clientdata(stdp4028_i2c, ge_b850v3_lvds_ptr); /* drm bridge initialization */ + ge_b850v3_lvds_ptr->bridge.odev = dev; ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs; - ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node; drm_bridge_add(&ge_b850v3_lvds_ptr->bridge); /* Clear pending interrupts since power up. */ -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/26] drm/bridge: synopsys: provide an owner .odev device for the bridges
It gets rid of two #ifdefs and the .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +--- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index ec8d0006ef7c..e3956a7e827c 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2471,11 +2471,9 @@ __dw_hdmi_probe(struct platform_device *pdev, hdmi->ddc = NULL; } + hdmi->bridge.odev = dev; hdmi->bridge.driver_private = hdmi; hdmi->bridge.funcs = &dw_hdmi_bridge_funcs; -#ifdef CONFIG_OF - hdmi->bridge.of_node = pdev->dev.of_node; -#endif dw_hdmi_setup_i2c(hdmi); if (hdmi->phy.ops->setup_hpd) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index fd7999642cf8..7c8d05f7cecd 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -930,11 +930,9 @@ __dw_mipi_dsi_probe(struct platform_device *pdev, return ERR_PTR(ret); } + dsi->bridge.odev = dev; dsi->bridge.driver_private = dsi; dsi->bridge.funcs = &dw_mipi_dsi_bridge_funcs; -#ifdef CONFIG_OF - dsi->bridge.of_node = pdev->dev.of_node; -#endif return dsi; } -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support
On Tue, May 15, 2018 at 02:20:38PM +0200, Ulrich Hecht wrote: > From: Kieran Bingham > > The r8a77995 D3 platform has 2 LVDS channels connected to the DU. > > Signed-off-by: Kieran Bingham > [uli: moved lvds* into the soc node, added PM domains, resets] > Signed-off-by: Ulrich Hecht This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
(bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya
---
drivers/video/fbdev/efifb.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..feef02b 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_host_bridge *bridge;
+ struct resource_entry *window;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,27 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ bridge = pci_find_host_bridge(dev->bus);
+ if (!bridge)
+ return;
+
+ resource_list_for_each_entry(window, &bridge->windows) {
+ phys_addr_t win_start;
+ phys_addr_t win_end;
+ size_t win_size;
+
+ if (resource_type(window->res) != IORESOURCE_MEM)
+ continue;
+
+ win_start = window->res->start - window->offset;
+ win_end = window->res->end - window->offset;
+ win_size = window->res->end - window->res->start + 1;
+ if (win_start <= base && win_end >= base + win_size - 1) {
+ base += window->offset;
+ break;
+ }
+ }
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach
The .odev owner device will be handy to have around.
Reviewed-by: Andrzej Hajda
Acked-by: Daniel Vetter
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
*/
void drm_bridge_add(struct drm_bridge *bridge)
{
+ if (WARN_ON(!bridge->odev))
+ return;
+
mutex_lock(&bridge_lock);
list_add_tail(&bridge->list, &bridge_list);
mutex_unlock(&bridge_lock);
@@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
if (!encoder || !bridge)
return -EINVAL;
+ if (WARN_ON(!bridge->odev))
+ return -EINVAL;
+
if (previous && (!previous->dev || previous->encoder != encoder))
return -EINVAL;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
On Wed, May 16, 2018 at 12:12 PM, Chen-Yu Tsai wrote:
> On Mon, May 14, 2018 at 11:03 AM, Jagan Teki
> wrote:
>> On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wrote:
>>> This panel is marketed as Banana Pi 7" LCD display. On the back is
>>> a sticker denoting the model name S070WV20-CT16.
>>>
>>> This is a 7" 800x480 panel connected through a 24-bit RGB interface.
>>> However the panel only does 262k colors.
>>>
>>> Signed-off-by: Chen-Yu Tsai
>>> ---
>>> .../display/panel/bananapi,s070wv20-ct16.txt | 7 ++
>>> drivers/gpu/drm/panel/panel-simple.c | 25 +++
>>> 2 files changed, 32 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>>
>>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>> new file mode 100644
>>> index ..2ec35ce36e9a
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>> @@ -0,0 +1,7 @@
>>> +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
>>> +
>>> +Required properties:
>>> +- compatible: should be "bananapi,s070wv20-ct16"
>>> +
>>> +This binding is compatible with the simple-panel binding, which is
>>> specified
>>> +in simple-panel.txt in this directory.
>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>> b/drivers/gpu/drm/panel/panel-simple.c
>>> index cbf1ab404ee7..9bc037f74d6c 100644
>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>> @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
>>> },
>>> };
>>>
>>> +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
>>> + .clock = 3,
>>> + .hdisplay = 800,
>>> + .hsync_start = 800 + 40,
>>> + .hsync_end = 800 + 40 + 48,
>>> + .htotal = 800 + 40 + 48 + 40,
>>> + .vdisplay = 480,
>>> + .vsync_start = 480 + 13,
>>> + .vsync_end = 480 + 13 + 3,
>>> + .vtotal = 480 + 13 + 3 + 29,
>>> +};
>>> +
>>> +static const struct panel_desc bananapi_s070wv20_ct16 = {
>>> + .modes = &bananapi_s070wv20_ct16_mode,
>>> + .num_modes = 1,
>>> + .bpc = 6,
>>> + .size = {
>>> + .width = 154,
>>> + .height = 86,
>>> + },
>>> +};
>>
>> I think this parallel RGB interface right? I too have same display
>> with DSI I'm sure these setting will not useful right? do we need to
>> write separate panel driver for that?
>
> AFAIK the DSI model is an RGB panel with a MIPI DSI bridge on the
> connector board. The model I have is dual interface.
Yes, this is what I have [1] where same strip can use for both RGB and
MIPI DSI. can bananapi,s070wv20-ct16 work for DSI interface as well?
[1]
https://www.aliexpress.com/item/New-Arrival-Banana-Pro-Pi-7-inch-LCD-Display-Touch-Screen-Raspberry-Pi-Car-GPS-FreeShipping/32335608836.html
Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/14] mm: turn on vm_fault_t type checking
On Wed, May 16, 2018 at 07:43:48AM +0200, Christoph Hellwig wrote:
> Switch vm_fault_t to point to an unsigned int with __bіtwise annotations.
> This both catches any old ->fault or ->page_mkwrite instance with plain
> compiler type checking, as well as finding more intricate problems with
> sparse.
>
> Signed-off-by: Christoph Hellwig
> ---
For the iomap and xfs parts,
Reviewed-by: Darrick J. Wong
That said...
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 54f1e05ecf3e..da2b77a19911 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -22,7 +22,8 @@
> #endif
> #define AT_VECTOR_SIZE (2*(AT_VECTOR_SIZE_ARCH + AT_VECTOR_SIZE_BASE + 1))
>
> -typedef int vm_fault_t;
> +typedef unsigned __bitwise vm_fault_t;
> +
>
> struct address_space;
> struct mem_cgroup;
> @@ -619,7 +620,7 @@ struct vm_special_mapping {
>* If non-NULL, then this is called to resolve page faults
>* on the special mapping. If used, .pages is not checked.
>*/
> - int (*fault)(const struct vm_special_mapping *sm,
> + vm_fault_t (*fault)(const struct vm_special_mapping *sm,
Uh, we're changing function signatures /and/ redefinining vm_fault_t?
All in the same 90K patch?
I /was/ expecting a series of "convert X and all callers/users"
patches followed by a trivial one to switch the definition, not a giant
pile of change. FWIW I don't mind so much if you make a patch
containing a change for some super-common primitive and a hojillion
little diff hunks tree-wide, but only one logical change at a time for a
big patch, please...
I quite prefer seeing the whole series from start to finish all packaged
up in one series, but wow this was overwhelming. :/
--D
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Quoting Sandeep Panda (2018-05-14 22:52:42)
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 000..b82bb56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,81 @@
> +Optional properties:
> +- interrupts: Specifier for the SN65DSI86 interrupt line.
> +- hpd-gpios: OF device-tree gpio specifications for HPD pin.
> +
> +- gpio-controller: Marks the device has a GPIO controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> + the second cell is used to specify flags.
> + See ../../gpio/gpio.txt for more information.
> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
> + the cell formats.
> +
> +- clock-names: should be "refclk"
> +- clocks: OF device-tree clock specification for refclk input. The reference
What is "OF device-tree .* specification" providing? This is all an OF
device-tree specification.
> + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the
> +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for DSI input
> +- Video port 1 for eDP output
> +
> +Example
> +---
> +
> +edp-bridge@2d {
> + compatible = "ti,sn65dsi86";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2d>;
> +
> + enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
> +
> + vccio-supply = <&pm8916_l17>;
> + vcca-supply = <&pm8916_l6>;
> + vpll-supply = <&pm8916_l17>;
> + vcc-supply = <&pm8916_l6>;
> +
> + clock-names = "refclk";
> + clocks = <&input_refclk>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + edp_bridge_in: endpoint {
> + remote-endpoint = <&dsi_out>;
How do we know the number of lanes that are connected and if there's one
channel (A) or two channels (A and B)? Would there be two endpoints in
that case?
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + edp_bridge_out: endpoint {
> + remote-endpoint = <&edp_panel_in>;
The hardware looks to support some sort of lane renumbering scheme,
where the eDP logical lane 0 can be routed through a different pin than
MLP/N0, same for logical lane 1, etc. I don't have a use case for this
right now, but I hope that it could be added somewhere in the binding as
an optional property to describe this lane remapping feature. It also
has some sort of lane polarity inversion feature. Perhaps there needs to
be a lane-config property that does this remapping and inversion with
two cells.
lane-config = <0 0>, /* Lane 0 logical is lane 0 phys (!inv) */
<1 0>, /* Lane 1 logical is lane 1 phys (!inv) */
<2 0>, /* Lane 2 logical is lane 2 phys (!inv) */
<3 0>; /* Lane 3 logical is lane 3 phys (!inv) */
Or
lane-config = <2 1>, /* Lane 2 logical is lane 0 phys (inv) */
<1 0>, /* Lane 1 logical is lane 1 phys (!inv) */
<3 1>, /* Lane 3 logical is lane 2 phys (inv) */
<0 0>; /* Lane 0 logical is lane 3 phys (!inv) */
> + };
> + };
> + };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()
To make suspend and resume work on msm8916 platforms, call into the generic
helpers and preserve the state across suspends.
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/msm/msm_drv.c | 9 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0a3ea3034e39..cdbe9249bff2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -907,16 +907,25 @@ static struct drm_driver msm_driver = {
static int msm_pm_suspend(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
drm_kms_helper_poll_disable(ddev);
+ priv->pm_state = drm_atomic_helper_suspend(ddev);
+ if (IS_ERR(priv->pm_state)) {
+ drm_kms_helper_poll_enable(ddev);
+ return PTR_ERR(priv->pm_state);
+ }
+
return 0;
}
static int msm_pm_resume(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
+ drm_atomic_helper_resume(ddev, priv->pm_state);
drm_kms_helper_poll_enable(ddev);
return 0;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0a653dd2e618..459d06a1ab9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -155,6 +155,7 @@ struct msm_drm_private {
struct shrinker shrinker;
struct msm_vblank_ctrl vblank_ctrl;
+ struct drm_atomic_state *pm_state;
};
struct msm_format {
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/26] drm/bridge: adv7511: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 2614cea538e2..fd2eef916b0b 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1204,8 +1204,8 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret) goto err_unregister_cec; + adv7511->bridge.odev = dev; adv7511->bridge.funcs = &adv7511_bridge_funcs; - adv7511->bridge.of_node = dev->of_node; drm_bridge_add(&adv7511->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/14] btrfs: separate errno from VM_FAULT_* values
On Wed, May 16, 2018 at 07:43:40AM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Reviewed-by: David Sterba I can add it to the btrfs queue now, unless you need the patch for the rest of the series. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] docs: Fix some broken references
On 9 May 2018 at 07:18, Mauro Carvalho Chehab wrote: > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix-rst > > Manually checked if the produced result is valid, removing a few > false-positives. > > Signed-off-by: Mauro Carvalho Chehab > --- > > diff --git a/Documentation/trace/coresight.txt > b/Documentation/trace/coresight.txt > index 1d74ad0202b6..efbc832146e7 100644 > --- a/Documentation/trace/coresight.txt > +++ b/Documentation/trace/coresight.txt > @@ -426,5 +426,5 @@ root@genericarmv8:~# > Details on how to use the generic STM API can be found here [2]. > > [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm > -[2]. Documentation/trace/stm.txt > +[2]. Documentation/trace/stm.rst > [3]. https://github.com/Linaro/perf-opencsd Acked-by: Mathieu Poirier ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/14] vgem: separate errno from VM_FAULT_* values
On Wed, May 16, 2018 at 03:01:59PM +0200, Christoph Hellwig wrote: > On Wed, May 16, 2018 at 11:53:03AM +0200, Daniel Vetter wrote: > > Reviewed-by: Daniel Vetter > > > > Want me to merge this through drm-misc or plan to pick it up yourself? > > For now I just want a honest discussion if people really actually > want the vm_fault_t change with the whole picture in place. That discussion already happened on the -mm mailing list. And again at LSFMM. Both times the answer was yes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error
On Wed, 2018-05-16 at 12:26 +0200, Lucas Stach wrote:
> Am Mittwoch, den 16.05.2018, 11:42 +0200 schrieb Daniel Vetter:
> > On Tue, May 15, 2018 at 01:16:30PM +0100, Chris Wilson wrote:
> > > Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> > > > On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > > > > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > > > > > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > > > > > Change how dma_fence_add_callback() behaves, when the fence
> > > > > > > has error-signaled by the time it is being add. After this commit,
> > > > > > > dma_fence_add_callback() returns the fence error, if it
> > > > > > > has error-signaled before dma_fence_add_callback() is called.
> > > > > >
> > > > > > Why? What problem are you trying to solve? fence->error does not
> > > > > > imply
> > > > > > that the fence has yet been signaled, and the caller wants a
> > > > > > callback
> > > > > > when it is signaled.
> > > > >
> > > > > On top this is incosistent, e.g. we don't do the same for any of the
> > > > > other
> > > > > dma_fence interfaces. Plus there's the issue that you might alias
> > > > > errno
> > > > > values with fence errno values.
> > > > >
> > > >
> > > > Right.
> > > >
> > > > > I think keeping the error codes from the functions you're calling
> > > > > distinct
> > > > > from the error code of the fence itself makes a lot of sense. The
> > > > > first
> > > > > tells you whether your request worked out (or why not), the second
> > > > > tells
> > > > > you whether the asynchronous dma operation (gpu rendering, page flip,
> > > > > whatever) that the dma_fence represents worked out (or why not).
> > > > > That's 2
> > > > > distinct things imo.
> > > > >
> > > > > Might be good to show us the driver code that needs this behaviour so
> > > > > we
> > > > > can discuss how to best handle your use-case.
> > > > >
> > > >
> > > > This change arose while discussing the in-fences support for
> > > > video4linux.
> > > > Here's the patch that calls dma_fence_add_callback
> > > > https://lkml.org/lkml/2018/5/4/766.
> > > >
> > > > The code snippet currently looks something like this:
> > > >
> > > > if (vb->in_fence) {
> > > > ret = dma_fence_add_callback(vb->in_fence,
> > > > &vb->fence_cb,
> > > >
> > > > vb2_qbuf_fence_cb);
> > > > /* is the fence signaled? */
> > > > if (ret == -ENOENT) {
> > > >
> > > > dma_fence_put(vb->in_fence);
> > > > vb->in_fence = NULL;
> > > > } else if (ret)
> > > > {
> > > > goto unlock;
> > > > }
> > > > }
> > > >
> > > > In this use case, if the callback is added successfully,
> > > > the video4linux core defers the activation of the buffer
> > > > until the fence signals.
> > > >
> > > > If the fence is signaled (currently disregarding of errors)
> > > > then the buffer is assumed to be ready to be activated,
> > > > and so it gets queued for hardware usage.
> > > >
> > > > Giving some more thought to this, I'm not so sure what is
> > > > the right action if a fence signaled with error. In this case,
> > > > it appears to me that we shouldn't be using this buffer
> > > > if its in-fence is in error, but perhaps I'm missing
> > > > something.
> > >
> > > What I have in mind for async errors is to skip the operation and
> > > propagate the error onto the next fence. Mostly because those async
> > > errors may include fatal errors such as unable to pin the backing
> > > storage for the operation, but even "trivial" errors such as an early
> > > operation failing means that this request is then subject to garbage-in,
> > > garbage-out. However, for trivial errors I would just propagate the
> > > error status (so the caller knows something went wrong if they care, but
> > > in all likelihood no one will notice) and continue on with the glitchy
> > > operation.
> >
> > In general, there's not really any hard rule about propagating fence
> > errors across devices. It's mostly just used by drivers internally to keep
> > track of failed stuff (gpu hangs or anything else async like Chris
> > describes here).
> >
> > For v4l I'm not sure you want to care much about this, since right now the
> > main use of fence errors is gpu hang recovery (whether it's the driver or
> > hw that's hung doesn't matter here).
>
> Yes, my understanding is that fence signal and errors are two distinct
> things that should not be conflated like it is done in this patch.
>
> In my understanding signaling a fence means the HW or SW component
> which added the fence is done with the buffer and will not touch it
> anymore. In case of an unrecoverable error the fence will be signaled
> with error status set, so we correctly reflect the buffer status as
> being free to be used by whoever is waiting for it, but may conta
[PATCH v3 24/26] drm/bridge: remove the .of_node member
It is unused.
Acked-by: Daniel Vetter
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 3 +--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
include/drm/drm_bridge.h | 4
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 3872f5379998..df084db33494 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,8 +365,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node
*np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if ((bridge->odev && bridge->odev->of_node == np) ||
- bridge->of_node == np) {
+ if (bridge->odev->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 557e0079c98d..e77d4c909582 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else if (lvds->bridge->of_node)
- remote = lvds->bridge->of_node;
else
remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 7c17977c3537..b656e505d11e 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,7 +258,6 @@ struct drm_bridge_timings {
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
- * @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
@@ -270,9 +269,6 @@ struct drm_bridge {
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-#ifdef CONFIG_OF
- struct device_node *of_node;
-#endif
struct list_head list;
const struct drm_bridge_timings *timings;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/26] drm/bridge: ti-tfp410: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/ti-tfp410.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index acb857030951..4745838fdf0e 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c +++ b/drivers/gpu/drm/bridge/ti-tfp410.c @@ -215,8 +215,8 @@ static int tfp410_init(struct device *dev) return -ENOMEM; dev_set_drvdata(dev, dvi); + dvi->bridge.odev = dev; dvi->bridge.funcs = &tfp410_bridge_funcs; - dvi->bridge.of_node = dev->of_node; dvi->dev = dev; ret = tfp410_get_connector_properties(dvi); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] docs: Fix some broken references
On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote: > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix-rst > > Manually checked if the produced result is valid, removing a few > false-positives. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/input/touchscreen/wm97xx-core.c | 2 +- Acked-by: Charles Keepax Thanks, Charles ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: rcar-du: Add r8a77995 device support
On Tue, May 15, 2018 at 02:20:36PM +0200, Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Ulrich Hecht
Reviewed-by: Simon Horman
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 05745e8..ba82842 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -266,6 +266,31 @@ static const struct rcar_du_device_info
> rcar_du_r8a77970_info = {
> .num_lvds = 1,
> };
>
> +static const struct rcar_du_device_info rcar_du_r8a77995_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> + | RCAR_DU_FEATURE_EXT_CTRL_REGS
> + | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 2,
> + .routes = {
> + /* R8A77995 has two LVDS output and one RGB output.
> + */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0) | BIT(1),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS1] = {
> + .possible_crtcs = BIT(1),
> + .port = 2,
> + },
> + },
> + .num_lvds = 2,
> +};
> +
> static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
> @@ -278,6 +303,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
> { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
> { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info },
> + { .compatible = "renesas,du-r8a77995", .data = &rcar_du_r8a77995_info },
> { }
> };
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/26] drm/bridge: thc63lvd1024: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c index c8b9edd5a7f4..4765c9c45aef 100644 --- a/drivers/gpu/drm/bridge/thc63lvd1024.c +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c @@ -167,8 +167,8 @@ static int thc63_probe(struct platform_device *pdev) if (ret) return ret; + thc63->bridge.odev = &pdev->dev; thc63->bridge.driver_private = thc63; - thc63->bridge.of_node = pdev->dev.of_node; thc63->bridge.funcs = &thc63_bridge_func; drm_bridge_add(&thc63->bridge); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 26/26] drm/bridge: establish a link between the bridge supplier and consumer
If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.
Reviewed-by: Andrzej Hajda
Acked-by: Daniel Vetter
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 18 ++
include/drm/drm_bridge.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
+ if (encoder->dev->dev != bridge->odev) {
+ bridge->link = device_link_add(encoder->dev->dev,
+ bridge->odev, 0);
+ if (!bridge->link) {
+ dev_err(bridge->odev, "failed to link bridge to %s\n",
+ dev_name(encoder->dev->dev));
+ return -EINVAL;
+ }
+ }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
+
bridge->dev = NULL;
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..bd1265c5a0bc 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
+ * @link: device link between the drm consumer and the bridge supplier
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+ struct device_link *link;
const struct drm_bridge_funcs *funcs;
void *driver_private;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device
Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.
By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.
When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.
There is an interaction with the rockchip lvds driver, since that
driver peeks into somewhat private parts of the bridge struct in
order to find out things about the remote bridge. When there are
now two ways to get to the remote bridge, the rockchip lvds driver
has to adapt. That said, the correct thing to do for the rockchip
lvds driver is to use some other way than DT to find things out
about the remote bridge, but that is orthogonal to this patch.
Reviewed-by: Andrzej Hajda
Acked-by: Daniel Vetter
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 3 ++-
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
include/drm/drm_bridge.h | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node
*np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if (bridge->of_node == np) {
+ if ((bridge->odev && bridge->odev->of_node == np) ||
+ bridge->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else
+ else if (lvds->bridge->of_node)
remote = lvds->bridge->of_node;
+ else
+ remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
/**
* struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
+ struct device *odev;
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 5/16/2018 2:31 PM, Timur Tabi wrote: > On 05/16/2018 01:23 PM, Sinan Kaya wrote: >> + win_start = window->res->start - window->offset; > > Can you guarantee that window->res->start is always >= window->offset? > Resource offset is generally 0 when not translating or a positive number that you subtract from the resource start to reach to the translating window. Having a bigger offset than resource start should be considered a BIOS bug. >> + win_size = window->res->end - window->res->start + 1; > > Use resource_size() instead. > I'll fix it. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 23/26] drm/sti: provide an owner .odev device for the bridges
The .of_node member is going away and providing an .odev will become mandatory. Signed-off-by: Peter Rosin --- drivers/gpu/drm/sti/sti_dvo.c | 2 +- drivers/gpu/drm/sti/sti_hda.c | 1 + drivers/gpu/drm/sti/sti_hdmi.c | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c index a5979cd25cc7..f2609725f8f1 100644 --- a/drivers/gpu/drm/sti/sti_dvo.c +++ b/drivers/gpu/drm/sti/sti_dvo.c @@ -460,9 +460,9 @@ static int sti_dvo_bind(struct device *dev, struct device *master, void *data) if (!bridge) return -ENOMEM; + bridge->odev = &dvo->dev; bridge->driver_private = dvo; bridge->funcs = &sti_dvo_bridge_funcs; - bridge->of_node = dvo->dev.of_node; drm_bridge_add(bridge); err = drm_bridge_attach(encoder, bridge, NULL); diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c index 199db13f565c..7fcd24664cd0 100644 --- a/drivers/gpu/drm/sti/sti_hda.c +++ b/drivers/gpu/drm/sti/sti_hda.c @@ -694,6 +694,7 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data) if (!bridge) return -ENOMEM; + bridge->odev = dev; bridge->driver_private = hda; bridge->funcs = &sti_hda_bridge_funcs; drm_bridge_attach(encoder, bridge, NULL); diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 932724784942..d1d2e1a1920c 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -1270,6 +1270,7 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data) if (!bridge) return -EINVAL; + bridge->odev = dev; bridge->driver_private = hdmi; bridge->funcs = &sti_hdmi_bridge_funcs; drm_bridge_attach(encoder, bridge, NULL); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] arm64: dts: renesas: r8a77995-draak: add X12 input dot clock
On Tue, May 15, 2018 at 02:20:40PM +0200, Ulrich Hecht wrote: > 74.25 Mhz oscillator X12 is connected to DU_DOTCLKIN0. > > Signed-off-by: Ulrich Hecht > --- > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++ > 1 file changed, 11 insertions(+) This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vm_fault_t conversion, for real
On Wed, May 16, 2018 at 03:03:09PM +0200, Christoph Hellwig wrote: > On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote: > > On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote: > > > this series tries to actually turn vm_fault_t into a type that can be > > > typechecked and checks the fallout instead of sprinkling random > > > annotations without context. > > > > Yes, why should we have small tasks that newcomers can do when the mighty > > Christoph Hellwig can swoop in and take over from them? Seriously, > > can't your talents find a better use than this? > > I've spent less time on this than trying to argue to you and Souptick > that these changes are only to get ignored and yelled at as an > "asshole maintainer". So yes, I could have done more productive things > if you hadn't forced this escalation. Perhaps you should try being less of an arsehole if you don't want to get yelled at? I don't mind when you're an arsehole towards me, but I do mind when you're an arsehole towards newcomers. How are we supposed to attract and retain new maintainers when you're so rude? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/26] drm/bridge: sii9234: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/sii9234.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c index c77000626c22..54326357b2ee 100644 --- a/drivers/gpu/drm/bridge/sii9234.c +++ b/drivers/gpu/drm/bridge/sii9234.c @@ -948,8 +948,8 @@ static int sii9234_probe(struct i2c_client *client, i2c_set_clientdata(client, ctx); + ctx->bridge.odev = dev; ctx->bridge.funcs = &sii9234_bridge_funcs; - ctx->bridge.of_node = dev->of_node; drm_bridge_add(&ctx->bridge); sii9234_cable_in(ctx); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 22/26] drm/rcar-du: lvds: provide an owner .odev device for the bridge
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 3d2d3bbd1342..efda02f55c95 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -463,9 +463,9 @@ static int rcar_lvds_probe(struct platform_device *pdev) if (ret < 0) return ret; + lvds->bridge.odev = &pdev->dev; lvds->bridge.driver_private = lvds; lvds->bridge.funcs = &rcar_lvds_bridge_ops; - lvds->bridge.of_node = pdev->dev.of_node; mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); lvds->mmio = devm_ioremap_resource(&pdev->dev, mem); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/26] drm/bridge/analogix: core: specify the owner .odev of the bridge
This will become mandatory. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 2bcbfadb6ac5..c60f29216213 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1467,6 +1467,7 @@ static int analogix_dp_create_bridge(struct drm_device *drm_dev, dp->bridge = bridge; + bridge->odev = dp->dev; bridge->driver_private = dp; bridge->funcs = &analogix_dp_bridge_funcs; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/14] mm: turn on vm_fault_t type checking
On Wed, May 16, 2018 at 07:43:48AM +0200, Christoph Hellwig wrote: > Switch vm_fault_t to point to an unsigned int with __bіtwise annotations. > This both catches any old ->fault or ->page_mkwrite instance with plain > compiler type checking, as well as finding more intricate problems with > sparse. Come on, Christoph; you know better than this. This patch is completely unreviewable. Split it into one patch per maintainer tree, and in any event, the patch to convert vm_fault_t to an unsigned int should be separated from all the trivial conversions. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu: host1x: Fix compiler errors by converting to dma_addr_t
The compiler is complaining with the following errors:
drivers/gpu/host1x/cdma.c:94:48: error:
passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
drivers/gpu/host1x/cdma.c:113:48: error:
passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
The expected pointer type of the third argument to dma_alloc_wc() is
dma_addr_t but phys_addr_t is passed.
Change the phys member of struct push_buffer to be dma_addr_t so that we
pass the correct type to dma_alloc_wc().
Also check pb->mapped for non-NULL in the destroy function as that is the
right way of checking if dma_alloc_wc() was successful.
Signed-off-by: Emil Goode
---
v2: - Change the phys member type instead of adding casts.
- Check pb->mapped in the destroy function as 0 is a valid value
for dma_addr_t.
drivers/gpu/host1x/cdma.c | 2 +-
drivers/gpu/host1x/cdma.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 28541b280739..02a0b61be18f 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -51,7 +51,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer *pb)
struct host1x_cdma *cdma = pb_to_cdma(pb);
struct host1x *host1x = cdma_to_host1x(cdma);
- if (!pb->phys)
+ if (!pb->mapped)
return;
if (host1x->domain) {
diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
index 286d49386be9..446ee1a84969 100644
--- a/drivers/gpu/host1x/cdma.h
+++ b/drivers/gpu/host1x/cdma.h
@@ -44,7 +44,7 @@ struct host1x_job;
struct push_buffer {
void *mapped; /* mapped pushbuffer memory */
dma_addr_t dma; /* device address of pushbuffer */
- phys_addr_t phys; /* physical address of pushbuffer */
+ dma_addr_t phys;/* physical address of pushbuffer */
u32 fence; /* index we've written */
u32 pos;/* index to write to */
u32 size;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/26] drm/bridge: tc358767: provide an owner .odev device
The .of_node member is going away. Signed-off-by: Peter Rosin --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 0fd9cf27542c..75f93e1d0bf5 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1331,8 +1331,8 @@ static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id) tc_connector_set_polling(tc, &tc->connector); + tc->bridge.odev = dev; tc->bridge.funcs = &tc_bridge_funcs; - tc->bridge.of_node = dev->of_node; drm_bridge_add(&tc->bridge); i2c_set_clientdata(client, tc); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/14] orangefs: don't return errno values from ->fault
On Wed, May 16, 2018 at 07:43:35AM +0200, Christoph Hellwig wrote:
> + rc = orangefs_inode_getattr(file->f_mapping->host, 0, 1, STATX_SIZE);
> if (rc) {
> gossip_err("%s: orangefs_inode_getattr failed, "
> "rc:%d:.\n", __func__, rc);
> - return rc;
> + return VM_FAULT_SIGBUS;
Nope. orangefs_inode_getattr can return -ENOMEM.
> }
> return filemap_fault(vmf);
> }
> --
> 2.17.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995-draak: add HDMI output
On Tue, May 15, 2018 at 02:20:39PM +0200, Ulrich Hecht wrote: > Adds LVDS decoder, HDMI encoder and connector for Draak boards. > > Signed-off-by: Ulrich Hecht > --- > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 80 > ++ > 1 file changed, 80 insertions(+) This looks fine but I will wait to see if there are other reviews before applying. Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 0/2] Enabling content-type setting for HDMI displays.
Ping.. On Tue, 2018-05-15 at 16:59 +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content type setting property to drm_connector(part 1) > and enabled transmitting it with HDMI AVI infoframes > for i915(part 2). > > Stanislav Lisovskiy (2): > drm: content-type property for HDMI connector > i915: content-type property for HDMI connector > > Documentation/gpu/drm-kms.rst| 6 ++ > Documentation/gpu/kms-properties.csv | 1 + > drivers/gpu/drm/drm_atomic.c | 4 + > drivers/gpu/drm/drm_connector.c | 115 > +++ > drivers/gpu/drm/drm_edid.c | 8 ++ > drivers/gpu/drm/i915/intel_atomic.c | 1 + > drivers/gpu/drm/i915/intel_hdmi.c| 18 +++-- > include/drm/drm_connector.h | 15 > include/drm/drm_mode_config.h| 5 ++ > include/uapi/drm/drm_mode.h | 7 ++ > 10 files changed, 174 insertions(+), 6 deletions(-) > -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: replace license text with SPDX tags
Am Mittwoch, den 16.05.2018, 19:30 +0200 schrieb Christian Gmeiner: > Am Di., 8. Mai 2018 um 16:30 Uhr schrieb Lucas Stach > : > > This replaces the repetitive GPL-2.0 license text in code and header files > > with the SPDX tags. Generated hardware headers aren't changed, as any > > changes > > there need to be done in the upstream rnndb repository. > > Signed-off-by: Lucas Stach > > Needed some time to think about it - I am okay with this change. Thanks, I really appreciate this. > Reviewed-by: Christian Gmeiner Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105433] Unreliable Modesetting on Tonga with two DVI Screens
https://bugs.freedesktop.org/show_bug.cgi?id=105433 --- Comment #2 from Thomas R. --- Created attachment 139608 --> https://bugs.freedesktop.org/attachment.cgi?id=139608&action=edit dmesg of boot, start of X, xrandr with current staging Still persists in commit dbf4f8b16fde from Tuesday, see 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 105433] Unreliable Modesetting on Tonga with two DVI Screens
https://bugs.freedesktop.org/show_bug.cgi?id=105433 --- Comment #3 from Thomas R. --- As you can see, I still get [drm] dce_get_required_clocks_state: clocks unsupported disp_clk 681000 pix_clk 148500 Is there anything I can do to give you more information? -- 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 105433] Unreliable Modesetting on Tonga with two DVI Screens
https://bugs.freedesktop.org/show_bug.cgi?id=105433 --- Comment #4 from Michel Dänzer --- (In reply to Thomas R. from comment #3) > [drm] dce_get_required_clocks_state: clocks unsupported disp_clk 681000 > pix_clk 148500 FWIW, I get the same message with Tonga, with a single DVI connection. I haven't noticed any obvious ill effects related to it though, so it might not be relevant for this issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:topic/core-for-CI 6/9] htmldocs: kernel/kthread.c:377: warning: Function parameter or member 'exited_key' not described in '_kthread_create_on_node'
Hi Daniel, First bad commit (maybe != root cause): tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 commit: 64b3f927aacc356dd742b3a83aead21fba7e56dd [6/9] lockdep: finer-grained completion key for kthread reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:955: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.ampdu_len' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.antenna' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.tx_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'status.status_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'driver_rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'pad' not described in 'ieee80211_tx_info' include/net/mac80211.h:955: warning: Function parameter or member 'rate_driver_data' not described in 'ieee80211_tx_info' include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad line: > include/net/mac80211.h:2083: warning: bad lin
Re: [RFC PATCH] drm: Add per-plane pixel blend mode property
Op 08-05-18 om 12:34 schreef Lowry Li:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Add a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_blend.c | 95
> +
> include/drm/drm_blend.h | 6 +++
> include/drm/drm_plane.h | 7 +++
> 5 files changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..0bb6de1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -764,6 +764,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> state->src_w = val;
> } else if (property == config->prop_src_h) {
> state->src_h = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
> } else if (property == plane->rotation_property) {
> if (!is_power_of_2(val & DRM_ROTATE_MASK))
> return -EINVAL;
> @@ -826,6 +828,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
> *val = state->src_w;
> } else if (property == config->prop_src_h) {
> *val = state->src_h;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
> } else if (property == plane->rotation_property) {
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 01d936b..e4377fd 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3133,6 +3133,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane
> *plane)
> if (plane->state) {
> plane->state->plane = plane;
> plane->state->rotation = DRM_ROTATE_0;
> + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> }
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 665aafc..bb938de 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -98,6 +98,12 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined.
> *
> + * pixel blend mode:
> + * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + * It adds a blend mode for alpha blending equation selection, describing
> + * how the pixels from the current plane are composited with the
> + * background.
> + *
> * Note that all the property extensions described here apply either to the
> * plane or the CRTC (e.g. for the background color, which currently is not
> * exposed and assumed to be black).
> @@ -405,3 +411,92 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_normalize_zpos);
> +
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported modes, must include
> + *BIT(DRM_MODE_BLEND_PREMULTI)
> + *
> + * This creates a new property describing the blend mode.
> + *
> + * The property exposed to userspace is an enumeration property (see
> + * drm_property_create_enum()) called "pixel blend mode" and has the
> + * following enumeration values:
> + *
> + * DRM_MODE_BLEND_PIXEL_NONE: Blend formula that ignores the pixel alpha.
> + * "None"
> + * out.rgb = plane.alpha * pixel.rgb + (1 - plane.alpha) * bg.rgb
> + *
> + * DRM_MODE_BLEND_PREMULTI: Blend formula that assumes the pixel color values
> + * have been already pre-multiplied with the alpha
> + * channel values.
> + * "Pre-multiplied"
> + * out.rgb = plane.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * DRM_MODE_BLEND_COVERAGE: Blend formula that assumes the pixel color values
> + * have not been pre-multiplied and will do so when
> + * blending them to the background color values.
> + * "Coverage"
> + * out.rgb = plane.alpha * pixel.alpha * pixel.rgb +
> + * (1 - (plane.alpha * pixel.alpha)) * bg.rgb
> + *
> + * This property has no effect on formats with no pixel alpha, as pixel.alpha
> + * is assumed to be 1.0. If the plane does not expose the "alpha" property,
> then
> + * plane.alpha is assumed to be 1.0, otherwise, it is the value of the
> "alpha"
> +
RE: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info
On Thu, 17 May 2018, "C, Ramalingam" wrote: >> > >> +/** >> > > Drop the extra *, unless you really love it :) >> > ha ha. Actually I have added intentionally. But removing them across >> > all patches as per your suggestions. :) >> >> /** is a syntax for KDoc, so if you want to receive automatic code >> documentation you should use it and adhere to KDoc syntax > > Thanks Alexander for the information. At present I am not adding the > KDoc support, if it is not compulsory. So I will remove the /**. It's "kernel-doc" to be pedantic. No such thing as KDoc. If you use /** please stick to the exact kernel-doc format. The below is not. You'll find the documentation under Documentation/doc-guide. If you drop /** please either use free form comments or stick to the kernel-doc format. Please don't leave behind things that look eerily similar to kernel-doc comments but are not. Without /** you won't even get warnings about them. /** * mei_store_pairing_info - Store pairing info received from panel * @cldev: Pointer for mei client device * @data: Intel HW specific Data * @pairing_info: Pointer for AKE_Send_Pairing_Info * * Returns 0 on success, <0 on failure. */ BR, Jani. > > --Ram >> > > >> > >> + * mei_store_pairing_info: >> > >> + * Function to store pairing info received from panel >> > >> + * >> > >> + * @cldev : Pointer for mei client device >> > >> + * @data : Intel HW specific Data >> > >> + * @pairing_info : Pointer for AKE_Send_Pairing_Info >> > >> + * >> > >> + * Returns 0 on Success, <0 on Failure */ -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Xen-devel][RFC 1/3] xen/balloon: Allow allocating DMA buffers
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/balloon.c | 214 +++---
drivers/xen/xen-balloon.c | 2 +
include/xen/balloon.h | 11 +-
3 files changed, 188 insertions(+), 39 deletions(-)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e4db19e88ab1..e3a145aa9f29 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -415,8 +415,10 @@ static bool balloon_is_inflated(void)
return balloon_stats.balloon_low || balloon_stats.balloon_high;
}
-static enum bp_state increase_reservation(unsigned long nr_pages)
+static enum bp_state increase_reservation(unsigned long nr_pages,
+ struct page **ext_pages)
{
+ enum bp_state ret = BP_DONE;
int rc;
unsigned long i;
struct page *page;
@@ -425,32 +427,49 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
.extent_order = EXTENT_ORDER,
.domid= DOMID_SELF
};
+ xen_pfn_t *frames;
- if (nr_pages > ARRAY_SIZE(frame_list))
- nr_pages = ARRAY_SIZE(frame_list);
+ if (nr_pages > ARRAY_SIZE(frame_list)) {
+ frames = kcalloc(nr_pages, sizeof(xen_pfn_t), GFP_KERNEL);
+ if (!frames)
+ return BP_ECANCELED;
+ } else {
+ frames = frame_list;
+ }
- page = list_first_entry_or_null(&ballooned_pages, struct page, lru);
- for (i = 0; i < nr_pages; i++) {
- if (!page) {
- nr_pages = i;
- break;
- }
+ /* XENMEM_populate_physmap requires a PFN based on Xen
+* granularity.
+*/
+ if (ext_pages) {
+ for (i = 0; i < nr_pages; i++)
+ frames[i] = page_to_xen_pfn(ext_pages[i]);
+ } else {
+ page = list_first_entry_or_null(&ballooned_pages,
+ struct page, lru);
+ for (i = 0; i < nr_pages; i++) {
+ if (!page) {
+ nr_pages = i;
+ break;
+ }
- /* XENMEM_populate_physmap requires a PFN based on Xen
-* granularity.
-*/
- frame_list[i] = page_to_xen_pfn(page);
- page = balloon_next_page(page);
+ frames[i] = page_to_xen_pfn(page);
+ page = balloon_next_page(page);
+ }
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
+ set_xen_guest_handle(reservation.extent_start, frames);
reservation.nr_extents = nr_pages;
rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
- if (rc <= 0)
- return BP_EAGAIN;
+ if (rc <= 0) {
+ ret = BP_EAGAIN;
+ goto out;
+ }
for (i = 0; i < rc; i++) {
- page = balloon_retrieve(false);
+ if (ext_pages)
+ page = ext_pages[i];
+ else
+ page = balloon_retrieve(false);
BUG_ON(page == NULL);
#ifdef CONFIG_XEN_HAVE_PVMMU
@@ -463,14 +482,14 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
unsigned long pfn = page_to_pfn(page);
- set_phys_to_machine(pfn, frame_list[i]);
+ set_phys_to_machine(pfn, frames[i]);
/* Link back into the page tables if not highmem. */
if (!PageHighMem(page)) {
int ret;
ret = HYPERVISOR_update_va_mapping(
(unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
+ mfn_pte(frames[i], PAGE_KERNEL),
0);
BUG_ON(ret);
}
@@ -478,15 +497,22 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
#endif
/* Relinquish the page back to the allocator. */
- __free_reserved_page(page);
+ if (!ext_pages)
+ __free_reserved_page(page);
}
- balloon_stats.current_pages += rc;
+ if (!ext_pages)
+ balloon_stats.current_pages += rc;
- return BP_DONE;
+out:
+ if (frames != frame_list)
+ kfree(frames);
+
+ return ret;
}
-static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
+static enum bp_state decrease_reservation(unsigned long n
[Xen-devel][RFC 0/3] dma-buf support for gntdev
From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and ballooning in/out the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any other memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first two patches in this series solve #1 and the last one is for #2. The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 Oleksandr Andrushchenko (3): xen/balloon: Allow allocating DMA buffers xen/grant-table: Extend API to work with DMA buffers xen/gntdev: Add support for Linux dma buffers drivers/xen/balloon.c | 214 +++-- drivers/xen/gntdev.c | 954 +- drivers/xen/grant-table.c | 49 ++ drivers/xen/xen-balloon.c | 2 + include/uapi/xen/gntdev.h | 101 include/xen/balloon.h | 11 +- include/xen/gntdev_exp.h | 23 + include/xen/grant_table.h | 7 + 8 files changed, 1310 insertions(+), 51 deletions(-) create mode 100644 include/xen/gntdev_exp.h -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Xen-devel][RFC 3/3] xen/gntdev: Add support for Linux dma buffers
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 954 +-
include/uapi/xen/gntdev.h | 101
include/xen/gntdev_exp.h | 23 +
3 files changed, 1066 insertions(+), 12 deletions(-)
create mode 100644 include/xen/gntdev_exp.h
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9510f228efe9..0ee88e193362 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -4,6 +4,8 @@
* Device for accessing (in user-space) pages that have been granted by other
* domains.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
*
@@ -37,6 +39,9 @@
#include
#include
+#include
+#include
+
#include
#include
#include
@@ -61,16 +66,39 @@ static atomic_t pages_mapped = ATOMIC_INIT(0);
static int use_ptemod;
#define populate_freeable_maps use_ptemod
+#ifndef GRANT_INVALID_REF
+/*
+ * Note on usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF 0
+#endif
+
struct gntdev_priv {
/* maps with visible offsets in the file descriptor */
struct list_head maps;
/* maps that are not visible; will be freed on munmap.
* Only populated if populate_freeable_maps == 1 */
struct list_head freeable_maps;
+ /* List of dma-bufs. */
+ struct list_head dma_bufs;
/* lock protects maps and freeable_maps */
struct mutex lock;
struct mm_struct *mm;
struct mmu_notifier mn;
+
+ /* Private data of the hyper DMA buffers. */
+
+ struct device *dev;
+ /* List of exported DMA buffers. */
+ struct list_head dmabuf_exp_list;
+ /* List of wait objects. */
+ struct list_head dmabuf_exp_wait_list;
+ /* List of imported DMA buffers. */
+ struct list_head dmabuf_imp_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex dmabuf_lock;
};
struct unmap_notify {
@@ -95,10 +123,65 @@ struct grant_map {
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
unsigned long pages_vm_start;
+
+ /*
+* All the fields starting with dmabuf_ are only valid if this
+* mapping is used for exporting a DMA buffer.
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ /* Flags used to create this DMA buffer: GNTDEV_DMABUF_FLAG_XXX. */
+ bool dmabuf_flags;
+ /* Virtual/CPU address of the DMA buffer. */
+ void *dmabuf_vaddr;
+ /* Bus address of the DMA buffer. */
+ dma_addr_t dmabuf_bus_addr;
+};
+
+struct hyper_dmabuf {
+ struct gntdev_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
+ union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+ struct grant_map *map;
+ } exp;
+ struct {
+ /* Granted references of the imported buffer. */
+ grant_ref_t *refs;
+ /* Scatter-gather table of the imported buffer. */
+ struct sg_table *sgt;
+ /* dma-buf attachment of the imported buffer. */
+ struct dma_buf_attachment *attach;
+ } imp;
+ } u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct hyper_dmabuf_wait_obj {
+ struct list_head next;
+ struct hyper_dmabuf *hyper_dmabuf;
+ struct completion completion;
+};
+
+struct hyper_dambuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
};
static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
+static struct miscdevice gntdev_miscdev;
+
/* -- */
static void gntdev_print_maps(struct gntdev_priv *priv,
@@ -120,8 +203,17 @@ static void gntdev_free_map(struct grant_map *map)
if (map == NULL)
return;
- if (map->pages)
+ if (map->dmabuf_vaddr) {
+ bool coherent = map->dmabuf_flags &
+ GNTDEV_DMABUF_FLAG_DMA_COHERENT;
+
+ gnttab_dma_free_pages(gntdev_miscdev.this_device,
+ coherent, map->count, map->pages,
+ map->dmabuf_vaddr, map->dmabuf_bus_addr);
+ } else if (map->pages) {
gnttab_free_pages(map->count, map->pages);
+ }
+
kfree(map->pages);
kfre
[Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 49 +++
include/xen/grant_table.h | 7 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e1dbcc..c27bcc420575 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -729,6 +729,55 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL(gnttab_free_pages);
+int gnttab_dma_alloc_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void **vaddr, dma_addr_t *dev_bus_addr)
+{
+ int i;
+ int ret;
+
+ ret = alloc_dma_xenballooned_pages(dev, coherent, nr_pages, pages,
+ vaddr, dev_bus_addr);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < nr_pages; i++) {
+#if BITS_PER_LONG < 64
+ struct xen_page_foreign *foreign;
+
+ foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
+ if (!foreign) {
+ gnttab_dma_free_pages(dev, flags, nr_pages, pages,
+ *vaddr, *dev_bus_addr);
+ return -ENOMEM;
+ }
+ set_page_private(pages[i], (unsigned long)foreign);
+#endif
+ SetPagePrivate(pages[i]);
+ }
+ return 0;
+}
+EXPORT_SYMBOL(gnttab_dma_alloc_pages);
+
+void gnttab_dma_free_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void *vaddr, dma_addr_t dev_bus_addr)
+{
+ int i;
+
+ for (i = 0; i < nr_pages; i++) {
+ if (PagePrivate(pages[i])) {
+#if BITS_PER_LONG < 64
+ kfree((void *)page_private(pages[i]));
+#endif
+ ClearPagePrivate(pages[i]);
+ }
+ }
+ free_dma_xenballooned_pages(dev, coherent, nr_pages, pages,
+ vaddr, dev_bus_addr);
+}
+EXPORT_SYMBOL(gnttab_dma_free_pages);
+
/* Handling of paged out grant targets (GNTST_eagain) */
#define MAX_DELAY 256
static inline void
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 34b1379f9777..20ee2b5ba965 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -195,6 +195,13 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_dma_alloc_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void **vaddr, dma_addr_t *dev_bus_addr);
+void gnttab_dma_free_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void *vaddr, dma_addr_t dev_bus_addr);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106548 Bug ID: 106548 Summary: Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAP I Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: kishore.kadiy...@intel.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 139610 --> https://bugs.freedesktop.org/attachment.cgi?id=139610&action=edit GL_GPU_FREQ_OVERRIDE_MDAPI Acceptance failure On Ubuntu 18.04, with latest MESA + MDAPI from here https://gerrit-gfx.intel.com/#/admin/projects/gfx/core/metrics-discovery The testacceptance is failing for GL_GPU_FREQ_OVERRIDE_MDAPI -- 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 106549] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106549 Bug ID: 106549 Summary: Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAP I Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: kishore.kadiy...@intel.com QA Contact: dri-devel@lists.freedesktop.org On Ubuntu 18.04, with latest MESA + MDAPI from here https://gerrit-gfx.intel.com/#/admin/projects/gfx/core/metrics-discovery The testacceptance is failing for GL_GPU_FREQ_OVERRIDE_MDAPI -- 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 106549] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106549 --- Comment #1 from Kishore --- I have tried on default kernel version on ubuntu 18.04 is 4.15-rc20. and also on the drm-tip, i can see the failure -- 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/scheduler: Remove obsolete spinlock.
Reviewed-by: Christian König
Am 17.05.2018 um 04:32 schrieb zhoucm1:
Yes, every thing is clear, Acked-by: Chunming Zhou
On 2018年05月16日 23:33, Andrey Grodzovsky wrote:
This spinlock is superfluous, any call to drm_sched_entity_push_job
should already be under a lock together with matching drm_sched_job_init
to match the order of insertion into queue with job's fence seqence
number.
v2:
Improve patch description.
Add functions documentation describing the locking considerations
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 15 ++-
include/drm/gpu_scheduler.h | 1 -
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 1f1dd70..80dd66c 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -140,7 +140,6 @@ int drm_sched_entity_init(struct
drm_gpu_scheduler *sched,
entity->last_scheduled = NULL;
spin_lock_init(&entity->rq_lock);
- spin_lock_init(&entity->queue_lock);
spsc_queue_init(&entity->job_queue);
atomic_set(&entity->fence_seq, 0);
@@ -414,6 +413,10 @@ drm_sched_entity_pop_job(struct drm_sched_entity
*entity)
*
* @sched_job The pointer to job required to submit
*
+ * Note: To guarantee that the order of insertion to queue matches
+ * the job's fence sequence number this function should be
+ * called with drm_sched_job_init under common lock.
+ *
* Returns 0 for success, negative error code otherwise.
*/
void drm_sched_entity_push_job(struct drm_sched_job *sched_job,
@@ -424,11 +427,8 @@ void drm_sched_entity_push_job(struct
drm_sched_job *sched_job,
trace_drm_sched_job(sched_job, entity);
- spin_lock(&entity->queue_lock);
first = spsc_queue_push(&entity->job_queue,
&sched_job->queue_node);
- spin_unlock(&entity->queue_lock);
-
/* first job wakes up scheduler */
if (first) {
/* Add the entity to the run queue */
@@ -594,7 +594,12 @@ void drm_sched_job_recovery(struct
drm_gpu_scheduler *sched)
}
EXPORT_SYMBOL(drm_sched_job_recovery);
-/* init a sched_job with basic field */
+/**
+ * Init a sched_job with basic field
+ *
+ * Note: Refer to drm_sched_entity_push_job documentation
+ * for locking considerations.
+ */
int drm_sched_job_init(struct drm_sched_job *job,
struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity,
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 350a62c..683eb65 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -56,7 +56,6 @@ struct drm_sched_entity {
spinlock_t rq_lock;
struct drm_gpu_scheduler *sched;
- spinlock_t queue_lock;
struct spsc_queue job_queue;
atomic_t fence_seq;
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] ARM: dts: Restructure Vexpress motherboard includes
On Wed, May 9, 2018 at 6:44 PM, Sudeep Holla wrote: > Please copy me and Lorenzo also in future. > Applied now(with typo in hierarchy fixed), thanks. Sure thing, sorry I didn't realize you were working actively with the Versatile Express, glad to see this :) I will send you my Versatile Express transition to DRI/DRM series today since my Pl111 work for Vexpress is now pending in linux-next, if I can find the right commits to base it on, do you have a Vexpress git branch somewhere? Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199749] New: amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 Bug ID: 199749 Summary: amdgpu on Ryzen 2400G freeze randomly Product: Drivers Version: 2.5 Kernel Version: 4.17 RC2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: muella...@gmail.com Regression: No System video freezes randomly during the day while working on the system normally (no 3D). Logfile shows only: May 17 11:18:00 ws01 kernel: [11831.268044] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, last signaled seq=2081253, last emitted seq=2081256 May 17 11:18:00 ws01 kernel: [11831.268051] [drm] No hardware hang detected. Did some blocks stall? If I can assist any further, please tell. -- 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 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #1 from Chris Wilson --- *** Bug 106549 has been marked as a duplicate of this bug. *** -- 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
[PULL] drm-intel-fixes
Hi Dave, Nothing too big this time either, a missing W/A added and fix for rare HW race in addition to early IOCTL error check. We got kthread_park related splats to CI from -rc5, so the results are to be taken with a pinch of salt. The fix to factor around it is bit too much for -fixes and there should be no user impact so I'm leaving it for -next-fixes. I'm still attempting to get an ack for the ICL stolen detection patches from Ingo, as lacking that may cause random memory corruption as previously discussed in CNL case. Regards, Joonas drm-intel-fixes-2018-05-17: - Userptr IOCTL zero size check (Matt) - Two hardware quirk fixes (Michel & Chris) The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f: Linux 4.17-rc5 (2018-05-13 16:15:17 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-05-17 for you to fetch changes up to b579f924a90f42fa561afd8201514fc216b71949: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (2018-05-16 11:21:09 +0300) - Userptr IOCTL zero size check (Matt) - Two hardware quirk fixes (Michel & Chris) Chris Wilson (1): drm/i915/execlists: Use rmb() to order CSB reads Matthew Auld (1): drm/i915/userptr: reject zero user_size Michel Thierry (1): drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk drivers/gpu/drm/i915/i915_gem_userptr.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_engine_cs.c | 4 drivers/gpu/drm/i915/intel_lrc.c| 1 + 4 files changed, 11 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
On 16/05/18 19:23, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
(bus address [0x0010-0x1fff])
pci :02:00.0: reg 0x10: [mem 0x8011e00-0x8011eff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e00
efifb: framebuffer at 0x1e00, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya
---
drivers/video/fbdev/efifb.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..feef02b 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_host_bridge *bridge;
+ struct resource_entry *window;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,27 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ bridge = pci_find_host_bridge(dev->bus);
+ if (!bridge)
+ return;
+
+ resource_list_for_each_entry(window, &bridge->windows) {
+ phys_addr_t win_start;
+ phys_addr_t win_end;
+ size_t win_size;
+
+ if (resource_type(window->res) != IORESOURCE_MEM)
+ continue;
+
+ win_start = window->res->start - window->offset;
+ win_end = window->res->end - window->offset;
+ win_size = window->res->end - window->res->start + 1;
+ if (win_start <= base && win_end >= base + win_size - 1) {
+ base += window->offset;
+ break;
+ }
+ }
+
Is this not pretty much just pcibios_bus_to_resource()?
Robin.
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106549] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106549 Chris Wilson changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Chris Wilson --- *** This bug has been marked as a duplicate of bug 106548 *** -- 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 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #2 from Chris Wilson --- /home/kk/workspace/gpa_extensions/src/GfxDrvDriverAcceptanceTest/test_GfxDrv_DriverAcceptanceQuery.cpp:1438: Failure Value of: pOverride->SetOverride(&freqParam, sizeof(freqParam)) Actual: 43 Expected: CC_OK Which is: 0 Looks like the test case needs improving for starters. -- 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 21/40] drm/i915: Define Intel HDCP2.2 registers
On Wednesday 09 May 2018 08:29 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH v3 21/40] drm/i915: Define Intel HDCP2.2 registers
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6a8c0ee7df1..f04ad3c15abd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8649,6 +8649,38 @@ enum skl_power_gate {
#define HDCP_STATUS_CIPHER BIT(16)
#define HDCP_STATUS_FRAME_CNT(x) ((x >> 8) & 0xff)
+/* HDCP2.2 Registers */
+#define _PORTA_HDCP2_BASE 0x66800
+#define _PORTB_HDCP2_BASE 0x66500
+#define _PORTC_HDCP2_BASE 0x66600
+#define _PORTD_HDCP2_BASE 0x66700
+#define _PORTE_HDCP2_BASE 0x66A00
+#define _PORTF_HDCP2_BASE 0x66900
+#define _PORT_HDCP2_BASE(port, x) _MMIO(_PICK(port, \
+ _PORTA_HDCP2_BASE, \
+ _PORTB_HDCP2_BASE, \
+ _PORTC_HDCP2_BASE, \
+ _PORTD_HDCP2_BASE, \
+ _PORTE_HDCP2_BASE, \
+ _PORTF_HDCP2_BASE) + x)
+
+#define HDCP2_AUTH_DDI(port) _PORT_HDCP2_BASE(port,
0x98)
+#define AUTH_LINK_AUTHENTICATED BIT(31)
+#define AUTH_LINK_TYPE BIT(30)
+#define AUTH_FORCE_CLR_INPUTCTR BIT(19)
+#define AUTH_CLR_KEYSBIT(18)
+
+#define HDCP2_CTR_DDI(port)_PORT_HDCP2_BASE(port, 0xB0)
Rename it to HDCP2_CTL_DDI to match with spec and avoid any ambiguity.
I will rename it as CTL.
--Ram
+#define CTL_LINK_ENCRYPTION_REQ BIT(31)
+
+#define HDCP2_STATUS_DDI(port) _PORT_HDCP2_BASE(port,
0xB4)
+#define STREAM_ENCRYPTION_STATUS_A BIT(31)
+#define STREAM_ENCRYPTION_STATUS_B BIT(30)
+#define STREAM_ENCRYPTION_STATUS_C BIT(29)
+#define LINK_TYPE_STATUS BIT(22)
+#define LINK_AUTH_STATUS BIT(21)
+#define LINK_ENCRYPTION_STATUS BIT(20)
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
--
2.7.4
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI
https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #3 from Vyacheslav Bogdanov --- (In reply to Chris Wilson from comment #2) > /home/kk/workspace/gpa_extensions/src/GfxDrvDriverAcceptanceTest/ > test_GfxDrv_DriverAcceptanceQuery.cpp:1438: Failure > Value of: pOverride->SetOverride(&freqParam, sizeof(freqParam)) > Actual: 43 > Expected: CC_OK > Which is: 0 > > Looks like the test case needs improving for starters. Could you please explain? The function call fails, test checks that. Syslog typically provides more logs that will help understanding the cause of the failure. -- 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 22/40] drm/i915: Wrappers for mei HDCP2.2 services
On Wednesday 09 May 2018 08:40 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH v3 22/40] drm/i915: Wrappers for mei HDCP2.2
services
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
v3:
cldev is moved from mei_hdcp_data to hdcp.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 194
++
1 file changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1cca4f349064..b4d56b21cf9b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -10,10 +10,13 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
+#define GET_MEI_DDI_INDEX(port)(((port) == PORT_A) ? DDI_A : \
+(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -
817,3 +820,194 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
mutex_unlock(&hdcp->hdcp_mutex);
return ret;
}
+
+static int
+hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
+*ake_data) {
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ struct intel_connector *connector = container_of(hdcp,
+struct intel_connector,
+hdcp);
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ if (data->port == INVALID_PORT && connector->encoder)
+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
I believe caller should provide valid port and this should fail if port
received is invalid instead of
retrieving it here.
Agreed. But at the initialization of mei_hdcp_data, if the encoder is
not initialized, data->port will be uninitialized (invalid).
So in that case at the start of the hdcp authentication we initialize
the port. May be I am bit paranoid here!
But on all other wrappers port needs to be valid.
--Ram
+
+ /* Clear ME FW instance for the port, just incase */
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data); }
+
+static int hdcp2_close_mei_session(struct intel_hdcp *hdcp) {
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+
+ if (!hdcp->cldev || data->port == INVALID_PORT)
This is what I was saying for above.
+ return -EINVAL;
+
+ return mei_close_hdcp_session(hdcp->cldev, data); }
+
+static int
+hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
+ paired, ek_pub_km, msg_sz);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_hprime *rx_hprime) {
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_store_paring_info(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_pairing_info *pairing_info) {
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init
+*lc_init) {
+ struct mei_hdcp_data *data = &hdcp->mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_initiate_locality_check(hdcp->cldev, data, lc_init);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+stat
Query about INTEL modifiers referred in intel_display.c
Hi,
I was going through drivers/gpu/drm/i915/intel_display.c to get an
understanding about how framebuffer modifiers are used in the drm
subsystem.
I could see the following in intel_framebuffer_init(),
(added in commit 2e2adb0573)
<< some code >>
switch (mode_cmd->modifier[0]) {
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
switch (mode_cmd->pixel_format) {
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
break;
default:
DRM_DEBUG_KMS("RC supported only with RGB formats\n");
goto err;
}
<< some code >>
And I see the following intel_primary_plane_format_mod_supported() -->
skl_mod_supported()
(added in commit 714244e280)
<< some code >>
switch (format) {
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
modifier == I915_FORMAT_MOD_Y_TILED_CCS)
return true;
<< some code >>
Is it a case of duplicacy? If we are checking for valid
combination of formats and modifiers in intel_framebuffer_init(), then why do
we
need to check it again in skl_mod_supported()?
Can we just check the valid combination only in
skl_mod_supported() and not in intel_framebuffer_init() ?
Please let me know if I misunderstood something.
Thanks,
Ayan Kumar Halder
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.
Hi Michele and others, I am trying to implement the approach bellow to resolve AMDGPU's hang when commands are stuck in pipe during process exit. I noticed that once I implemented the file_operation.flush callback then during run of X, i see the flush callback gets called not only for Xorg process but for other processes such as 'xkbcomp' and even 'sh', it seems like Xorg passes his FDs to children, Christian mentioned he remembered a discussion to always set FD_CLOEXEC flag when opening the hardware device file, so we suspect a bug in Xorg with regard to this behavior. Any advise on this would be very helpful. Andrey On 05/02/2018 07:48 AM, Christian König wrote: I suggest the following approach: 1. Implement the flush callback and call the function to wait for the scheduler to push everything to the hardware (maybe rename the scheduler function to flush as well). 2. Change the scheduler to test for PF_EXITING, if it's set use wait_event_timeout() if it isn't set use wait_event_killable(). When the wait times out or is killed set a flag so that the _fini function knows that. Alternatively you could cleanup the _fini function to work in all cases, e.g. both when there are still jobs on the queue and when the queue is empty. For this you need to add something like a struct completion to the main loop to remove this start()/stop() of the kernel thread. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/tegra: Acquire a reference to the IOVA cache
On Thu, May 17, 2018 at 01:53:23PM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 09:57, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> > sure that this cache is available, obtain a reference to it and release
> > the reference when the cache is no longer needed.
> >
> > On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> > that reference and never releases it. On 32-bit ARM, however, the DMA
> > mapping API doesn't do that, so allocation of IOVA nodes fails.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/gpu/drm/tegra/drm.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > index 4a696fa274a3..0540b0741df6 100644
> > --- a/drivers/gpu/drm/tegra/drm.c
> > +++ b/drivers/gpu/drm/tegra/drm.c
> > @@ -115,6 +115,10 @@ static int tegra_drm_load(struct drm_device *drm,
> > unsigned long flags)
> > goto free;
> > }
> >
> > + err = iova_cache_get();
> > + if (err < 0)
> > + goto domain;
> > +
> > geometry = &tegra->domain->geometry;
> > gem_start = geometry->aperture_start;
> > gem_end = geometry->aperture_end - CARVEOUT_SZ;
> > @@ -205,11 +209,12 @@ static int tegra_drm_load(struct drm_device *drm,
> > unsigned long flags)
> > tegra_drm_fb_free(drm);
> > config:
> > drm_mode_config_cleanup(drm);
> > -
> > +domain:
> > if (tegra->domain) {
> > mutex_destroy(&tegra->mm_lock);
> > drm_mm_takedown(&tegra->mm);
> > put_iova_domain(&tegra->carveout.domain);
> > + iova_cache_put();
>
> I've spotted that this ^ is incorrect. This will put the iova_cache without
> getting it if iova_cache_get() failed.
Good catch, updated the patch with your suggestion.
Thanks,
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral
On Thu, May 17, 2018 at 4:47 AM, wrote: > On 2018-05-08 15:55, kgu...@codeaurora.org wrote: >> >> On 2018-05-07 21:50, Bjorn Andersson wrote: >>> >>> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: >>> WLED4 peripheral is present on some PMICs like pmi8998 and pm660l. It has a different register map and also configurations are different. Add support for it. >>> >>> Several things are going on in this patch, it needs to be split to >>> not hide the functional changes from the structural/renames. >>> >> Ok. I will split it in the next series. Signed-off-by: Kiran Gunda --- .../bindings/leds/backlight/qcom-wled.txt | 172 - drivers/video/backlight/qcom-wled.c| 749 +++-- 2 files changed, 696 insertions(+), 225 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt index fb39e32..0ceffa1 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt @@ -1,30 +1,129 @@ Binding for Qualcomm Technologies, Inc. WLED driver -Required properties: -- compatible: should be "qcom,pm8941-wled" -- reg: slave address - -Optional properties: -- default-brightness: brightness value on boot, value from: 0-4095 - default: 2048 -- label: The name of the backlight device -- qcom,cs-out: bool; enable current sink output -- qcom,cabc: bool; enable content adaptive backlight control -- qcom,ext-gen: bool; use externally generated modulator signal to dim -- qcom,current-limit: mA; per-string current limit; value from 0 to 25 - default: 20mA -- qcom,current-boost-limit: mA; boost current limit; one of: - 105, 385, 525, 805, 980, 1260, 1400, 1680 - default: 805mA -- qcom,switching-freq: kHz; switching frequency; one of: - 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, - 1600, 1920, 2400, 3200, 4800, 9600, - default: 1600kHz -- qcom,ovp: V; Over-voltage protection limit; one of: - 27, 29, 32, 35 - default: 29V -- qcom,num-strings: #; number of led strings attached; value from 1 to 3 - default: 2 +WLED (White Light Emitting Diode) driver is used for controlling display +backlight that is part of PMIC on Qualcomm Technologies, Inc. reference +platforms. The PMIC is connected to the host processor via SPMI bus. + +- compatible + Usage:required + Value type: + Definition: should be "qcom,pm8941-wled" or "qcom,pmi8998-wled". + or "qcom,pm660l-wled". >>> >>> >>> Better written as >>> >>> should be one of: >>> X >>> Y >>> Z >>> >> Will do it in the next series. + +- reg + Usage:required + Value type: + Definition: Base address of the WLED modules. + +- interrupts + Usage:optional + Value type: + Definition: Interrupts associated with WLED. Interrupts can be + specified as per the encoding listed under + Documentation/devicetree/bindings/spmi/ + qcom,spmi-pmic-arb.txt. >>> >>> >>> Better to describe that this should be the "short" and "ovp" interrupts >>> in this property than in the interrupt-names. >>> >> Ok. I will do it in the next series. + +- interrupt-names + Usage:optional + Value type: + Definition: Interrupt names associated with the interrupts. + Must be "short" and "ovp". The short circuit detection + is not supported for PM8941. + +- label + Usage:required + Value type: + Definition: The name of the backlight device + +- default-brightness + Usage:optional + Value type: + Definition: brightness value on boot, value from: 0-4095 + Default: 2048 + +- qcom,current-limit + Usage:optional + Value type: + Definition: uA; per-string current limit >>> >>> >>> You can't change unit on an existing property, that breaks any existing >>> dts using the qcom,pm8941-wled compatible. >>> >> + value: + For pm8941: from 0 to 25000 with 5000 ua step + Default 2 uA + For pmi8998: from 0 to 3 with 5000 ua step +
Re: [Intel-gfx] Query about INTEL modifiers referred in intel_display.c
On Thu, May 17, 2018 at 11:55:47AM +0100, Ayan Halder wrote:
> Hi,
>
> I was going through drivers/gpu/drm/i915/intel_display.c to get an
> understanding about how framebuffer modifiers are used in the drm
> subsystem.
> I could see the following in intel_framebuffer_init(),
> (added in commit 2e2adb0573)
>
> << some code >>
> switch (mode_cmd->modifier[0]) {
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> switch (mode_cmd->pixel_format) {
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_ABGR:
> case DRM_FORMAT_XRGB:
> case DRM_FORMAT_ARGB:
> break;
> default:
> DRM_DEBUG_KMS("RC supported only with RGB formats\n");
> goto err;
> }
> << some code >>
>
> And I see the following intel_primary_plane_format_mod_supported() -->
> skl_mod_supported()
> (added in commit 714244e280)
>
> << some code >>
> switch (format) {
>
> case DRM_FORMAT_XRGB:
>
> case DRM_FORMAT_XBGR:
>
> case DRM_FORMAT_ARGB:
>
> case DRM_FORMAT_ABGR:
>
> if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
>
> modifier == I915_FORMAT_MOD_Y_TILED_CCS)
>
> return true;
> << some code >>
>
> Is it a case of duplicacy? If we are checking for valid
> combination of formats and modifiers in intel_framebuffer_init(), then why do
> we
> need to check it again in skl_mod_supported()?
>
> Can we just check the valid combination only in
> skl_mod_supported() and not in intel_framebuffer_init() ?
The check in intel_framebuffer_init() is there to prevent the creation
of framebuffers that can't be scanned out by any plane. In theory we
don't have to do that, but I think it's a good idea in case userspace
just blindly probes which format+modifier combos are supported. And in
fact, before we got the IN_FORMATS property on planes blind probing
was the only way to discover the supported modifiers.
That said, I do want to eliminate that code from
intel_framebuffer_init() and replace it with a piece of generic code
that simply goes through all the planes and checks whether any of
them support the requested format+modifier combo. I've posted some
patches for that, but there were some unforseen complications due
to how some other drivers want to use modifiers. The last patch
I posted on the topic https://patchwork.freedesktop.org/patch/211306/
should help us proceed but it didn't get reviewed so we're stuck
until I can nudge it forward somehow.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication
On Monday 14 May 2018 02:38 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater
authentication
Implements the HDCP2.2 repeaters authentication steps such as verifying the
downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 135
++
1 file changed, 135 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ee9b7519fe73..d70320da85e4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1145,6 +1145,135 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+/*
+ * Lib endianness functions are aligned for 16/32/64 bits. Since here
+sequence
+ * num is 24bits developed a small conversion function.
+ */
+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)
This function is already defined and used in mei layer. Define this in some
common header file and use instead of duplicating it here. May be in below
file:
Sure.
--Ram
+{
+ u32 index;
+
+ if (dest != NULL && dst_sz != 0) {
+ for (index = 0; index < dst_sz && index < sizeof(u32);
+index++) {
+ dest[dst_sz - index - 1] = src[index];
+ }
+ }
+}
+
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector
+*connector) {
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ reverse_endianness(msgs.stream_manage.seq_num_m,
HDCP_2_2_SEQ_NUM_LEN,
+ (u8 *)&hdcp->seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = __swab16(1);
+
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ msgs.stream_manage.streams[0].stream_id = 0;
+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+ /* Send it to Repeater */
+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.stream_manage,
+ sizeof(msgs.stream_manage));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port,
HDCP_2_2_REP_STREAM_READY,
+&msgs.stream_ready,
sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(hdcp, &msgs.stream_ready);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_m++;
+
+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ return -1;
+ }
Leave a blank line.
+ return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector
+*connector) {
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ union {
+ struct hdcp2_rep_send_receiverid_list recvid_list;
+ struct hdcp2_rep_send_ack rep_ack;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
+ uint8_t *rx_info;
+ uint32_t seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port,
HDCP_2_2_REP_SEND_RECVID_LIST,
+&msgs.recvid_list, sizeof(msgs.recvid_list));
+ if (ret < 0)
+ return ret;
+
+ rx_info = msgs.recvid_list.rx_info;
+
+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+ return -1;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ reverse_endianness((u8 *)&seq_num_v, HDCP_2_2_SEQ_NUM_LEN,
+ msgs.recvid_list.seq_num_v);
+
+ if (seq_num_v < hdcp->seq_num_v) {
+ /* Roll over of the seq
Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer
On 30 March 2018 at 15:11, Daniel Stone wrote: > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > can remove it. > > Signed-off-by: Daniel Stone > Cc: Sandy Huang > Cc: Heiko Stübner Ping? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
Implements the enable and disable functions for HDCP2.2 encryption of the
PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 54
+++
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index d70320da85e4..91cac643f083 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim) @@ -
1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct intel_connector
*connector)
return ret;
}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector) {
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
Print a message saying "Encryption Already enabled" .
It doesn't serve any purpose uma. why do we need this?
+ return 0;
+
+ if (hdcp->hdcp_shim->toggle_signalling)
Check for "hdcp->hdcp_shim" as well.
Without hdcp_shim structure, we wont reach here.
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+
+ /* Link is Authenticated. Now set for Encryption */
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) |
+ CTL_LINK_ENCRYPTION_REQ);
+ }
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS,
+ LINK_ENCRYPTION_STATUS,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
Print a message in case of timeout.
Yes. Since this timeout is unexpected, debug msg would help.
+ return ret;
+}
+
+static int hdcp2_disable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS))
Put a info message saying "Already Disabled" .
I feel this msg wont help uma.
+ return 0;
+
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) &
~CTL_LINK_ENCRYPTION_REQ);
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS, 0x0,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
If this times out, do we still need to toggle the signalling ?
As per the Bspec Encryption will stop in a frame time. So 32mSec should
be adequate.
So we need to toggle the hdcp signaling so that panel will know that
unencrypted data is expected.
+
+ if (hdcp->hdcp_shim->toggle_signalling)
Check for validity of " hdcp->hdcp_shim".
hdcp_shim will be valid at this point. but where as toggling function is
only for hdmi.
--Ram
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+ return ret;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer
Hi Thierry, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since tegra_fb is now the same as drm_framebuffer, we can just replace > the type completely. > > Signed-off-by: Daniel Stone > Cc: Thierry Reding > Cc: linux-te...@vger.kernel.org Did this still need some more testing, or is it OK to apply? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer
Hi Rob, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle function the same as the GEM framebuffer helper, we > can reuse that. I didn't get to removing msm_framebuffer completely, because the cleanup was a bit too painful. It still seems like a useful cleanup though - could you please take a look? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer
On 30 March 2018 at 21:53, Sebastian Reichel wrote: > On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote: >> drm_framebuffer already holds per-plane pitch and offsets, which is >> filled out for us when we create the framebuffer. Nuke our local copy in >> the plane struct. >> >> Signed-off-by: Daniel Stone >> Cc: Tomi Valkeinen > > Reviewed-by: Sebastian Reichel Thanks Sebastian! Tomi, are you planning to take this through drm-tip if you're happy with it? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer
Hi CK, Philipp, On 30 March 2018 at 15:11, Daniel Stone wrote: > Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can > just delete it. Did you get a chance to look at these three patches for Mediatek? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer
Hi Russell, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse those. Ping - have you had a chance to look at this? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer
Hi Ville, On 23 March 2018 at 14:49, Daniel Stone wrote: > On 23 March 2018 at 14:42, Ville Syrjälä > wrote: >> Hmm. I'm thinking we can stick to the single reference per fb. >> IIRC this counter is there just to prevent changes of the obj >> tiling mode as long as any fb exists that uses the object. So >> doesn't actually matter how many planes the fb has. >> >> Naturally the story would be slightly difference if we supported >> fbs using multiple different BOs, as each BO would need to get its >> framebuffer_references adjusted. > > Yeah, fair enough. It looks a little bit weird (perhaps deserving of a > comment) there. The reason to do that was just the general principle > of having one reference per object pointer, especially when other > drivers (ones which can have separate BOs in a single logical image) > will and do refcount them separately. Having different refcounting > semantics in shared structures depending on which driver is in use > makes me itchy. Absent any other comment, I've dropped this change and will keep a single framebuffer_reference[s] for v2. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Introduce tracepoints for CL execution.
This has been useful for debugging the window movement lag in X11, and
I have patches to sysprof that watch these to produce nice
visualizations.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_gem.c | 4 +++
drivers/gpu/drm/vc4/vc4_irq.c | 4 +++
drivers/gpu/drm/vc4/vc4_trace.h | 58 +
3 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 7910b9acedd6..7e98eb93bcc0 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -479,6 +479,7 @@ vc4_submit_next_bin_job(struct drm_device *dev)
*/
if (exec->ct0ca != exec->ct0ea) {
submit_cl(dev, 0, exec->ct0ca, exec->ct0ea);
+ trace_vc4_submit_cl(dev, exec->seqno, false);
} else {
struct vc4_exec_info *next;
@@ -513,6 +514,7 @@ vc4_submit_next_render_job(struct drm_device *dev)
vc4_flush_texture_caches(dev);
submit_cl(dev, 1, exec->ct1ca, exec->ct1ea);
+ trace_vc4_submit_cl(dev, exec->seqno, true);
}
void
@@ -1124,6 +1126,8 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct dma_fence *in_fence;
int ret = 0;
+ trace_vc4_submit_cl_begin(dev);
+
if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
VC4_SUBMIT_CL_FIXED_RCL_ORDER |
VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 4cd2ccfe15f4..d331ad136ae8 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -47,6 +47,7 @@
#include "vc4_drv.h"
#include "vc4_regs.h"
+#include "vc4_trace.h"
#define V3D_DRIVER_IRQS (V3D_INT_OUTOMEM | \
V3D_INT_FLDONE | \
@@ -109,6 +110,7 @@ vc4_irq_finish_bin_job(struct drm_device *dev)
if (!exec)
return;
+ trace_vc4_finish_cl(dev, exec->seqno, false);
vc4_move_job_to_render(dev, exec);
next = vc4_first_bin_job(vc4);
@@ -147,6 +149,8 @@ vc4_irq_finish_render_job(struct drm_device *dev)
if (!exec)
return;
+ trace_vc4_finish_cl(dev, exec->seqno, true);
+
vc4->finished_seqno++;
list_move_tail(&exec->head, &vc4->job_done_list);
diff --git a/drivers/gpu/drm/vc4/vc4_trace.h b/drivers/gpu/drm/vc4/vc4_trace.h
index deafb32923e1..d5f2b91035a5 100644
--- a/drivers/gpu/drm/vc4/vc4_trace.h
+++ b/drivers/gpu/drm/vc4/vc4_trace.h
@@ -55,6 +55,64 @@ TRACE_EVENT(vc4_wait_for_seqno_end,
__entry->dev, __entry->seqno)
);
+TRACE_EVENT(vc4_submit_cl_begin,
+ TP_PROTO(struct drm_device *dev),
+ TP_ARGS(dev),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ ),
+
+ TP_printk("dev=%u",
+ __entry->dev)
+);
+
+TRACE_EVENT(vc4_submit_cl,
+ TP_PROTO(struct drm_device *dev, uint64_t seqno, int ring),
+ TP_ARGS(dev, seqno, ring),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, seqno)
+__field(bool, ring)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->seqno = seqno;
+ __entry->ring = ring;
+ ),
+
+ TP_printk("dev=%u, seqno=%llu %s",
+ __entry->dev, __entry->seqno,
+ __entry->ring ? "RCL" : "BCL")
+);
+
+TRACE_EVENT(vc4_finish_cl,
+ TP_PROTO(struct drm_device *dev, uint64_t seqno, int ring),
+ TP_ARGS(dev, seqno, ring),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, seqno)
+__field(bool, ring)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->seqno = seqno;
+ __entry->ring = ring;
+ ),
+
+ TP_printk("dev=%u, seqno=%llu %s",
+ __entry->dev, __entry->seqno,
+ __entry->ring ? "RCL" : "BCL")
+);
+
#endif /* _VC4_TRACE_H_ */
/* This part must be outside protection */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote:
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port
encryption
Implements the enable and disable functions for HDCP2.2 encryption
of the
PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 54
+++
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index d70320da85e4..91cac643f083 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
*intel_dig_port,
const struct intel_hdcp_shim *shim) @@ -
1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct
intel_connector
*connector)
return ret;
}
+
+static int hdcp2_enable_encryption(struct intel_connector
*connector) {
+ struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
Print a message saying "Encryption Already enabled" .
It doesn't serve any purpose uma. why do we need this?
+ return 0;
+
+ if (hdcp->hdcp_shim->toggle_signalling)
Check for "hdcp->hdcp_shim" as well.
Without hdcp_shim structure, we wont reach here.
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+
+ /* Link is Authenticated. Now set for Encryption */
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) |
+ CTL_LINK_ENCRYPTION_REQ);
+ }
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS,
+ LINK_ENCRYPTION_STATUS,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
Print a message in case of timeout.
Yes. Since this timeout is unexpected, debug msg would help.
Sorry my bad, caller is already handling the error case. So such debug
msg is needed only for disable sequence.
+ return ret;
+}
+
+static int hdcp2_disable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS))
Put a info message saying "Already Disabled" .
I feel this msg wont help uma.
+ return 0;
+
+ I915_WRITE(HDCP2_CTR_DDI(port),
+ I915_READ(HDCP2_CTR_DDI(port)) &
~CTL_LINK_ENCRYPTION_REQ);
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS, 0x0,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
If this times out, do we still need to toggle the signalling ?
As per the Bspec Encryption will stop in a frame time. So 32mSec
should be adequate.
So we need to toggle the hdcp signaling so that panel will know that
unencrypted data is expected.
+
+ if (hdcp->hdcp_shim->toggle_signalling)
Check for validity of " hdcp->hdcp_shim".
hdcp_shim will be valid at this point. but where as toggling function
is only for hdmi.
--Ram
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+ return ret;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able
On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able
May be calling enable/disable sequence separately will be better :)
Implements a sequence of enabling and disabling the HDCP2.2 (auth and
encryption).
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 75
+++
1 file changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 91cac643f083..005627746ca5 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -21,6 +21,9 @@
#define HDCP2_LC_RETRY_CNT 3
#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
+static int _intel_hdcp2_enable(struct intel_connector *connector);
+static int _intel_hdcp2_disable(struct intel_connector *connector);
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim) { @@ -
1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct intel_connector
*connector)
return ret;
}
+
+static int hdcp2_authenticate_and_encrypt(struct intel_connector
+*connector) {
+ int ret, i, tries = 3;
+
+ for (i = 0; i < tries; i++) {
+ ret = hdcp2_authenticate_sink(connector);
+ if (!ret)
+ break;
+
+ /* Clearing the mei hdcp session */
+ hdcp2_deauthenticate_port(&connector->hdcp);
+ DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
+ i + 1, tries, ret);
+ }
+
+ if (i != tries) {
+
+ /*
+* Ensuring the required 200mSec min time interval between
+* Session Key Exchange and encryption.
+*/
+ msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
+ ret = hdcp2_enable_encryption(connector);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n",
ret);
+ hdcp2_deauthenticate_port(&connector->hdcp);
+ }
+ }
+
+ return ret;
+}
+
+static int _intel_hdcp2_disable(struct intel_connector *connector) {
+ int ret;
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = hdcp2_disable_encryption(connector);
Check for return and print a message.
Caller will handle the error cases I guess. So we will just pass the
error here.
+
+ hdcp2_deauthenticate_port(&connector->hdcp);
+
+ return ret;
+}
+
+static int _intel_hdcp2_enable(struct intel_connector *connector) {
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ int ret;
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+ ret = hdcp2_authenticate_and_encrypt(connector);
+ if (ret) {
+ DRM_ERROR("HDCP2 Type%d Enabling Failed. (%d)\n",
+ hdcp->content_type, ret);
+ return ret;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
+ connector->base.name, connector->base.base.id,
+ hdcp->content_type);
+
+ hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+
+ return 0;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
;>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/exynos: Add driver for Exynos Scaler module
Hello Andrzej Pietrasiewicz,
The patch 01fb9185dc18: "drm/exynos: Add driver for Exynos Scaler
module" from May 9, 2018, leads to the following static checker
warning:
drivers/gpu/drm/exynos/exynos_drm_scaler.c:402 scaler_task_done()
warn: signedness bug returning '(-22)'
drivers/gpu/drm/exynos/exynos_drm_scaler.c
399
400 static inline bool scaler_task_done(u32 val)
401 {
402 return val & SCALER_INT_STATUS_FRAME_END ? 0 : -EINVAL;
^^^
403 }
404
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vc4: plane: Expand the lower bits by repeating the higher bits
The vc4 HVS uses an internal RGB888 representation of the frames, and will by default expand formats using a lower depth using zeros. This causes an issue when we try to use other compositing software such as pixman that fill the missing bits by repeating the higher significant bits. As such, we can't check the display output in a reliable way by doing a software composition and an hardware one and compare both. To prevent this, force the same behaviour so that we can do such things. Signed-off-by: Maxime Ripard --- Changes from v1: - Change the pattern - Rebase on top of drm-misc-next and use the defines newly introduced drivers/gpu/drm/vc4/vc4_plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 3483c05cc3d6..6e8984aee613 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -544,6 +544,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane, /* Control word */ vc4_dlist_write(vc4_state, SCALER_CTL0_VALID | + VC4_SET_FIELD(SCALER_CTL0_RGBA_EXPAND_ROUND, SCALER_CTL0_RGBA_EXPAND) | (format->pixel_order << SCALER_CTL0_ORDER_SHIFT) | (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) | VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) | -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander
Cc: Vivi, Rodrigo
Subject: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is performed by the
HDCP Receiver to check that cipher synchronization is maintained between the
HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the HDCP Receiver must assert the
corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
register and it may initiate re-authentication.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 81
++-
include/drm/drm_hdcp.h| 8
2 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 005627746ca5..e2aec73aefe3 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -23,6 +23,8 @@
static int _intel_hdcp2_enable(struct intel_connector *connector); static int
_intel_hdcp2_disable(struct intel_connector *connector);
+static void intel_hdcp2_check_work(struct work_struct *work); static
+int intel_hdcp2_check_link(struct intel_connector *connector);
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim) @@ -
1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector)
hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
schedule_work(&hdcp->hdcp_prop_work);
-
+ schedule_delayed_work(&hdcp->hdcp2_check_work,
+ DRM_HDCP2_CHECK_PERIOD_MS);
return 0;
}
+
+static int intel_hdcp2_check_link(struct intel_connector *connector) {
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum port port = connector->encoder->port;
+ int ret = 0;
+
+ if (!hdcp->hdcp_shim)
+ return -ENOENT;
+
+ mutex_lock(&hdcp->hdcp_mutex);
+
+ if (hdcp->hdcp_value ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
LINK_ENCRYPTION_STATUS)) {
+ DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+ ret = -ENXIO;
+ hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+ ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);
Check " hdcp->hdcp_shim->check_2_2_link " for NULL.
check_2_2_link is essential func ptr. Dont think it will be good to
check on each loop.
Wondering if I need to check for the essential func ptr at init itself.
--Ram
+ if (!ret) {
Here actually we are comparing the ret == DRM_HDCP_LINK_PROTECTED
indirectly here.
I will make it explicit, hence we can have the enum definition at this
patch itself.
+ if (hdcp->hdcp_value !=
DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ }
+ goto out;
+ }
+
+ DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
+connector->base.name, connector->base.base.id);
+
+ ret = _intel_hdcp2_disable(connector);
+ if (ret) {
+ DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+
+ hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+ ret = _intel_hdcp2_enable(connector);
+ if (ret) {
+ DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+
+ hdcp->hdcp_value =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->hdcp_prop_work);
+ goto out;
+ }
+
+out:
+ mutex_unlock(&hdcp->hdcp_mutex);
+ return ret;
+}
+
+static void intel_hdcp2_check_work(struct work_struct *work) {
+ struct intel_hdcp *hdcp = container_of(
Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer
Hi Daniel, Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone: > On 30 March 2018 at 15:11, Daniel Stone wrote: > > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > > can remove it. > > > > Signed-off-by: Daniel Stone > > Cc: Sandy Huang > > Cc: Heiko Stübner > > Ping? I only see the cover-letter (not listing all patches of the series) plus patches 4+5 of the series, nothing else. Both patches seem to reference other previous patches (1-3?) so could you point me at mboxes [patchwork] for those? Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/amd/pp: Change voltage/clk range for OD feature on VI
Hello Rex Zhu,
The patch d389d607e608: "drm/amd/pp: Change voltage/clk range for OD
feature on VI" from Apr 18, 2018, leads to the following static
checker warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872
smu7_setup_voltage_range_from_vbios()
error: uninitialized symbol 'min_vddc'.
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
857 static void smu7_setup_voltage_range_from_vbios(struct pp_hwmgr *hwmgr)
858 {
859 struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
860 struct phm_ppt_v1_clock_voltage_dependency_table
*dep_sclk_table;
861 struct phm_ppt_v1_information *table_info =
862 (struct phm_ppt_v1_information
*)(hwmgr->pptable);
863 uint32_t min_vddc, max_vddc;
864
865 if (!table_info)
866 return;
867
868 dep_sclk_table = table_info->vdd_dep_on_sclk;
869
870 atomctrl_get_voltage_range(hwmgr, &max_vddc, &min_vddc);
This doesn't necessarily initialize the parameters.
871
872 if (min_vddc == 0 || min_vddc > 2000
873 || min_vddc > dep_sclk_table->entries[0].vddc)
874 min_vddc = dep_sclk_table->entries[0].vddc;
875
876 if (max_vddc == 0 || max_vddc > 2000
877 || max_vddc <
dep_sclk_table->entries[dep_sclk_table->count-1].vddc)
878 max_vddc =
dep_sclk_table->entries[dep_sclk_table->count-1].vddc;
879
880 data->odn_dpm_table.min_vddc = min_vddc;
881 data->odn_dpm_table.max_vddc = max_vddc;
882 }
See also:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872
smu7_setup_voltage_range_from_vbios() error: uninitialized symbol 'min_vddc'.
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:876
smu7_setup_voltage_range_from_vbios() error: uninitialized symbol 'max_vddc'.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1588
vegam_populate_clock_stretcher_data_table() error: uninitialized symbol 'efuse'.
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1725
vegam_populate_avfs_parameters() error: uninitialized symbol 'tmp'.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
