Re: [git pull] drm tree for 5.4-rc1
On Fri, Sep 20, 2019 at 9:11 AM Dave Airlie wrote:
>
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
> > drm_gem_prime_export, because it's the default if none exists. That's
> > the left-over from
> >
> > 3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
> >
> > after the import stayed around because it got turned into an actually
> > non-default one.
> >
> > I think that both of our merges are right - equivalent but just
> > slightly different.
> >
> > But the reason I'm pointing this out is that I also get the feeling
> > that if it needs that dev->dev_private difference from the default
> > function in prime_import(), wouldn't it need the same for prime_export
> > too?
> >
> > I don't know the code, and I don't know the hardware, but just from a
> > "pattern matching" angle I just wanted to check whether maybe there's
> > need for a mtk_drm_gem_prime_export() wrapper that does that same
> > thing with
> >
> > struct mtk_drm_private *private = dev->dev_private;
> >
> > .. use private->dev instead of dev->dev ..
> >
> > So I'm just asking that somebody that knows that drm/mtk code should
> > double-check that oddity.
>
> I've cc'ed Alexandre who wrote the import half of this code to look into it.
I am not super familiar with this driver either so I may have
overlooked this. Using dev->dev_private was to make sure that the
imported buffers would be mapped contiguously in the device's address
space, so I am not sure whether we need to do something in the case of
export.
Added CK and Tomasz who may have a more informed opinion on this.
[drm-intel:drm-intel-next-queued 5/7] drivers/gpu/drm/i915/display/intel_color.c:1535 i9xx_read_lut_8() error: potential null dereference 'blob'. (drm_property_create_blob returns null)
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 4bb6a9d5d9a8289673c4cb0786d44be8a63c21db
commit: 1af22383829864299102ca0c2eab458f755a9971 [5/7] drm/i915/display:
Extract i9xx_read_luts()
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
smatch warnings:
drivers/gpu/drm/i915/display/intel_color.c:1535 i9xx_read_lut_8() error:
potential null dereference 'blob'. (drm_property_create_blob returns null)
vim +/blob +1535 drivers/gpu/drm/i915/display/intel_color.c
1518
1519 static struct drm_property_blob *
1520 i9xx_read_lut_8(const struct intel_crtc_state *crtc_state)
1521 {
1522 struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
1523 struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
1524 enum pipe pipe = crtc->pipe;
1525 struct drm_property_blob *blob;
1526 struct drm_color_lut *blob_data;
1527 u32 i, val;
1528
1529 blob = drm_property_create_blob(_priv->drm,
1530 sizeof(struct drm_color_lut) *
LEGACY_LUT_LENGTH,
1531 NULL);
1532 if (IS_ERR(blob))
1533 return NULL;
1534
> 1535 blob_data = blob->data;
1536
1537 for (i = 0; i < LEGACY_LUT_LENGTH; i++) {
1538 if (HAS_GMCH(dev_priv))
1539 val = I915_READ(PALETTE(pipe, i));
1540 else
1541 val = I915_READ(LGC_PALETTE(pipe, i));
1542
1543 blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(
1544
LGC_PALETTE_RED_MASK, val), 8);
1545 blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(
1546
LGC_PALETTE_GREEN_MASK, val), 8);
1547 blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(
1548
LGC_PALETTE_BLUE_MASK, val), 8);
1549 }
1550
1551 return blob;
1552 }
1553
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: kirin: Fix dsi probe/attach logic
Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
host at probe time") landed in -next the HiKey board would fail
to boot, looping:
adv7511 2-0039: failed to find dsi host
messages over and over. Andrzej Hajda suggested this is due to a
circular dependency issue, and that the adv7511 change is
correcting the improper order used earlier.
Unfortunately this means the DSI drivers that use adv7511 need
to also need to be updated to use the proper ordering to
continue to work.
This patch tries to reorder the initialization to register the
dsi_host first, and then call component_add via dsi_host_attach,
instead of doing that at probe time.
This seems to resolve the issue with the HiKey board.
Cc: Andrzej Hajda
Cc: Matt Redfearn
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Laurent Pinchart
Cc: Neil Armstrong
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: Thierry Reding
Cc: David Airlie ,
Cc: Sean Paul
Cc: Sam Ravnborg
Cc: "dri-devel@lists.freedesktop.org"
Fixes: 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI host at probe time")
Signed-off-by: John Stultz
Change-Id: Ia42345f81b4955a732d0251f1d1ddb118f885299
---
v2: Reordered platform_set_drvdata and dsi_host_init, suggested
by Andrzej
Note: I'm really not super familiar with the DSI code here,
and am mostly just trying to refactor the existing code in a
similar fashion to the suggested dw-mipi-dsi-rockchip.c
implementation. Careful review would be greatly appreciated!
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 107 +--
1 file changed, 52 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 5bf8138941de..0ddf22a8be0f 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
};
struct dw_dsi {
+ struct device *dev;
struct drm_encoder encoder;
struct drm_bridge *bridge;
struct mipi_dsi_host host;
@@ -724,51 +725,6 @@ static int dw_drm_encoder_init(struct device *dev,
return 0;
}
-static int dsi_host_attach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *mdsi)
-{
- struct dw_dsi *dsi = host_to_dsi(host);
-
- if (mdsi->lanes < 1 || mdsi->lanes > 4) {
- DRM_ERROR("dsi device params invalid\n");
- return -EINVAL;
- }
-
- dsi->lanes = mdsi->lanes;
- dsi->format = mdsi->format;
- dsi->mode_flags = mdsi->mode_flags;
-
- return 0;
-}
-
-static int dsi_host_detach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *mdsi)
-{
- /* do nothing */
- return 0;
-}
-
-static const struct mipi_dsi_host_ops dsi_host_ops = {
- .attach = dsi_host_attach,
- .detach = dsi_host_detach,
-};
-
-static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
-{
- struct mipi_dsi_host *host = >host;
- int ret;
-
- host->dev = dev;
- host->ops = _host_ops;
- ret = mipi_dsi_host_register(host);
- if (ret) {
- DRM_ERROR("failed to register dsi host\n");
- return ret;
- }
-
- return 0;
-}
-
static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
{
struct drm_encoder *encoder = >encoder;
@@ -796,10 +752,6 @@ static int dsi_bind(struct device *dev, struct device
*master, void *data)
if (ret)
return ret;
- ret = dsi_host_init(dev, dsi);
- if (ret)
- return ret;
-
ret = dsi_bridge_init(drm_dev, dsi);
if (ret)
return ret;
@@ -817,13 +769,22 @@ static const struct component_ops dsi_ops = {
.unbind = dsi_unbind,
};
-static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
+static int dsi_host_attach(struct mipi_dsi_host *host,
+ struct mipi_dsi_device *mdsi)
{
- struct dsi_hw_ctx *ctx = dsi->ctx;
- struct device_node *np = pdev->dev.of_node;
- struct resource *res;
+ struct dw_dsi *dsi = host_to_dsi(host);
+ struct device_node *np = dsi->dev->of_node;
int ret;
+ if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+ DRM_ERROR("dsi device params invalid\n");
+ return -EINVAL;
+ }
+
+ dsi->lanes = mdsi->lanes;
+ dsi->format = mdsi->format;
+ dsi->mode_flags = mdsi->mode_flags;
+
/*
* Get the endpoint node. In our case, dsi has one output port1
* to which the external HDMI bridge is connected.
@@ -832,6 +793,42 @@ static int dsi_parse_dt(struct platform_device *pdev,
struct dw_dsi *dsi)
if (ret)
return ret;
+ return component_add(dsi->dev, _ops);
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+ struct mipi_dsi_device *mdsi)
+{
+ /* do nothing */
+ return
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #53 from Sebastian Meyer ---
Just compiled the latest mainline kernel from a few hours ago with the merge of
drm-next-2019-09-18 and tried again.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=574cc4539762561d96b456dbc0544d8898bd4c6e
RotTR is still making the system freeze. I haven't tested other Vulkan
applications yet.
[ 330.849703] amdgpu :04:00.0: [gfxhub] page fault (src_id:0 ring:24
vmid:3 pasid:32777, for process RiseOfTheTombRa pid 2371 thread RiseOfTheT:cs0
pid 2377)
[ 330.849706] amdgpu :04:00.0: in page starting at address
0x8000bf066000 from client 27
[ 330.849708] amdgpu :04:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00301430
[ 330.849709] amdgpu :04:00.0: MORE_FAULTS: 0x0
[ 330.849711] amdgpu :04:00.0: WALKER_ERROR: 0x0
[ 330.849712] amdgpu :04:00.0: PERMISSION_FAULTS: 0x3
[ 330.849713] amdgpu :04:00.0: MAPPING_ERROR: 0x0
[ 330.849715] amdgpu :04:00.0: RW: 0x0
[ 335.967209] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[ 335.967290] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[ 340.873553] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0
timeout, signaled seq=73308, emitted seq=73310
[ 340.873616] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process RiseOfTheTombRa pid 2371 thread RiseOfTheT:cs0 pid 2377
[ 340.873618] [drm] GPU recovery disabled.
[ 341.086869] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
$ pacman -Q linux-git linux-firmware-agd5f-radeon-navi10
{,lib32-}{mesa-git,vulkan-radeon-git,llvm-git,libdrm-git}
linux-git 5.3.r10169.g574cc4539762-1
linux-firmware-agd5f-radeon-navi10 2019.09.13.18.36-1
mesa-git 1:19.3.0_devel.115529.8b78cce433b-1
lib32-mesa-git 1:19.3.0_devel.115529.8b78cce433b-1
vulkan-radeon-git 1:19.3.0_devel.115529.8b78cce433b-1
lib32-vulkan-radeon-git 1:19.3.0_devel.115529.8b78cce433b-1
llvm-git 10.0.0_r327281.ec841cf36ca-1
lib32-llvm-git 10.0.0_r327289.ed69faa01bf-1
libdrm-git 2.4.99.r23.g0c427545-1
lib32-libdrm-git 2.4.99.r23.g0c427545-1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 04/11] devfreq: exynos-bus: Clean up code
Hi Artur,
On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds minor improvements to the exynos-bus driver.
>
> Signed-off-by: Artur Świgoń
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/devfreq/exynos-bus.c | 66 ++--
> 1 file changed, 25 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 60ad4319fd80..8d44810cac69 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -15,11 +15,10 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> -#include
>
> #define DEFAULT_SATURATION_RATIO 40
>
> @@ -178,7 +177,7 @@ static int exynos_bus_parent_parse_of(struct device_node
> *np,
> struct device *dev = bus->dev;
> struct opp_table *opp_table;
> const char *vdd = "vdd";
> - int i, ret, count, size;
> + int i, ret, count;
>
> opp_table = dev_pm_opp_set_regulators(dev, , 1);
> if (IS_ERR(opp_table)) {
> @@ -201,8 +200,7 @@ static int exynos_bus_parent_parse_of(struct device_node
> *np,
> }
> bus->edev_count = count;
>
> - size = sizeof(*bus->edev) * count;
> - bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
> + bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev), GFP_KERNEL);
> if (!bus->edev) {
> ret = -ENOMEM;
> goto err_regulator;
> @@ -301,10 +299,9 @@ static int exynos_bus_profile_init(struct exynos_bus
> *bus,
> profile->exit = exynos_bus_exit;
>
> ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> - if (!ondemand_data) {
> - ret = -ENOMEM;
> - goto err;
> - }
> + if (!ondemand_data)
> + return -ENOMEM;
> +
> ondemand_data->upthreshold = 40;
> ondemand_data->downdifferential = 5;
>
> @@ -314,8 +311,7 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
> ondemand_data);
> if (IS_ERR(bus->devfreq)) {
> dev_err(dev, "failed to add devfreq device\n");
> - ret = PTR_ERR(bus->devfreq);
> - goto err;
> + return PTR_ERR(bus->devfreq);
> }
>
> /*
> @@ -325,16 +321,13 @@ static int exynos_bus_profile_init(struct exynos_bus
> *bus,
> ret = exynos_bus_enable_edev(bus);
> if (ret < 0) {
> dev_err(dev, "failed to enable devfreq-event devices\n");
> - goto err;
> + return ret;
> }
>
> ret = exynos_bus_set_event(bus);
> - if (ret < 0) {
> + if (ret < 0)
> dev_err(dev, "failed to set event to devfreq-event devices\n");
> - goto err;
Instead of removing 'goto err', just return err as I commented[1] on v1.
[1] https://lkml.org/lkml/2019/7/26/331
> - }
>
> -err:
> return ret;
And you just keep 'return ret' or you can change it as 'return 0'.
> }
>
> @@ -344,7 +337,6 @@ static int exynos_bus_profile_init_passive(struct
> exynos_bus *bus,
> struct device *dev = bus->dev;
> struct devfreq_passive_data *passive_data;
> struct devfreq *parent_devfreq;
> - int ret = 0;
>
> /* Initialize the struct profile and governor data for passive device */
> profile->target = exynos_bus_target;
> @@ -352,30 +344,26 @@ static int exynos_bus_profile_init_passive(struct
> exynos_bus *bus,
>
> /* Get the instance of parent devfreq device */
> parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
> - if (IS_ERR(parent_devfreq)) {
> - ret = -EPROBE_DEFER;
> - goto err;
> - }
> + if (IS_ERR(parent_devfreq))
> + return -EPROBE_DEFER;
>
> passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
> - if (!passive_data) {
> - ret = -ENOMEM;
> - goto err;
> - }
> + if (!passive_data)
> + return -ENOMEM;
> +
> passive_data->parent = parent_devfreq;
>
> /* Add devfreq device for exynos bus with passive governor */
> - bus->devfreq = devm_devfreq_add_device(dev, profile,
> DEVFREQ_GOV_PASSIVE,
> + bus->devfreq = devm_devfreq_add_device(dev, profile,
> + DEVFREQ_GOV_PASSIVE,
> passive_data);
> if (IS_ERR(bus->devfreq)) {
> dev_err(dev,
> "failed to add devfreq dev with passive governor\n");
> - ret = PTR_ERR(bus->devfreq);
> - goto err;
> + return PTR_ERR(bus->devfreq);
> }
>
> -err:
> - return ret;
> + return 0;
> }
>
> static int exynos_bus_probe(struct platform_device *pdev)
> @@ -393,18 +381,18 @@ static int exynos_bus_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> -
Re: [PATCH] drm/fourcc: Add Arm 16x16 block modifier
Hi guys,
I'd like to know the status of this patch? I expect a v2 adding some
comments/macros about the high bit plan would be enough?
@Raymond & @Brian do you still need another long process to send out a
v2 patch? If so, I can help to prepare a v2 patch according to your
previous mail.
Thanks,
Qiang
On Thu, Jun 27, 2019 at 3:30 AM Daniel Vetter wrote:
>
> On Mon, Jun 24, 2019 at 1:23 PM Brian Starkey wrote:
> >
> > On Mon, Jun 24, 2019 at 11:58:59AM +0200, Daniel Vetter wrote:
> > > On Mon, Jun 24, 2019 at 11:32 AM Brian Starkey
> > > wrote:
> > > >
> > > > Hi Daniel,
> > > >
> > > > On Fri, Jun 21, 2019 at 05:27:00PM +0200, Daniel Vetter wrote:
> > > > > On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith
> > > > > wrote:
> > > > > >
> > > > > > Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> > > > > > denote the 16x16 block u-interleaved format used in Arm Utgard and
> > > > > > Midgard GPUs.
> > > > > >
> > > > > > Signed-off-by: Raymond Smith
> > > > > > ---
> > > > > > include/uapi/drm/drm_fourcc.h | 10 ++
> > > > > > 1 file changed, 10 insertions(+)
> > > > > >
> > > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > > index 3feeaa3..8ed7ecf 100644
> > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > @@ -743,6 +743,16 @@ extern "C" {
> > > > > > #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
> > > > > >
> > > > > > /*
> > > > > > + * Arm 16x16 Block U-Interleaved modifier
> > > > > > + *
> > > > > > + * This is used by Arm Mali Utgard and Midgard GPUs. It divides
> > > > > > the image
> > > > > > + * into 16x16 pixel blocks. Blocks are stored linearly in order,
> > > > > > but pixels
> > > > > > + * in the block are reordered.
> > > > > > + */
> > > > > > +#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
> > > > > > + fourcc_mod_code(ARM, ((1ULL << 55) | 1))
> > > > >
> > > > > This seems to be an extremely random pick for a new number. What's the
> > > > > thinking here? Aside from "doesnt match any of the afbc combos" ofc.
> > > > > If you're already up to having thrown away 55bits, then it's not going
> > > > > to last long really :-)
> > > > >
> > > > > I think a good idea would be to reserve a bunch of the high bits as
> > > > > some form of index (afbc would get index 0 for backwards compat). And
> > > > > then the lower bits would be for free use for a given index/mode. And
> > > > > the first mode is probably an enumeration, where possible modes simple
> > > > > get enumerated without further flags or anything.
> > > >
> > > > Yup, that's the plan:
> > > >
> > > > (0 << 55): AFBC
> > > > (1 << 55): This "non-category" for U-Interleaved
> > > > (1 << 54): Whatever the next category is
> > > > (3 << 54): Whatever comes after that
> > > > (1 << 53): Maybe we'll get here someday
> > >
> > > Uh, so the index would be encoded with least-significant bit first,
> > > starting from bit55 downwards?
> >
> > Yeah.
> >
> > > Clever idea, but I think this needs a
> > > macro (or at least a comment). Not sure there's a ready-made bitmask
> > > mirror function for this stuff, works case we can hand-code it and
> > > extend every time we need one more bit encoded. Something like:
> > >
> > > MIRROR_U32((u & (BIT(0)) << 31 | (u & BIT(1) << 30 | ...)
> > >
> >
> > Is it really worth it? People can just use the definitions as written
> > in drm_fourcc.h. I agree that we should have the high bits described
> > in a comment though.
> >
> > > And then shift that to the correct place. Probably want an
> > >
> > > ARM_MODIFIER_ENCODE(space_idx, flags) macro which assembles everything.
> > >
> > > > ...
> > > >
> > > > I didn't want to explicitly reserve some high bits, because we've no
> > > > idea how many to reserve. This way, we can assign exactly as many
> > > > high bits as we need, when we need them. If any of the "modes" start
> > > > encroaching towards the high bits, we'll have to make a decision at
> > > > that point.
> > > >
> > > > Also, this is the only U-Interleaved format (that I know of), so it's
> > > > not worth calling bit 55 "The U-Interleaved bit" because that would be
> > > > a waste of space. It's more like the "misc" bit, but that's not a
> > > > useful name to enshrine in UAPI.
> > >
> > > Yeah that's what I meant. Also better to explicitly reserve this, i.e.
> > >
> > > #define ARM_FBC_MODIFIER_SPACE 0
> > > #define ARM_MISC_MODIFIER_SPACE 1
> > >
> > > and then encode with the mirror trickery.
> > >
> >
> > I don't really see the value in that either, it's just giving
> > userspace the opportunity to depend on more stuff: more future
> > headaches. So long as the 64-bit values are stable, that should be
> > enough.
>
> If you think you need to save the few bits this potentially saves you
> over just encoding 8bit enum like in Qiang's original patch I think
> you get to type a few
Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
Hi,
As I already replied on v1, patch1/2/3 clean-up code
for readability without any behavior changes.
I think that you better to merge patch1/2/3 to one patch.
On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds a new static function, exynos_bus_profile_init(), extracted
> from exynos_bus_probe().
>
> Signed-off-by: Artur Świgoń
> ---
> drivers/devfreq/exynos-bus.c | 92 +---
> 1 file changed, 53 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 29f422469960..78f38b7fb596 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
> return ret;
> }
>
> +static int exynos_bus_profile_init(struct exynos_bus *bus,
> +struct devfreq_dev_profile *profile)
> +{
> + struct device *dev = bus->dev;
> + struct devfreq_simple_ondemand_data *ondemand_data;
> + int ret;
> +
> + /* Initialize the struct profile and governor data for parent device */
> + profile->polling_ms = 50;
> + profile->target = exynos_bus_target;
> + profile->get_dev_status = exynos_bus_get_dev_status;
> + profile->exit = exynos_bus_exit;
> +
> + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> + if (!ondemand_data) {
> + ret = -ENOMEM;
> + goto err;
> + }
> + ondemand_data->upthreshold = 40;
> + ondemand_data->downdifferential = 5;
> +
> + /* Add devfreq device to monitor and handle the exynos bus */
> + bus->devfreq = devm_devfreq_add_device(dev, profile,
> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> + ondemand_data);
> + if (IS_ERR(bus->devfreq)) {
> + dev_err(dev, "failed to add devfreq device\n");
> + ret = PTR_ERR(bus->devfreq);
> + goto err;
> + }
> +
> + /*
> + * Enable devfreq-event to get raw data which is used to determine
> + * current bus load.
> + */
> + ret = exynos_bus_enable_edev(bus);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable devfreq-event devices\n");
> + goto err;
> + }
> +
> + ret = exynos_bus_set_event(bus);
> + if (ret < 0) {
> + dev_err(dev, "failed to set event to devfreq-event devices\n");
> + goto err;
> + }
> +
> +err:
> + return ret;
> +}
> +
> static int exynos_bus_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct device_node *np = dev->of_node, *node;
> struct devfreq_dev_profile *profile;
> - struct devfreq_simple_ondemand_data *ondemand_data;
> struct devfreq_passive_data *passive_data;
> struct devfreq *parent_devfreq;
> struct exynos_bus *bus;
> @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (passive)
> goto passive;
>
> - /* Initialize the struct profile and governor data for parent device */
> - profile->polling_ms = 50;
> - profile->target = exynos_bus_target;
> - profile->get_dev_status = exynos_bus_get_dev_status;
> - profile->exit = exynos_bus_exit;
> -
> - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> - if (!ondemand_data) {
> - ret = -ENOMEM;
> + ret = exynos_bus_profile_init(bus, profile);
> + if (ret < 0)
> goto err;
> - }
> - ondemand_data->upthreshold = 40;
> - ondemand_data->downdifferential = 5;
> -
> - /* Add devfreq device to monitor and handle the exynos bus */
> - bus->devfreq = devm_devfreq_add_device(dev, profile,
> - DEVFREQ_GOV_SIMPLE_ONDEMAND,
> - ondemand_data);
> - if (IS_ERR(bus->devfreq)) {
> - dev_err(dev, "failed to add devfreq device\n");
> - ret = PTR_ERR(bus->devfreq);
> - goto err;
> - }
> -
> - /*
> - * Enable devfreq-event to get raw data which is used to determine
> - * current bus load.
> - */
> - ret = exynos_bus_enable_edev(bus);
> - if (ret < 0) {
> - dev_err(dev, "failed to enable devfreq-event devices\n");
> - goto err;
> - }
> -
> - ret = exynos_bus_set_event(bus);
> - if (ret < 0) {
> - dev_err(dev, "failed to set event to devfreq-event devices\n");
> - goto err;
> - }
>
> goto out;
> passive:
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
Hi Artur, I tried to just build this patch on mainline kernel or linux-next. But, when I applied them, merge conflict happens. You didn't develop them on latest version. Please rebase them based on latest mainline kernel. On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote: > Hi Artur, > > On v1, I mentioned that we need to discuss how to change > the v2 for this. But, I have not received any reply from you on v1. > And, without your reply from v1, you just send v2. > > I think that it is not proper development sequence. > I have spent many times to review your patches > and also I'll review your patches. You have to take care > the reply of reviewer and and keep the basic rule > of mailing contribution for discussion. > > On 19. 9. 19. 오후 11:22, Artur Świgoń wrote: >> The following patchset adds interconnect[1][2] framework support to the >> exynos-bus devfreq driver. Extending the devfreq driver with interconnect >> capabilities started as a response to the issue referenced in [3]. The >> patches can be subdivided into four logical groups: >> >> (a) Refactoring the existing devfreq driver in order to improve readability >> and accommodate for adding new code (patches 01--04/11). >> >> (b) Tweaking the interconnect framework to support the exynos-bus use case >> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to >> avoid hardcoding every single graph edge in the DT or driver source, and >> relaxing the requirement contained in that function removes the need to >> provide dummy node IDs in the DT. Adjusting the logic in >> apply_constraints() (drivers/interconnect/core.c) accounts for the fact >> that every bus is a separate entity and therefore a separate interconnect >> provider, albeit constituting a part of a larger hierarchy. >> >> (c) Implementing interconnect providers in the exynos-bus devfreq driver >> and adding required DT properties for one selected platform, namely >> Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a >> generic driver for various Exynos SoCs, node IDs are generated dynamically >> rather than hardcoded. This has been determined to be a simpler approach, >> but depends on changes described in (b). >> >> (d) Implementing a sample interconnect consumer for exynos-mixer targeted >> at the issue referenced in [3], again with DT info only for Exynos4412 >> (patches 10--11/11). >> >> Integration of devfreq and interconnect functionalities is achieved by >> using dev_pm_qos_*() API[5]. All new code works equally well when >> CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all >> interconnect API functions are no-ops. >> >> This patchset depends on [5]. >> >> --- Changes since v1 [6]: >> * Rebase on [4] (coupled regulators). >> * Rebase on [5] (dev_pm_qos for devfreq). >> * Use dev_pm_qos_*() API[5] instead of overriding frequency in >> exynos_bus_target(). >> * Use IDR for node ID allocation. >> * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04). >> * Reverse order of multiplication and division in >> mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow. >> >> --- >> Artur Świgoń >> Samsung R Institute Poland >> Samsung Electronics >> >> --- >> References: >> [1] Documentation/interconnect/interconnect.rst >> [2] Documentation/devicetree/bindings/interconnect/interconnect.txt >> [3] https://patchwork.kernel.org/patch/10861757/ (original issue) >> [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged) >> [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq) >> [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) >> >> Artur Świgoń (10): >> devfreq: exynos-bus: Extract exynos_bus_profile_init() >> devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() >> devfreq: exynos-bus: Change goto-based logic to if-else logic >> devfreq: exynos-bus: Clean up code >> interconnect: Export of_icc_get_from_provider() >> interconnect: Relax requirement in of_icc_get_from_provider() >> interconnect: Relax condition in apply_constraints() >> arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412 >> devfreq: exynos-bus: Add interconnect functionality to exynos-bus >> arm: dts: exynos: Add interconnects to Exynos4412 mixer >> >> Marek Szyprowski (1): >> drm: exynos: mixer: Add interconnect support >> >> .../boot/dts/exynos4412-odroid-common.dtsi| 1 + >> arch/arm/boot/dts/exynos4412.dtsi | 10 + >> drivers/devfreq/exynos-bus.c | 319 +- >> drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++- >> drivers/interconnect/core.c | 12 +- >> include/linux/interconnect-provider.h | 6 + >> 6 files changed, 327 insertions(+), 92 deletions(-) >> > > -- Best Regards, Chanwoo Choi Samsung Electronics
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 Christopher Snowhill (kod...@gmail.com) changed: What|Removed |Added CC||kod...@gmail.com --- Comment #49 from Christopher Snowhill (kod...@gmail.com) --- RX 480. Applied patch, haven't had any spurious crashes since. Using patchset since kernel 5.2.14, now using it on 5.3. Haven't had any suspend/wake crashes yet, either, but that may be unrelated. Will continue applying it to successive 5.3 kernels until it is officially backported, and will report if there are any further crashes. -- 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 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #29 from Brian Schott --- (In reply to Pierre-Eric Pelloux-Prayer from comment #28) > > Could you test this commit > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2016/ > diffs?commit_id=4829f697ab2ceb2fc2772cc1220acc4185e6013d and let us know if > it fixes this issue? Using kernel 5.3.0 and mesa git with that patch: * Graphics corruption in Dolphin is gone (without nodcc env variable) * System lockup is gone (without nodcc env variable) * Desktop corruption is still present (without nodcc env variable) * Desktop corruption is gone (nodcc env variable set) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
Hi Artur, On v1, I mentioned that we need to discuss how to change the v2 for this. But, I have not received any reply from you on v1. And, without your reply from v1, you just send v2. I think that it is not proper development sequence. I have spent many times to review your patches and also I'll review your patches. You have to take care the reply of reviewer and and keep the basic rule of mailing contribution for discussion. On 19. 9. 19. 오후 11:22, Artur Świgoń wrote: > The following patchset adds interconnect[1][2] framework support to the > exynos-bus devfreq driver. Extending the devfreq driver with interconnect > capabilities started as a response to the issue referenced in [3]. The > patches can be subdivided into four logical groups: > > (a) Refactoring the existing devfreq driver in order to improve readability > and accommodate for adding new code (patches 01--04/11). > > (b) Tweaking the interconnect framework to support the exynos-bus use case > (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to > avoid hardcoding every single graph edge in the DT or driver source, and > relaxing the requirement contained in that function removes the need to > provide dummy node IDs in the DT. Adjusting the logic in > apply_constraints() (drivers/interconnect/core.c) accounts for the fact > that every bus is a separate entity and therefore a separate interconnect > provider, albeit constituting a part of a larger hierarchy. > > (c) Implementing interconnect providers in the exynos-bus devfreq driver > and adding required DT properties for one selected platform, namely > Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a > generic driver for various Exynos SoCs, node IDs are generated dynamically > rather than hardcoded. This has been determined to be a simpler approach, > but depends on changes described in (b). > > (d) Implementing a sample interconnect consumer for exynos-mixer targeted > at the issue referenced in [3], again with DT info only for Exynos4412 > (patches 10--11/11). > > Integration of devfreq and interconnect functionalities is achieved by > using dev_pm_qos_*() API[5]. All new code works equally well when > CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all > interconnect API functions are no-ops. > > This patchset depends on [5]. > > --- Changes since v1 [6]: > * Rebase on [4] (coupled regulators). > * Rebase on [5] (dev_pm_qos for devfreq). > * Use dev_pm_qos_*() API[5] instead of overriding frequency in > exynos_bus_target(). > * Use IDR for node ID allocation. > * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04). > * Reverse order of multiplication and division in > mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow. > > --- > Artur Świgoń > Samsung R Institute Poland > Samsung Electronics > > --- > References: > [1] Documentation/interconnect/interconnect.rst > [2] Documentation/devicetree/bindings/interconnect/interconnect.txt > [3] https://patchwork.kernel.org/patch/10861757/ (original issue) > [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged) > [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq) > [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) > > Artur Świgoń (10): > devfreq: exynos-bus: Extract exynos_bus_profile_init() > devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() > devfreq: exynos-bus: Change goto-based logic to if-else logic > devfreq: exynos-bus: Clean up code > interconnect: Export of_icc_get_from_provider() > interconnect: Relax requirement in of_icc_get_from_provider() > interconnect: Relax condition in apply_constraints() > arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412 > devfreq: exynos-bus: Add interconnect functionality to exynos-bus > arm: dts: exynos: Add interconnects to Exynos4412 mixer > > Marek Szyprowski (1): > drm: exynos: mixer: Add interconnect support > > .../boot/dts/exynos4412-odroid-common.dtsi| 1 + > arch/arm/boot/dts/exynos4412.dtsi | 10 + > drivers/devfreq/exynos-bus.c | 319 +- > drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++- > drivers/interconnect/core.c | 12 +- > include/linux/interconnect-provider.h | 6 + > 6 files changed, 327 insertions(+), 92 deletions(-) > -- Best Regards, Chanwoo Choi Samsung Electronics
[Bug 111234] amdgpu bug: kernel NULL pointer dereference during video playback
https://bugs.freedesktop.org/show_bug.cgi?id=111234 --- Comment #4 from jamespharve...@gmail.com --- Just ran into this for my first time. I've had pretty consistent problems with the potentially related bug that Nicholas Kazlauskas mentioned at https://bugzilla.kernel.org/show_bug.cgi?id=204181 Could certainly be the same bug, but definitely has a different backtrace. Also running KDE, also running multi (5) monitor. Was on linux 5.2.10, mesa 19.1.6, plasma 5.16.4. == 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c1) (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RX Vega64 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- [drm] add ip block number 1 [drm] add ip block number 2 [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 [drm] add ip block number 6 [drm] add ip block number 7 [drm] add ip block number 8 [drm] add ip block number 9 [drm] UVD(0) is enabled in VM mode [drm] UVD(0) ENC is enabled in VM mode [drm] VCE enabled in VM mode [drm] RAS INFO: ras initialized successfully, hardware ability[0] ras_mask[0] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [drm] Detected VRAM RAM=8176M, BAR=256M [drm] RAM width 2048bits HBM [drm] amdgpu: 8176M of VRAM memory ready [drm] amdgpu: 8176M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] PCIE GART of 512M enabled (table at 0x00F40090). [drm] use_doorbell being set to: [true] [drm] use_doorbell being set to: [true] [drm] Found UVD firmware Version: 65.29 Family ID: 17 [drm] PSP loading UVD firmware [drm] Found VCE firmware Version: 57.4 Binary ID: 4 [drm] PSP loading VCE firmware [drm] reserve 0x40 from 0xf40100 for PSP TMR SIZE [drm] Display Core initialized with v3.2.27! [drm] DM_MST: Differing MST start on aconnector: (ptrval) [id: 59] [drm] DM_MST: Differing MST start on aconnector: (ptrval) [id: 62] [drm] DM_MST: Differing MST start on aconnector: (ptrval) [id: 65] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] UVD and UVD ENC initialized successfully. [drm] VCE initialized successfully. [drm] Cannot find any crtc or sizes [drm] ECC is not present. [drm] SRAM ECC is not present. [drm] Initialized amdgpu 3.32.0 20150101 for :05:00.0 on minor 0 [drm] amdgpu_dm_irq_schedule_work FAILED src 8 [drm] DM_MST: added connector: (ptrval) [id: 70] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 74] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 78] [master: (ptrval)] [drm] fb mappable at 0xC140 [drm] vram apper at 0xC000 [drm] size 14745600 [drm] fb depth is 24 [drm]pitch is 10240 fbcon: amdgpudrmfb (fb0) is primary device [drm] DM_MST: added connector: (ptrval) [id: 85] [master: (ptrval)] amdgpu :05:00.0: fb0: amdgpudrmfb frame buffer device [drm] DM_MST: added connector: (ptrval) [id: 89] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 93] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 97] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 107] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 113] [master: (ptrval)] [drm] DM_MST: added connector: (ptrval) [id: 117] [master: (ptrval)] .. BUG: kernel NULL pointer dereference, address: 02b4 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP PTI CPU: 1 PID: 2678499 Comm: kworker/u65:9 Tainted: GW OE 5.2.11-arch1-1-ARCH #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./EP2C602, BIOS P1.90 04/12/2018 Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dc_stream_log+0x6/0xb0 [amdgpu] Code: 04 00 00 49 8b bc 02 b0 02 00 00 48 8b 07 48 8b 40 50 e8 2d 3b 14 c9 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 66 66 66 66 90 53 <8b> 86 b4 02 00 00 48 89 f3 48 89 f2 8b 8e 10 01 00 00 bf 04 00 00 RSP: 0018:a0c6a365faf8 EFLAGS: 00010202 RAX: RBX: 0001 RCX: 0005 RDX: c0547710 RSI: RDI: 9a4bd62e5000 RBP: 9a448308 R08: 9a448308 R09: R10: 9a448308 R11: 0018 R12: 9a4bd62e5000 R13: a0c6a365fd58 R14: 9a4bd67dcff0 R15: FS: () GS:9a4bdf84() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02b4 CR3: 000ffbe76005 CR4: 000626e0
Re: [git pull] drm tree for 5.4-rc1
> Hmm. My merge isn't identical to that. It's close though. Different
> order for one #define which might be just from you and me merging
> different directions.
>
> But I also ended up removing the .gem_prime_export initialization to
> drm_gem_prime_export, because it's the default if none exists. That's
> the left-over from
>
> 3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
>
> after the import stayed around because it got turned into an actually
> non-default one.
>
> I think that both of our merges are right - equivalent but just
> slightly different.
>
> But the reason I'm pointing this out is that I also get the feeling
> that if it needs that dev->dev_private difference from the default
> function in prime_import(), wouldn't it need the same for prime_export
> too?
>
> I don't know the code, and I don't know the hardware, but just from a
> "pattern matching" angle I just wanted to check whether maybe there's
> need for a mtk_drm_gem_prime_export() wrapper that does that same
> thing with
>
> struct mtk_drm_private *private = dev->dev_private;
>
> .. use private->dev instead of dev->dev ..
>
> So I'm just asking that somebody that knows that drm/mtk code should
> double-check that oddity.
I've cc'ed Alexandre who wrote the import half of this code to look into it.
I've looked at the other results and it all seems fine to me.
Dave.
Re: [PATCH 15/15] drm/amd/display: Trigger modesets on MST DSC connectors
This still needs to be moved into an atomic helper so it can be reused by
other drivers
...
...
however, I've had this patch series on my mind for a while and something
occurred to me that would be a lot easier. Why exactly are we not just
enabling DSC wherever it's supported, regardless of whether or not it's
actually needed to fit into bandwidth constraints? The reason I mention this
is while only enabling DSC when needed makes perfect sense for SST, since I'd
assume non-DSC consumes less power, it doesn't quite make sense for MST.
See: currently with MST (at least this is the case with i915, but I plan on
making it the case with nouveau as well), we always default to link training
at the maximum link rate/lane count. i915 does the opposite with SST for
optimization, but we maximize for MST because maximizing the amount of
bandwidth we have to work with means that we can enable new displays and
disable displays without having to potentially update the rest of the topology
with new PBN/VCPI allocations (unless the bandwidth restrictions get lowered
later, of course).
An abstract example: Let's say a user has a hub setup with two displays,
without DSC enabled. The user plugs in a third display, but this display won't
fit into the available bandwidth without enabling DSC. But assuming enabling
DSC causes us to need to recalculate the bandwidth for the other two displays,
we end up having to do a modeset on all three displays.
Alternatively: the user has two displays again. This time though we started
off by using DSC from the start, so adding a new display can be done without
performing a modeset on the other two displays.
Taking this into consideration, wouldn't we be able to just get rid of this
whole function by enabling DSC by default instead of as-needed? And get a
nicer result?
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: David Francis
>
> Whenever a connector on an MST network is attached, detached, or
> undergoes a modeset, the DSC configs for each stream on that
> topology will be recalculated. This can change their required
> bandwidth, requiring a full reprogramming, as though a modeset
> was performed, even if that stream did not change timing.
>
> Therefore, whenever a crtc has drm_atomic_crtc_needs_modeset,
> for each crtc that shares a MST topology with that stream and
> supports DSC, add that crtc (and all affected connectors and
> planes) to the atomic state and set mode_changed on its state
>
> v2: Do this check only on Navi and before adding connectors
> and planes on modesetting crtcs
>
> Cc: Leo Li
> Cc: Nicholas Kazlauskas
> Cc: Lyude Paul
> Signed-off-by: David Francis
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 79 +++
> 1 file changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ba017e6bf0b4..f65326e85b86 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6704,6 +6704,74 @@ static int do_aquire_global_lock(struct drm_device
> *dev,
> return ret < 0 ? ret : 0;
> }
>
> +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> +/*
> + * TODO: This logic should at some point be moved into DRM
> + */
> +static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_crtc_state *new_crtc_state;
> + struct amdgpu_dm_connector *aconnector = NULL, *aconnector_to_add;
> + int i, j;
> + struct drm_crtc *crtcs_affected[AMDGPU_MAX_CRTCS] = { 0 };
> +
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
> + if (conn_state->crtc != crtc)
> + continue;
> +
> + aconnector = to_amdgpu_dm_connector(connector);
> + if (!aconnector->port)
> + aconnector = NULL;
> + else
> + break;
> + }
> +
> + if (!aconnector)
> + return 0;
> +
> + i = 0;
> + drm_connector_list_iter_begin(state->dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + if (!connector->state || !connector->state->crtc)
> + continue;
> +
> + aconnector_to_add = to_amdgpu_dm_connector(connector);
> + if (!aconnector_to_add->port)
> + continue;
> +
> + if (aconnector_to_add->port->mgr != aconnector->port->mgr)
> + continue;
> +
> + if (!aconnector_to_add->dc_sink)
> + continue;
> +
> + if (!aconnector_to_add->dc_sink-
> >sink_dsc_caps.dsc_dec_caps.is_dsc_supported)
> + continue;
> +
> + if (i >= AMDGPU_MAX_CRTCS)
> + continue;
>
Re: [PATCH 08/15] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
Reviewed-by: Lyude Paul
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: David Francis
>
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This function
> finds the correct aux for the job.
>
> As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
> is a DP feature new in DP v1.4, which exposes certain DPCD
> registers on virtual ports.
>
> v2: Remember to unlock mutex on all paths
> v3: Refactor to match coding style and increase brevity
>
> Cc: Lyude Paul
> Cc: Jani Nikula
> Cc: Harry Wentland
> Reviewed-by: Wenjing Liu
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 127 ++
> include/drm/drm_dp_mst_helper.h | 2 +
> 2 files changed, 129 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ae2f986d76a2..dd2ca065cc92 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4147,3 +4147,130 @@ static void drm_dp_mst_unregister_i2c_bus(struct
> drm_dp_aux *aux)
> {
> i2c_del_adapter(>ddc);
> }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer
> Device
> + * @port: The port to check
> + *
> + * A single physical MST hub object can be represented in the topology
> + * by multiple branches, with virtual ports between those branches.
> + *
> + * As of DP1.4, An MST hub with internal (virtual) ports must expose
> + * certain DPCD registers over those ports. See sections 2.6.1.1.1
> + * and 2.6.1.1.2 of Display Port specification v1.4 for details.
> + *
> + * May acquire mgr->lock
> + *
> + * Returns:
> + * true if the port is a virtual DP peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port || port->dpcd_rev < DP_DPCD_REV_14)
> + return false;
> +
> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps)
> + return true;
> +
> + /* DP-to-DP */
> + mutex_lock(>mgr->lock);
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->mstb->num_ports == 2) {
> + list_for_each_entry(downstream_port, >mstb->ports, next)
> {
> + if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
> + !downstream_port->input) {
> + mutex_unlock(>mgr->lock);
> + return true;
> + }
> + }
> + }
> + mutex_unlock(>mgr->lock);
> +
> + return false;
> +}
> +
> +/**
> + * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
> + * @port: The port to check. A leaf of the MST tree with an attached
> display.
> + *
> + * Depending on the situation, DSC may be enabled via the endpoint aux,
> + * the immediately upstream aux, or the connector's physical aux.
> + *
> + * This is both the correct aux to read DSC_CAPABILITY and the
> + * correct aux to write DSC_ENABLED.
> + *
> + * This operation can be expensive (up to four aux reads), so
> + * the caller should cache the return.
> + *
> + * Returns:
> + * NULL if DSC cannot be enabled on this port, otherwise the aux device
> + */
> +struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port
> *port)
> +{
> + struct drm_dp_mst_port *immediate_upstream_port;
> + struct drm_dp_mst_port *fec_port;
> +
> + if (!port)
> + return NULL;
> +
> + if (port->parent)
> + immediate_upstream_port = port->parent->port_parent;
> + else
> + immediate_upstream_port = NULL;
> +
> + fec_port = immediate_upstream_port;
> + while (fec_port) {
> + /*
> + * Each physical link (i.e. not a virtual port) between the
> + * output and the primary device must support FEC
> + */
> + if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
> + !fec_port->fec_capable)
> + return NULL;
> +
> + fec_port = fec_port->parent->port_parent;
> + }
> +
> + /* DP-to-DP peer device */
> + if (drm_dp_mst_is_virtual_dpcd(immediate_upstream_port)) {
> + u8 upstream_dsc;
> + u8 endpoint_dsc;
> + u8 endpoint_fec;
> +
> + if (drm_dp_dpcd_read(>aux,
> + DP_DSC_SUPPORT, _dsc, 1) < 0)
> + return NULL;
> + if (drm_dp_dpcd_read(>aux,
> + DP_FEC_CAPABILITY, _fec, 1) < 0)
> +
Re: [PATCH 09/15] drm/dp_mst: Add new quirk for Synaptics MST hubs
Great work!
Reviewed-by: Lyude Paul
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: David Francis
>
> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
> support virtual DPCD registers, but do support DSC.
> The DSC caps can be read from the physical aux,
> like in SST DSC. These hubs have many different
> DEVICE_IDs. Add a new quirk to detect this case.
>
> Change-Id: I9d332f273dfca0cfbced111e62f5a06c5c312893
> Cc: Lyude Paul
> Cc: Jani Nikula
> Cc: Harry Wentland
> Reviewed-by: Wenjing Liu
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_helper.c | 4 +++-
> drivers/gpu/drm/drm_dp_mst_topology.c | 27 +++
> include/drm/drm_dp_helper.h | 7 +++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 0cbf10727bd6..c3e1da78e442 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1288,7 +1288,9 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> /* LG LP140WF6-SPM1 eDP panel */
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'),
> false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> /* Apple panels need some additional handling to support PSR */
> - { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> BIT(DP_DPCD_QUIRK_NO_PSR) }
> + { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> BIT(DP_DPCD_QUIRK_NO_PSR) },
> + /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> + { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index dd2ca065cc92..4e493d8af288 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4219,6 +4219,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> {
> struct drm_dp_mst_port *immediate_upstream_port;
> struct drm_dp_mst_port *fec_port;
> + struct drm_dp_desc desc = { 0 };
>
> if (!port)
> return NULL;
> @@ -4271,6 +4272,32 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> if (drm_dp_mst_is_virtual_dpcd(port))
> return >aux;
>
> + /*
> + * Synaptics quirk
> + * Applies to ports for which:
> + * - Physical aux has Synaptics OUI
> + * - DPv1.4 or higher
> + * - Port is on primary branch device
> + * - Not a VGA adapter (DP_DWN_STRM_PORT_TYPE_ANALOG)
> + */
> + if (!drm_dp_read_desc(port->mgr->aux, , true))
> + return NULL;
> +
> + if (drm_dp_has_quirk(, DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
> + port->mgr->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 &&
> + port->parent == port->mgr->mst_primary) {
> + u8 downstreamport;
> +
> + if (drm_dp_dpcd_read(>aux, DP_DOWNSTREAMPORT_PRESENT,
> + , 1) < 0)
> + return NULL;
> +
> + if ((downstreamport & DP_DWN_STRM_PORT_PRESENT) &&
> +((downstreamport & DP_DWN_STRM_PORT_TYPE_MASK)
> + != DP_DWN_STRM_PORT_TYPE_ANALOG))
> + return port->mgr->aux;
> + }
> +
> return NULL;
> }
> EXPORT_SYMBOL(drm_dp_mst_dsc_aux_for_port);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 6ae1a6765f63..919ad940bfb1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1414,6 +1414,13 @@ enum drm_dp_quirk {
>* driver still need to implement proper handling for such device.
>*/
> DP_DPCD_QUIRK_NO_PSR,
> + /**
> + * @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
> + *
> + * The device supports MST DSC despite not supporting Virtual DPCD.
> + * The DSC caps can be read from the physical aux instead.
> + */
> + DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
> };
>
> /**
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/15] drm/amdgpu: validate mst topology in atomic check
This also needs to be squashed into the previous two patches. There's no point
in using drm_dp_atomic_find_vcpi_slots() or drm_dp_atomic_release_vcpi_slots()
without drm_dp_mst_atomic_check(), since the VCPI allocations setup by the two
functions aren't validated until then.
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Validate mst topology and the number of VCPI slots available
> for a new state. Fail if topology has no more bandwidth for
> a new state.
> [how]
> Pass the atomic state to drm_dp_mst_atomic_check to verify
> if the new topology is possible.
>
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index d700b962d338..39c239a08633 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7485,6 +7485,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> if (ret)
> goto fail;
>
> + /* Perform validation of MST topology in the state*/
> + ret = drm_dp_mst_atomic_check(state);
> + if (ret)
> + goto fail;
> +
> if (state->legacy_cursor_update) {
> /*
>* This is a fast cursor update coming from the plane update
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 5.4-rc1
The pull request you sent on Fri, 20 Sep 2019 05:08:55 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-09-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/574cc4539762561d96b456dbc0544d8898bd4c6e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 02/15] drm/amdgpu: Add connector atomic check
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Complying with new MST atomic check requirements.
> The driver needs to call this function on every
> atomic check to reset the VCPI slots if new state
> disables
> [how]
> - Verify that it is a MST connection
> - Verify that old crtc state exists
> - Verify the new crtc state disables sink
> - Release VCPI slots on the port
>
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 34 +++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b59..4e1bbf5bbe77 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -252,10 +252,44 @@ static struct drm_encoder *dm_mst_best_encoder(struct
> drm_connector *connector)
> return _dm_connector->mst_encoder->base;
> }
>
> +static int dm_dp_mst_atomic_check(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state)
> +{
> + struct drm_atomic_state *state = new_conn_state->state;
> + struct drm_connector_state *old_conn_state =
> + drm_atomic_get_old_connector_state(state, connector);
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> +
> + if (!aconnector || !aconnector->port)
> + return 0;
Same as the last patch, I don't think you should need either of these checks.
Otherwise, assuming this gets squashed into the previous patch this looks fine
to me
> +
> + mst_port = aconnector->port;
> + mst_mgr = >mst_port->mst_mgr;
> +
> + if (!old_conn_state->crtc)
> + return 0;
> +
> + if (new_conn_state->crtc) {
> + new_crtc_state = drm_atomic_get_old_crtc_state(state,
> new_conn_state->crtc);
> + if (!new_crtc_state ||
> + !drm_atomic_crtc_needs_modeset(new_crtc_state) ||
> + new_crtc_state->enable)
> + return 0;
> + }
> +
> + return drm_dp_atomic_release_vcpi_slots(state,
> + mst_mgr,
> + mst_port);
> +}
> +
> static const struct drm_connector_helper_funcs
> dm_dp_mst_connector_helper_funcs = {
> .get_modes = dm_dp_mst_get_modes,
> .mode_valid = amdgpu_dm_connector_mode_valid,
> .best_encoder = dm_mst_best_encoder,
> + .atomic_check = dm_dp_mst_atomic_check,
> };
>
> static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 5.4-rc1
On Thu, Sep 19, 2019 at 12:09 PM Dave Airlie wrote:
>
> There are a few merge conflicts across the board, we have a shared
> rerere cache which meant I hadn't noticed them until I avoided the
> cache.
> https://cgit.freedesktop.org/drm/drm/log/?h=drm-5.4-merge
> contains what we've done, none of them are too crazy.
Hmm. My merge isn't identical to that. It's close though. Different
order for one #define which might be just from you and me merging
different directions.
But I also ended up removing the .gem_prime_export initialization to
drm_gem_prime_export, because it's the default if none exists. That's
the left-over from
3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
after the import stayed around because it got turned into an actually
non-default one.
I think that both of our merges are right - equivalent but just
slightly different.
But the reason I'm pointing this out is that I also get the feeling
that if it needs that dev->dev_private difference from the default
function in prime_import(), wouldn't it need the same for prime_export
too?
I don't know the code, and I don't know the hardware, but just from a
"pattern matching" angle I just wanted to check whether maybe there's
need for a mtk_drm_gem_prime_export() wrapper that does that same
thing with
struct mtk_drm_private *private = dev->dev_private;
.. use private->dev instead of dev->dev ..
So I'm just asking that somebody that knows that drm/mtk code should
double-check that oddity.
Thanks,
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-dkms-5.0 3698/3724] include/linux/dma-fence.h:508:20: sparse: the previous one is here
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: a51a5ad4b8daf0dd0a437d51a19c2baa98953675
commit: a5784d79d1577c00e6e81f892cde52593546a5f4 [3698/3724] drm/amdkcl: drop
kcl_dma_fence_set_error
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
git checkout a5784d79d1577c00e6e81f892cde52593546a5f4
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
include/kcl/kcl_fence.h:142:20: sparse: sparse: multiple definitions for
function 'dma_fence_set_error'
>> include/linux/dma-fence.h:508:20: sparse: the previous one is here
include/kcl/kcl_drm.h:167:1: sparse: sparse: multiple definitions for
function 'drm_fb_helper_remove_conflicting_pci_framebuffers'
include/drm/drm_fb_helper.h:641:1: sparse: the previous one is here
include/kcl/kcl_drm.h:390:28: sparse: sparse: redefinition of struct
drm_format_name_buf
vim +508 include/linux/dma-fence.h
d6c99f4bf093a5 Chris Wilson 2017-01-04 496
a009e975da5c7d Chris Wilson 2017-01-04 497 /**
a009e975da5c7d Chris Wilson 2017-01-04 498 * dma_fence_set_error - flag an
error condition on the fence
2c269b09065123 Daniel Vetter 2018-04-27 499 * @fence: the dma_fence
2c269b09065123 Daniel Vetter 2018-04-27 500 * @error: the error to store
a009e975da5c7d Chris Wilson 2017-01-04 501 *
a009e975da5c7d Chris Wilson 2017-01-04 502 * Drivers can supply an optional
error status condition before they signal
a009e975da5c7d Chris Wilson 2017-01-04 503 * the fence, to indicate that
the fence was completed due to an error
a009e975da5c7d Chris Wilson 2017-01-04 504 * rather than success. This must
be set before signaling (so that the value
a009e975da5c7d Chris Wilson 2017-01-04 505 * is visible before any waiters
on the signal callback are woken). This
a009e975da5c7d Chris Wilson 2017-01-04 506 * helper exists to help catching
erroneous setting of #dma_fence.error.
a009e975da5c7d Chris Wilson 2017-01-04 507 */
a009e975da5c7d Chris Wilson 2017-01-04 @508 static inline void
dma_fence_set_error(struct dma_fence *fence,
a009e975da5c7d Chris Wilson 2017-01-04 509
int error)
a009e975da5c7d Chris Wilson 2017-01-04 510 {
6ce31263c9758c Daniel Vetter 2017-07-20 511
WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
6ce31263c9758c Daniel Vetter 2017-07-20 512WARN_ON(error >= 0 || error <
-MAX_ERRNO);
a009e975da5c7d Chris Wilson 2017-01-04 513
a009e975da5c7d Chris Wilson 2017-01-04 514fence->error = error;
a009e975da5c7d Chris Wilson 2017-01-04 515 }
a009e975da5c7d Chris Wilson 2017-01-04 516
:: The code at line 508 was first introduced by commit
:: a009e975da5c7d42a7f5eaadc54946eb5f76c9af dma-fence: Introduce
drm_fence_set_error() helper
:: TO: Chris Wilson
:: CC: Sumit Semwal
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/15] drm/amdgpu: Add encoder atomic check
Ok, so reviewing this is kind of difficult because this series doesn't apply
to drm-tip, and also doesn't make any mention of what branch it's supposed to
apply to. So there's no way for me to apply any of these changes in my tree to
get an idea of how things look overall with these patches applied. Could you
please base the next series on top of drm-tip?
In the mean time, I've left as much feedback as I can below:
For starters, this patch should be combined with the next patch in the series
since you really can't use drm_dp_atomic_find_vcpi_slots() without using
drm_dp_atomic_release_vcpi_slots(). More down below
On Wed, 2019-09-18 at 16:26 -0400, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> In order to comply with new MST atomic check
> we have to find and add VCPI slots to the state
> during atomic check whenever their is a change on
> mode or connector.
> [how]
> - Verify that it is a MST connection
> - Convert new stream's clock and bpp
> - Calculate PBN based on stream parameters
> - Find and add VCPI slots to the state
>
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 7b0ca2e1ed8b..d700b962d338 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4432,6 +4432,65 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state
> *conn_state)
> {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + struct dm_crtc_state *dm_new_crtc_state =
> to_dm_crtc_state(crtc_state);
> + const struct drm_display_mode *adjusted_mode = _state-
> >adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + int pbn, slots,clock, bpp = 0;
> +
> + if (!dm_new_crtc_state)
> + return 0;
> +
> + if (!aconnector || !aconnector->port)
> + return 0;
...in what situation would aconnector ever be NULL? Same for aconnector->port,
the drm_dp_mst_port stays around until the drm_connector is destroyed.
> +
> + mst_port = aconnector->port;
> + mst_mgr = >mst_port->mst_mgr;
> +
> + if (!mst_mgr->mst_state)
> + return 0;
I'm confused here, what is the purpose of this check? mst_mgr->mst_state
shouldn't be touched directly ever, as it refers to the currently committed
mgr state. the way to retrieve the mgr's atomic state is:
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms-helpers.html#c.drm_atomic_get_mst_topology_state
Even then though, there's no actual need to grab the mst_state here manually.
drm_dp_atomic_find_vcpi_slots() does this for you
> +
> + if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> + return 0;
> +
> + switch (convert_color_depth_from_display_info(connector, conn_state))
> {
> + case COLOR_DEPTH_666:
> + bpp = 6;
> + break;
> + case COLOR_DEPTH_888:
> + bpp = 8;
> + break;
> + case COLOR_DEPTH_101010:
> + bpp = 10;
> + break;
> + case COLOR_DEPTH_121212:
> + bpp = 12;
> + break;
> + case COLOR_DEPTH_141414:
> + bpp = 14;
> + break;
> + case COLOR_DEPTH_161616:
> + bpp = 16;
> + break;
> + default:
> + ASSERT(bpp != 0);
> + break;
> + }
> +
> + bpp *= 3;
> + clock = adjusted_mode->clock;
> + pbn = drm_dp_calc_pbn_mode(clock, bpp);
I might have forgotten to mention this in the documentation (I'll double check
after sending this out and fix it if I did...), but it's a good idea to only
recalculate the PBN when !drm_atomic_state->duplicated. The reason for this is
that when we're resuming the system from S3, there's a chance that MST
topologies which were previously connected to the system might no longer be
present or may have changed.
When resuming from S3, or any other situation where the GPU needs to save and
restore it's atomic state, the general expectation is that the state that was
saved is basically identical to the state that was resumed since a different
state won't have the guarantee of passing the atomic check. An example
scenario (note that we don't reprobe topologies after resume yet, but we will
be doing this very soon):
* MST connector DP-4 starts off with a bpp of 8
* The GPU has a VCPI table that is currently full, and includes an active
allocation for DP-4.
*
Re: [PATCH v2] drm/amd/display: fix struct init in update_bounding_box
On Wed, Aug 28, 2019 at 2:51 PM Raul E Rangel wrote:
>
> dcn20_resource.c:2636:9: error: missing braces around initializer
> [-Werror=missing-braces]
> struct _vcs_dpi_voltage_scaling_st
> calculated_states[MAX_CLOCK_LIMIT_STATES] = {0};
> ^
> Fixes: 7ed4e6352c16f ("drm/amd/display: Add DCN2 HW Sequencer and Resource")
>
> Signed-off-by: Raul E Rangel
> ---
> So apparently `{}` is a gcc extension. The C standard requires at least
> one expression. So {{0}} is correct. I got a lint error about {{0}}
> needing a space, so i use `{ {0} }`.
I think there were issues with {{}} as well. How about just a memset?
Alex
>
> Changes in v2:
> - Use { {0} } instead of {}
>
> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index b949e202d6cb..8e6433be2252 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -2633,7 +2633,7 @@ static void cap_soc_clocks(
> static void update_bounding_box(struct dc *dc, struct
> _vcs_dpi_soc_bounding_box_st *bb,
> struct pp_smu_nv_clock_table *max_clocks, unsigned int
> *uclk_states, unsigned int num_states)
> {
> - struct _vcs_dpi_voltage_scaling_st
> calculated_states[MAX_CLOCK_LIMIT_STATES] = {0};
> + struct _vcs_dpi_voltage_scaling_st
> calculated_states[MAX_CLOCK_LIMIT_STATES] = { {0} };
> int i;
> int num_calculated_states = 0;
> int min_dcfclk = 0;
> --
> 2.23.0.187.g17f5b7556c-goog
>
> ___
> 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
[Bug 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 Michael Haworth changed: What|Removed |Added Summary|hardware cursor corruption |inconsistent cursor |w/ AMD 5700 XT |movement speed when using ||AMD 5700 XT -- 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 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 --- Comment #14 from Mirek Kratochvil (exa@gmail.com) --- Created attachment 285069 --> https://bugzilla.kernel.org/attachment.cgi?id=285069=edit syslog from 5.2.16 with warnings -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Use vi plane as primary
Dne četrtek, 19. september 2019 ob 22:03:26 CEST je Roman Stratiienko napisal(a): > Hello guys, > > Actually, I beleive this is True solution, and current one is wrong. Let > me explain why. > > De2. 0 was designed to match Android hwcomposer hal requirements IMO. > You can easily agree with this conclusion by comparing Composer HAL and > De2. 0 hardware manuals. > > I faced at least 4 issues when try to run Android using the mainline kernel > sun8i mixer implementation. Current one, missing pixel formats (my previous > patch), missing plane alpha and rotation properties. I plan to fix it and > also send appropriate solution to the upstream. Android and mainline Linux don't have necessarily same view how things should work. Check how different Android version of Linux kernel was in the past. Fortunately, they are converging now. While I agree that HW was probably designed with Android in mind, that doesn't mean that Android way is the best or only way of doing things. Android can afford a lot of non-intuitive things because it's closed system and all IP cores are used only in certain ways. You can't say that for general Linux distro. Would you say that advertising formats with alpha support is correct thing to do if alpha blending is not supported? Put aside the fact that it makes it easier to implement Android features for you and imagine some app which finds first available overlay plane with ARGB support. It puts it on top with zpos property and gives it some transparent image. If that plane is VI, it would look wrong and users would complain. At the end, it's not apps fault to expect that if plane advertises format with alpha channel actually supports transparency. Regarding rotation, that core is not part of display pipeline. It takes one buffer and writes transformed (rotated in this case) image to output buffer. This principle is very definition of V4L2 M2M framework and should be handled by it. > > To achieve optimal UI performance Android requires at least 4 ui layers to > make screen composition. Current patch enables 4th plane usable. Ah, your idea is to pretend that VI planes supports all features of UI planes while in fact they not? > > As for using vi plane to display video. I assume that some of current users > may have regression in their software, but it could be easily fixed. For > example if vi layer isn't fullscreen and should be on top of the other > layers, it can actually be placed on the bottom and overlayed with pictures > with transparent rectangles in video region. This idea is imposible to implement if VI plane becomes primary plane. Apps wouldn't find overlay plane which suports YUV buffers and only one which does, it's already taken by window manager for rendering windows. Best regards, Jernej > But I assume most of users such as browser etc. uses GPU for that. > > And if you are watching fullscreen video, I can imagine only subtitles > layer and advertizing layers on top of the video layers. > > чт, 19 сент. 2019 г., 21:15 Jernej Škrabec : > > Dne četrtek, 19. september 2019 ob 19:17:54 CEST je Maxime Ripard > > > > napisal(a): > > > Hi, > > > > > > On Thu, Sep 19, 2019 at 03:37:03PM +0300, > > > > roman.stratiie...@globallogic.com > > > > wrote: > > > > From: Roman Stratiienko > > > > > > > > DE2.0 blender does not take into the account alpha channel of vi > > > > layer. > > > > Thus makes overlaying of this layer totally opaque. > > > > Using vi layer as bottom solves this issue. > > > > What issue? Overlays don't have to be "full screen", thus missing support > > for > > alpha blending doesn't make it less valuable. And VI planes are already > > placed > > at the bottom (zpos = 0). > > > > > > Tested on Android. > > > > > > > > Signed-off-by: Roman Stratiienko > > > > > > It sounds like a workaround more than an actual fix. > > > > > > If the VI planes can't use the alpha, then we should just stop > > > reporting that format. > > > > > > Jernej, what do you think? > > > > Commit message is misleading. What this commit actually does is moving > > primary > > plane from first UI plane to bottom most plane, i.e. first VI plane. > > However, VI > > planes are scarce resource, almost all mixers have only one. I wouldn't > > set it > > as primary, because it's the only one which provide support for YUV > > formats. > > That could be used for example by video player for zero-copy rendering. > > Probably most apps wouldn't touch it if it was primary (that's usually > > reserved for window manager, if used). > > > > I left few formats with alpha channel exposed by VI planes, just because > > they > > don't have equivalent format without alpha. But I'm fine with removing > > them if > > you all agree on that. > > > > Best regards, > > Jernej > > > > > Maxime > > > > > > > --- > > > > > > > > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 33 --- > > > > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 > > > >
[Bug 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 --- Comment #13 from Mirek Kratochvil (exa@gmail.com) --- After the BIOS upgrade the kernel parameters can be removed, but the kernel (5.2.16) now locks up when entering XFCE (it survives lightdm though). The error is almost same as as in the posted dmesg; I'll attach mine with backtraces in a few seconds. Highlights: This gets printed out before each warning: [ 66.159175] [drm] pstate TEST_DEBUG_DATA: 0x36F6 R08 gets increased by some value between 49 and 56 after each next warning (the value is sometimes in R10) Userspace seems working otherwise (the logs are from syslog), just the display won't show anything. I will try a few other kernels available for debian and eventually bisect. -- 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 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #10 from Michael Haworth --- issue occurs with the closed source drivers too, on kernel 4.15 (linux mint 19.2) but to a much lesser extent -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix a potential NULL pointer dereference
On 2019-09-18 12:30 p.m., Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> index c56ac47..caa82a8 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> @@ -62,6 +62,11 @@ int kfd_interrupt_init(struct kfd_dev *kfd)
> }
>
> kfd->ih_wq = alloc_workqueue("KFD IH", WQ_HIGHPRI, 1);
> + if (unlikely(!kfd->ih_wq)) {
> + fifo_free(>ih_fifo);
This does not compile. I think this should be kfifo_free.
> + dev_err(kfd_chardev(), "Failed to allocate KFD IH workqueue\n");
> + return kfd->ih_wq;
This throws a compiler warning "return makes integer from pointer
without a cast". What's worse, kfd->ih_wq is NULL here and
kfd_interrupt_init returns 0 to mean success, so returning a NULL
pointer is definitely not what you want here. This function should
return a negative error code on failure. I propose -ENOMEM.
I'm going to apply your patch with those fixes.
Regards,
Felix
> + }
> spin_lock_init(>interrupt_lock);
>
> INIT_WORK(>interrupt_work, interrupt_wq);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111633] amdgpu driver crash with kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=111633 --- Comment #1 from vakevk+freedesktopbugzi...@gmail.com --- Another one, different stacktrace. BUG: kernel NULL pointer dereference, address: 0360 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 4 PID: 28005 Comm: kworker/u16:1 Not tainted 5.2.14-arch1-1-ARCH #1 Hardware name: ASUS All Series/Z87-PLUS, BIOS 2103 08/15/2014 Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dc_stream_retain+0x5/0x20 [amdgpu] Call Trace: dc_resource_state_copy_construct+0xa0/0xf0 [amdgpu] dc_commit_updates_for_stream+0xa63/0xc20 [amdgpu] amdgpu_dm_atomic_commit_tail+0xabe/0x19a0 [amdgpu] ? commit_tail+0x3c/0x70 [drm_kms_helper] commit_tail+0x3c/0x70 [drm_kms_helper] process_one_work+0x1d1/0x3e0 worker_thread+0x4a/0x3d0 kthread+0xfb/0x130 ? process_one_work+0x3e0/0x3e0 ? kthread_park+0x80/0x80 ret_from_fork+0x35/0x40 Modules linked in: tun nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nf_tables_set cfg80211 8021q garp mrp nf_tables stp llc nfnetlink intel_rapl ofpart nls_iso8859_1 nls_cp437 cmdlinepart vfat intel_spi_platform fat fuse intel_spi mei_hdcp spi_nor iTCO_wdt x86_pkg_temp_thermal mtd iTCO_vendor_support intel_powerclamp uvcvideo coretemp videobuf2_vmalloc kvm_intel btusb snd_hda_codec_realtek videobuf2_memops btrtl btbcm snd_hda_codec_generic videobuf2_v4l2 btintel ledtrig_audio snd_hda_codec_hdmi videobuf2_common bluetooth eeepc_wmi kvm snd_usb_audio snd_hda_intel videodev asus_wmi snd_hda_codec sparse_keymap wmi_bmof snd_usbmidi_lib mxm_wmi irqbypass snd_hda_core snd_rawmidi snd_hwdep snd_seq_device intel_cstate ecdh_generic snd_pcm intel_uncore mei_me i2c_i801 snd_timer intel_rapl_perf rfkill snd pcspkr media cdc_acm pcc_cpufreq mousedev ecc joydev e1000e input_leds soundcore mei lpc_ich evdev mac_hid wmi ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 hid_generic usbhid hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ahci libahci aesni_intel libata aes_x86_64 crypto_simd xhci_pci cryptd scsi_mod glue_helper xhci_hcd ehci_pci ehci_hcd amdgpu gpu_sched i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart CR2: 0360 ---[ end trace 3b3265e8a1ad7f82 ]--- -- 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 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 Matt Turner changed: What|Removed |Added CC|matts...@gmail.com | --- Comment #44 from Matt Turner --- (In reply to rol...@rptd.ch from comment #43) > Sorry, but this is rude. I waited for an answer on my result of testing the > patch (as requested) and that's what I get as answer? I can continue trying > to find a reproducible task but then please say that you acknowledged my > finding so I can continue in a helpful way. Huh? Thanks for testing, but I'm just informing you now that the stab-in-the-dark attempted fix didn't solve it that you're probably not going to see this fixed unless you can find a way for developers to reproduce. I'm not sure why you think that's rude. And honestly I've spent s much time trying to help you and it's been *painful* at every step. I've done this kind of triage for 10 years and I don't remember a more frustrating experience helping a user. I'm un'Cc'ing myself since I don't work on this driver and I feel that my time is better spent elsewhere. Best of luck. -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #52 from Matthias Müller --- Comment on attachment 145436 --> https://bugs.freedesktop.org/attachment.cgi?id=145436 Log of divide error i just encountered a "random" freeze, too. And because it seems to be something "new", i thought i'd post it here - seems to be some kind of null pointer from what i found? -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #51 from Matthias Müller --- Created attachment 145436 --> https://bugs.freedesktop.org/attachment.cgi?id=145436=edit Log of divide error -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/v3d: clean caches at the end of render jobs on request from user space
Iago Toral Quiroga writes: > Extends the user space ioctl for CL submissions so it can include a request > to flush the cache once the CL execution has completed. Fixes memory > write violation messages reported by the kernel in workloads involving > shader memory writes (SSBOs, shader images, scratch, etc) which sometimes > also lead to GPU resets during Piglit and CTS workloads. > > v2: if v3d_job_init() fails we need to kfree() the job instead of > v3d_job_put() it (Eric Anholt). > > v3 (Eric Anholt): > - Drop _FLAG suffix from the new flag name. > - Add a new param so userspace can tell whether cache flushing is > implemented in the kernel. Appled to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/8] drm: Rename HDMI colorspace property creation function
As between HDMI and DP have different colorspaces, in order to distinguish
colorspace of DP and HDMI, it renames drm_mode_create_colorspace_property()
function to drm_mode_create_hdmi_colorspace_property() function for HDMI
connector.
In order to apply changed drm api, i915 driver has channged.
It addresses review comments from Ville.
- Split hunk into renaming and adding of code.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_connector.c | 39 +++
.../gpu/drm/i915/display/intel_connector.c| 2 +-
include/drm/drm_connector.h | 2 +-
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4410939a088d..14a94a100cb0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1667,7 +1667,6 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* DOC: standard connector properties
*
* Colorspace:
- * drm_mode_create_colorspace_property - create colorspace property
* This property helps select a suitable colorspace based on the sink
* capability. Modern sink devices support wider gamut like BT2020.
* This helps switch to BT2020 mode if the BT2020 encoded video stream
@@ -1687,32 +1686,38 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* - This property is just to inform sink what colorspace
*source is trying to drive.
*
+ * Because between HDMI and DP have different colorspaces,
+ * drm_mode_create_hdmi_colorspace_property() is used for HDMI connector.
+ */
+
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
* Called by a driver the first time it's needed, must be attached to desired
- * connectors.
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errono on failure.
*/
-int drm_mode_create_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
- if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
- connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
- prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
- "Colorspace",
- hdmi_colorspaces,
- ARRAY_SIZE(hdmi_colorspaces));
- if (!prop)
- return -ENOMEM;
- } else {
- DRM_DEBUG_KMS("Colorspace property not supported\n");
+ if (connector->colorspace_property)
return 0;
- }
- connector->colorspace_property = prop;
+ connector->colorspace_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+hdmi_colorspaces,
+ARRAY_SIZE(hdmi_colorspaces));
+
+ if (!connector->colorspace_property)
+ return -ENOMEM;
return 0;
}
-EXPORT_SYMBOL(drm_mode_create_colorspace_property);
+EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
/**
* drm_mode_create_content_type_property - create content type property
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 308ec63207ee..ba2ef165a01a 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -277,7 +277,7 @@ intel_attach_aspect_ratio_property(struct drm_connector
*connector)
void
intel_attach_colorspace_property(struct drm_connector *connector)
{
- if (!drm_mode_create_colorspace_property(connector))
+ if (!drm_mode_create_hdmi_colorspace_property(connector))
drm_object_attach_property(>base,
connector->colorspace_property, 0);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c6e993e78dbd..48ffed064487 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1523,7 +1523,7 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
-int drm_mode_create_colorspace_property(struct drm_connector *connector);
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector);
int drm_mode_create_content_type_property(struct drm_device *dev);
void drm_hdmi_avi_infoframe_content_type(struct hdmi_avi_infoframe *frame,
const struct drm_connector_state
*conn_state);
--
2.23.0
[PATCH v9 0/8] drm/i915/dp: Support for DP HDR outputs
Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] v4: - Add additional comments to struct drm_prop_enum_list. - Polishing an enum string of struct drm_prop_enum_list. v5: - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. - Add missed variables on dp_colorspaces. - Fix typo. [Uma] v6: - Addressed review comments from Ilia and Ville Split drm_mode_create_colorspace_property() to DP and HDMI connector. Becasue between HDMI and DP have different colorspaces, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. And it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. In order to apply changed and added drm api, i915 driver has channged. v7: - Fix typo [Jani Saarinen] - Fix white space. v8: - Addressed review comments from Ville Drop colorimetries which have another way to distinguish or which would not be used. v9: - Addressed review comments from Ville - Remove a duplicated output color space from intel_crtc_state. - In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp() - Split hunk into renaming and adding of code. - Add a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). - Add WARN_ON() when buffer size if larger than register size. - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. - Change a passed size toward write_infoframe() for DP infoframe sdp packet for HDR static metadata. Gwan-gyeong Mun (8): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Rename HDMI colorspace property creation function drm: Add DisplayPort colorspace property creation function drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 101 +++-- .../gpu/drm/i915/display/intel_connector.c| 21 +- drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 1 - drivers/gpu/drm/i915/display/intel_display.h | 2 - drivers/gpu/drm/i915/display/intel_dp.c | 196 -- drivers/gpu/drm/i915/display/intel_dp.h | 8 + drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 7 +- 11 files changed, 323 insertions(+), 46 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCH v9 4/8] drm: Add DisplayPort colorspace property creation function
Because between HDMI and DP have different colorspaces, it adds
drm_mode_create_dp_colorspace_property() function for creating of DP
colorspace property.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.
v4: Add additional comments to struct drm_prop_enum_list.
Polishing an enum string of struct drm_prop_enum_list
v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
DP abbreviations.
Add missed variables on dp_colorspaces.
Fix typo. [Uma]
v6: Addressed review comments from Ilia and Ville
- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
v7: Fix typo [Jani Saarinen]
Fix white space.
v8: Addressed review comments from Ville
- Drop colorimetries which have another way to distinguish or which
would not be used.
v9: Addressed review comments from Ville
- Split hunk into renaming and adding of code.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 64 -
include/drm/drm_connector.h | 5 +++
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 14a94a100cb0..0965632008a9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -875,6 +875,38 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+/*
+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
+ * Format Table 2-120
+ */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
+ /* Colorimetry based on scRGB (IEC 61966-2-2) */
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
},
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on SMPTE RP 431-2 */
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+ { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1687,7 +1719,8 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
*source is trying to drive.
*
* Because between HDMI and DP have different colorspaces,
- * drm_mode_create_hdmi_colorspace_property() is used for HDMI connector.
+ * drm_mode_create_hdmi_colorspace_property() is used for HDMI connector and
+ * drm_mode_create_dp_colorspace_property() is used for DP connector.
*/
/**
@@ -1719,6 +1752,35 @@ int drm_mode_create_hdmi_colorspace_property(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
+/**
+ * drm_mode_create_dp_colorspace_property - create dp colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * DP connectors.
+ *
+ * Returns:
+ * Zero on success, negative errono on failure.
+ */
+int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+
+ if (connector->colorspace_property)
+ return 0;
+
+ connector->colorspace_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+dp_colorspaces,
+ARRAY_SIZE(dp_colorspaces));
+
+ if (!connector->colorspace_property)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
+
/**
* drm_mode_create_content_type_property - create content type property
* @dev: DRM device
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 48ffed064487..5f8c3389d46f 100644
---
[PATCH v9 8/8] drm/i915/dp: Attach HDR metadata property to DP connector
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 961279bb4a74..57d786df28bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6542,6 +6542,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_colorspace_property(connector);
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property,
+ 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 7/8] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.
Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register
size.
Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
++---+
| [ Packet Type Value ] | [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
| [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++
v2: Add a missed blank line after function declaration.
v3: Remove not handled return values from
intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
v9: Addressed review comments from Ville.
- Add BUILD_BUG_ON to check a changing of struct dp_sdp size.
- Change a passed size toward write_infoframe() for DP infoframe sdp
packet for HDR static metadata.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 92
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d2a1bfa6a259..5654fe596ba5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3628,6 +3628,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1f7d69e74850..961279bb4a74 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4599,6 +4599,86 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
}
+static void
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct dp_sdp infoframe_sdp = {};
+ struct hdmi_drm_infoframe drm_infoframe = {};
+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
HDMI_DRM_INFOFRAME_SIZE;
+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+ ssize_t len;
+ int ret;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+ if (ret) {
+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ return;
+ }
+
+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+ if (len < 0) {
+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
infoframe\n");
+ return;
+ }
+
+ if (len != infoframe_size) {
+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+ return;
+ }
+
+ /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+ /* Packet ID, 00h for non-Audio INFOFRAME */
+ infoframe_sdp.sdp_header.HB0 = 0;
+ /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+
[PATCH v9 2/8] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. In order to handle colorspace of
drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings()
function into intel_ddi_pre_enable_dp(). And it also rename
intel_ddi_set_pipe_settings() to intel_ddi_set_dp_msa().
As per DP 1.4a spec section 2.2.4 [MSA Data Transport]
The MSA data that the DP Source device transports for reproducing the main
video stream. Attribute data is sent once per frame during the main video
stream’s vertical blanking period.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
v2: Remove useless parentheses
v3: Addressed review comments from Ville
- In order to checking output format and output colorspace on
intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state struct
value.
- Remove a pointless variable.
v9: Addressed review comments from Ville
- Remove a duplicated output color space from intel_crtc_state.
- In order to handle colorspace of drm_connector_state, it moves a
calling of intel_ddi_set_pipe_settings() function into
intel_ddi_pre_enable_dp().
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 14 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 1 -
drivers/gpu/drm/i915/display/intel_dp.c | 29 +++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
5 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 98d69febd8e3..d2a1bfa6a259 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1692,7 +1692,8 @@ static void intel_ddi_clock_get(struct intel_encoder
*encoder,
hsw_ddi_clock_get(encoder, pipe_config);
}
-void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
+void intel_ddi_set_dp_msa(const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1737,11 +1738,12 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
*/
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (intel_dp_needs_vsc_sdp(crtc_state, conn_state))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
@@ -3370,6 +3372,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
tgl_ddi_pre_enable_dp(encoder, crtc_state, conn_state);
else
hsw_ddi_pre_enable_dp(encoder, crtc_state, conn_state);
+
+ intel_ddi_set_dp_msa(crtc_state, conn_state);
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
@@ -3781,7 +3785,7 @@ static void intel_ddi_update_pipe_dp(struct intel_encoder
*encoder,
{
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
- intel_ddi_set_pipe_settings(crtc_state);
+ intel_ddi_set_dp_msa(crtc_state, conn_state);
intel_psr_update(intel_dp, crtc_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index a08365da2643..19aeab1246ee 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -30,7 +30,8 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
*crtc_state);
void intel_ddi_enable_pipe_clock(const struct intel_crtc_state *crtc_state);
void intel_ddi_disable_pipe_clock(const struct intel_crtc_state *crtc_state);
-void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state);
+void intel_ddi_set_dp_msa(const struct intel_crtc_state *crtc_state,
+
[PATCH v9 5/8] drm/i915/dp: Attach colorspace property
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
And in order to distinguish colorspace bwtween DP and HDMI connector, it
adds a handling of drm_mode_create_dp_colorspace_property() to
intel_attach_colorspace_property().
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.
v9: Addressed review comments from Ville
- Add a handling of drm_mode_create_dp_colorspace_property() to
intel_attach_colorspace_property(). This hunk moved from the previous
commit.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
.../gpu/drm/i915/display/intel_connector.c| 21 ---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index ba2ef165a01a..1133c4e97bb4 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -277,7 +277,22 @@ intel_attach_aspect_ratio_property(struct drm_connector
*connector)
void
intel_attach_colorspace_property(struct drm_connector *connector)
{
- if (!drm_mode_create_hdmi_colorspace_property(connector))
- drm_object_attach_property(>base,
- connector->colorspace_property, 0);
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ if (drm_mode_create_hdmi_colorspace_property(connector))
+ return;
+ break;
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ if (drm_mode_create_dp_colorspace_property(connector))
+ return;
+ break;
+ default:
+ DRM_DEBUG_KMS("Colorspace property not supported\n");
+ return;
+ }
+
+ drm_object_attach_property(>base,
+ connector->colorspace_property, 0);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f13892deafbb..1f7d69e74850 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6448,6 +6448,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 6/8] drm/i915: Add new GMP register size for GEN11
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.
v9: Add WARN_ON() when buffer size if larger than register size. [Ville]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 ++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 14e350f5ecc8..ba6535a6502f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
}
-static int hsw_dip_data_size(unsigned int type)
+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
+unsigned int type)
{
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_VSC_DATA_SIZE;
case DP_SDP_PPS:
return VIDEO_DIP_PPS_DATA_SIZE;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ if (INTEL_GEN(dev_priv) >= 11)
+ return VIDEO_DIP_GMP_DATA_SIZE;
+ else
+ return VIDEO_DIP_DATA_SIZE;
default:
return VIDEO_DIP_DATA_SIZE;
}
@@ -514,7 +520,9 @@ static void hsw_write_infoframe(struct intel_encoder
*encoder,
int i;
u32 val = I915_READ(ctl_reg);
- data_size = hsw_dip_data_size(type);
+ data_size = hsw_dip_data_size(dev_priv, type);
+
+ WARN_ON(len > data_size);
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e3a6178aff4..9275b67faf3f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4677,6 +4677,7 @@ enum {
* (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_GMP_DATA_SIZE 36
#define VIDEO_DIP_VSC_DATA_SIZE 36
#define VIDEO_DIP_PPS_DATA_SIZE 132
#define VIDEO_DIP_CTL _MMIO(0x61170)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/8] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.
Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 68
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
4 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e6394139964..98d69febd8e3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3623,7 +3623,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+ intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index b1ae0e59c715..dc987e09aa05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -531,8 +531,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ccaf9f00b747..9023609c5dcb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,8 +4449,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
}
static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4471,13 +4472,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp
*intel_dp,
*/
vsc_sdp.sdp_header.HB3 = 0x13;
- /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
- vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+ /* DP 1.4a spec, Table 2-120 */
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ default:
+ /* RGB: DB16[7:4] = 0h */
+ break;
+ }
+
+ switch (conn_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ vsc_sdp.db[16] |= 0x1;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ vsc_sdp.db[16] |= 0x2;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ vsc_sdp.db[16] |= 0x3;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ vsc_sdp.db[16] |= 0x4;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ vsc_sdp.db[16] |= 0x5;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ vsc_sdp.db[16] |= 0x6;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ vsc_sdp.db[16] |= 0x7;
+ break;
+ case
Re: [PATCH v8 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
On Wed, 2019-09-18 at 17:13 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:49AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles
> > Infoframe SDP
> > header and data block setup for HDR Static Metadata. It enables
> > writing of
> > HDR metadata infoframe SDP to panel. Support for HDR video was
> > introduced
> > in DisplayPort 1.4. It implements the CTA-861-G standard for
> > transport of
> > static HDR metadata. The HDR Metadata will be provided by userspace
> > compositors, based on blending policies and passed to the driver
> > through
> > a blob property.
> >
> > Because each of GEN11 and prior GEN11 have different register size
> > for
> > HDR Metadata Infoframe SDP packet, it adds and uses different
> > register
> > size.
> >
> > Setup Infoframe SDP header and data block in function
> > intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata
> > as per
> > dp 1.4 spec and CTA-861-F spec.
> > As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range
> > and
> > Mastering Infoframe for HDR content, which is defined in CTA-861-F
> > spec.
> > According to DP 1.4 spec and CEA-861-F spec Table 5, in order to
> > transmit
> > static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
> >
> > ++---+
> > > [ Packet Type Value ] | [ Packet Type ] |
> > ++---+
> > > 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
> > ++---+
> > > [Transmission Timing] |
> > ++
> > > As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
> > > which Dynamic Range and Mastering INFOFRAME are defined|
> > ++
> >
> > v2: Add a missed blank line after function declaration.
> > v3: Remove not handled return values from
> > intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 89
> >
> > drivers/gpu/drm/i915/display/intel_dp.h | 3 +
> > 3 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 8dc030650801..306f6f9f0204 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3625,6 +3625,7 @@ static void intel_enable_ddi_dp(struct
> > intel_encoder *encoder,
> > intel_edp_backlight_on(crtc_state, conn_state);
> > intel_psr_enable(intel_dp, crtc_state);
> > intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
> > + intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
> > intel_edp_drrs_enable(intel_dp, crtc_state);
> >
> > if (crtc_state->has_audio)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 7fe22b37474d..abbf1d5c54c4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4599,6 +4599,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp
> > *intel_dp,
> > crtc_state, DP_SDP_VSC, _sdp,
> > sizeof(vsc_sdp));
> > }
> >
> > +static void
> > +intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp
> > *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + const struct
> > drm_connector_state *conn_state)
> > +{
> > + struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > + struct drm_i915_private *dev_priv = to_i915(intel_dig_port-
> > >base.base.dev);
> > + struct dp_sdp infoframe_sdp = {};
> > + struct hdmi_drm_infoframe drm_infoframe = {};
> > + const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE;
> > + unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE];
> > + ssize_t len;
> > + int ret;
> > +
> > + ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe,
> > conn_state);
> > + if (ret) {
> > + DRM_DEBUG_KMS("couldn't set HDR metadata in
> > infoframe\n");
> > + return;
> > + }
> > +
> > + len = hdmi_drm_infoframe_pack_only(_infoframe, buf,
> > sizeof(buf));
> > + if (len < 0) {
> > + DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
> > infoframe\n");
> > + return;
> > + }
> > +
> > + if (len != infoframe_size) {
> > + DRM_DEBUG_KMS("wrong static hdr metadata size\n");
> > + return;
> > + }
> > +
> > + /*
> > +* Set up the infoframe sdp packet
Re: [PATCH v8 3/7] drm: Add DisplayPort colorspace property
On Wed, 2019-09-18 at 17:08 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:46AM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property() function for HDMI
> > connector.
> > And it adds drm_mode_create_dp_colorspace_property() function for
> > creating
> > of DP colorspace property.
> > In order to apply changed and added drm api, i915 driver has
> > channged.
> >
> > v3: Addressed review comments from Ville
> > - Add new colorimetry options for DP 1.4a spec.
> > - Separate set of colorimetry enum values for DP.
> > v4: Add additional comments to struct drm_prop_enum_list.
> > Polishing an enum string of struct drm_prop_enum_list
> > v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI
> > prefix and
> > DP abbreviations.
> > Add missed variables on dp_colorspaces.
> > Fix typo. [Uma]
> > v6: Addressed review comments from Ilia and Ville
> >- Split drm_mode_create_colorspace_property() to DP and HDMI
> > connector.
> > v7: Fix typo [Jani Saarinen]
> > Fix white space.
> > v8: Addressed review comments from Ville
> >- Drop colorimetries which have another way to distinguish or
> > which
> > would not be used.
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_connector.c | 101
> > +++---
> > .../gpu/drm/i915/display/intel_connector.c| 21 +++-
>
> The i915 part shouldn't be here. Looks like you can just move that
> hunk into the next patch.
>
Okay, I'll split hunk into renaming and adding of code.
> > include/drm/drm_connector.h | 7 +-
> > 3 files changed, 108 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 4c766624b20d..57c97949081a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -882,6 +882,38 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater"
> > },
> > };
> >
> > +/*
> > + * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
> > Encoding/Colorimetry
> > + * Format Table 2-120
> > + */
> > +static const struct drm_prop_enum_list dp_colorspaces[] = {
> > + /* For Default case, driver will set the colorspace */
> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> > + { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED,
> > "RGB_Wide_Gamut_Fixed_Point" },
> > + /* Colorimetry based on scRGB (IEC 61966-2-2) */
> > + { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT,
> > "RGB_Wide_Gamut_Floating_Point" },
> > + /* Colorimetry based on IEC 61966-2-5 */
> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> > + /* Colorimetry based on SMPTE RP 431-2 */
> > + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > + { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> > + { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> > + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> > + /* Colorimetry based on IEC 61966-2-5 [33] */
> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > +};
> > +
> > /**
> > * DOC: standard connector properties
> > *
> > @@ -1674,7 +1706,6 @@
> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> > - * drm_mode_create_colorspace_property - create colorspace
> > property
> > * This property helps select a suitable colorspace based on
> > the sink
> > * capability. Modern sink devices support wider gamut like
> > BT2020.
> > * This helps switch to BT2020 mode if the BT2020 encoded
> > video stream
> > @@ -1694,32 +1725,68 @@
> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> > * - This property is just to inform sink what colorspace
> > *source is trying to drive.
> > *
> > + * Because between HDMI and DP have different colorspaces,
> > + * drm_mode_create_hdmi_colorspace_property() is used for HDMI
> > connector and
> > + * drm_mode_create_dp_colorspace_property() is used for DP
> > connector.
> > + */
> > +
> > +/**
> > + * drm_mode_create_hdmi_colorspace_property - create hdmi
> >
Re: [PATCH v8 2/7] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
On Wed, 2019-09-18 at 17:15 +0300, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 10:11:45AM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct as a place holder of pipe's output
> > colorspace.
> > In order to distinguish needed colorimetry for VSC SDP, it adds
> > intel_dp_needs_vsc_sdp function.
> > If the output colorspace requires vsc sdp or output format is YCbCr
> > 4:2:0,
> > it uses MSA with VSC SDP.
> >
> > As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
> > Color Encoding Format and Content Color Gamut] while sending
> > BT.2020 Colorimetry signals we should program MSA MISC1 fields
> > which
> > indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> >
> > v2: Remove useless parentheses
> > v3: Addressed review comments from Ville
> > - In order to checking output format and output colorspace on
> > intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state
> > struct
> > value.
> > - Remove a pointless variable.
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++--
> > .../drm/i915/display/intel_display_types.h| 3 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 29
> > ++-
> > drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> > 4 files changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 98d69febd8e3..8dc030650801 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1737,11 +1737,12 @@ void intel_ddi_set_pipe_settings(const
> > struct intel_crtc_state *crtc_state)
> > /*
> > * As per DP 1.4a spec section 2.2.4.3 [MSA Field for
> > Indication
> > * of Color Encoding Format and Content Color Gamut] while
> > sending
> > -* YCBCR 420 signals we should program MSA MISC1 fields which
> > -* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> > +* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1
> > fields
> > +* which indicate VSC SDP for the Pixel Encoding/Colorimetry
> > Format.
> > */
> > - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > + if (intel_dp_needs_vsc_sdp(crtc_state))
> > temp |= TRANS_MSA_USE_VSC_SDP;
> > +
> > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index d5cc4b810d9e..4108570907d4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -971,6 +971,9 @@ struct intel_crtc_state {
> > /* Output format RGB/YCBCR etc */
> > enum intel_output_format output_format;
> >
> > + /* Output colorspace sRGB/BT.2020 etc */
> > + u32 output_colorspace;
>
> Why are we duplicating this? It's already in the connector state no?
I'll remove a duplicated output color space from intel_crtc_state. And
in order to handle colorspace of drm_connector_state, I'll moves a
calling of intel_ddi_set_pipe_settings() function into
intel_ddi_pre_enable_dp().
>
> > +
> > /* Output down scaling is done in LSPCON device */
> > bool lspcon_downsampling;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index a2a0214f771a..3a8aef1c6036 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2187,6 +2187,8 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->has_pch_encoder = true;
> >
> > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > + pipe_config->output_colorspace = intel_conn_state-
> > >base.colorspace;
> > +
> > if (lspcon->active)
> > lspcon_ycbcr420_config(_connector->base,
> > pipe_config);
> > else
> > @@ -4448,6 +4450,31 @@ u8 intel_dp_dsc_get_slice_count(struct
> > intel_dp *intel_dp,
> > return 0;
> > }
> >
> > +bool
> > +intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state)
> > +{
> > + /*
> > +* As per DP 1.4a spec section 2.2.4.3 [MSA Field for
> > Indication
> > +* of Color Encoding Format and Content Color Gamut], in order
> > to
> > +* sending YCBCR 420 or HDR BT.2020 signals we should use DP
> > VSC SDP.
> > +*/
> > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > + return true;
> > +
> > + switch (crtc_state->output_colorspace) {
> > + case DRM_MODE_COLORIMETRY_SYCC_601:
> > + case DRM_MODE_COLORIMETRY_OPYCC_601:
> > + case DRM_MODE_COLORIMETRY_BT2020_YCC:
> > + case
Re: [PATCH 2/2] MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2
On Thu, Sep 19, 2019 at 7:30 PM Maxime Ripard wrote: > > The newer Allwinner SoCs have a different layers controller than the older > ones. Jernej wrote that support and has been reviewing patches for a while > now, so let's make him a formal reviewer. > > Signed-off-by: Maxime Ripard Haz commit rights already, or do we need to fix that? -Daniel > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 54e222e1d0d6..fae328f06c17 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5361,6 +5361,15 @@ F: drivers/gpu/drm/sun4i/ > F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > T: git git://anongit.freedesktop.org/drm/drm-misc > > +DRM DRIVER FOR ALLWINNER DE2 ENGINE > +M: Maxime Ripard > +M: Chen-Yu Tsai > +R: Jernej Škrabec > +L: dri-devel@lists.freedesktop.org > +S: Supported > +F: drivers/gpu/drm/sun4i/sun8i* > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > DRM DRIVERS FOR AMLOGIC SOCS > M: Neil Armstrong > L: dri-devel@lists.freedesktop.org > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #30 from Gabriel C --- (In reply to Gabriel C from comment #29) > Michael, > > I see the same on a Ryzen 7 35750H APU + RX 560x Nitro5 Laptop. It is 3750H :-) -- 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 1/2] MAINTAINERS: Update Allwinner DRM drivers entry
On Thu, Sep 19, 2019 at 7:36 PM Chen-Yu Tsai wrote: > > On Fri, Sep 20, 2019 at 1:30 AM Maxime Ripard wrote: > > > > The DRM drivers are more than about the A10 now, so let's make the entry > > name a bit more generic. > > > > Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a > > while, is a maintainer of the Allwinner platform for an even longer time, > > and has drm-misc commit access. Let's make it formal and add him as a > > Although I have an account, I haven't actually tried if I have commit access. > I also don't think my account was properly migrated over to GitLab, as I > had to re-create one. The git repo is still on legacy git fd.o servers, it's not yet migrated over to gitlab. -Daniel > > > maintainer. > > > > Signed-off-by: Maxime Ripard > > Acked-by: Chen-Yu Tsai > > > --- > > MAINTAINERS | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index b2326dece28e..54e222e1d0d6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5352,8 +5352,9 @@ F:include/drm/drm* > > F: include/uapi/drm/drm* > > F: include/linux/vga* > > > > -DRM DRIVERS FOR ALLWINNER A10 > > +DRM DRIVERS FOR ALLWINNER SOCS > > M: Maxime Ripard > > +M: Chen-Yu Tsai > > L: dri-devel@lists.freedesktop.org > > S: Supported > > F: drivers/gpu/drm/sun4i/ > > -- > > 2.21.0 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #29 from Gabriel C --- Michael, I see the same on a Ryzen 7 35750H APU + RX 560x Nitro5 Laptop. reverting https://github.com/freedesktop/xorg-xf86-video-amdgpu/commit/a2b32e72fdaff3007a79b84929997d8176c2d512 fixes the problem for me. I tested kernels 5.2*, 5.3, and all have the same problem when suspending from X with that commit, without the commit everything is working fine. ( will test 5.4git once drm-next is in but I tested amd-staging-drm-next some days ago and that didn't work also ) If you need more informations please let me know. I can test any kind patches kernel/X/mesa and/or give you debug info if you tell me what you may need. Best Regards, Gabriel C -- 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
[radeon-alex:amd-mainline-dkms-5.0 3711/3724] drivers/gpu/drm/ttm/ttm_bo_vm.c:137:44: error: 'struct vm_fault' has no member named 'virtual_address'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: a51a5ad4b8daf0dd0a437d51a19c2baa98953675
commit: 5165cd1453625e59650a1ed9b0f269b41529e421 [3711/3724] Revert "Revert
"drm/amd/autoconf: Test whether vm_fault->{address/vma} is available""
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
git checkout 5165cd1453625e59650a1ed9b0f269b41529e421
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
from :0:
include/linux/sched/mm.h:234:20: note: previous definition of
'memalloc_nofs_restore' was here
static inline void memalloc_nofs_restore(unsigned int flags)
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:61:21: error: redefinition of 'kvmalloc'
static inline void *kvmalloc(size_t size, gfp_t flags)
^~~~
In file included from include/linux/scatterlist.h:8:0,
from include/linux/dma-mapping.h:11,
from include/drm/drmP.h:37,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/linux/mm.h:602:21: note: previous definition of 'kvmalloc' was here
static inline void *kvmalloc(size_t size, gfp_t flags)
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:71:21: error: redefinition of 'kvzalloc'
static inline void *kvzalloc(size_t size, gfp_t flags)
^~~~
In file included from include/linux/scatterlist.h:8:0,
from include/linux/dma-mapping.h:11,
from include/drm/drmP.h:37,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/linux/mm.h:610:21: note: previous definition of 'kvzalloc' was here
static inline void *kvzalloc(size_t size, gfp_t flags)
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:81:20: error: static declaration of 'kvfree' follows
non-static declaration
static inline void kvfree(const void *addr)
^~
In file included from include/linux/scatterlist.h:8:0,
from include/linux/dma-mapping.h:11,
from include/drm/drmP.h:37,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/linux/mm.h:630:13: note: previous declaration of 'kvfree' was here
extern void kvfree(const void *addr);
^~
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:101:21: error: redefinition of 'kvmalloc_array'
static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags)
^~
In file included from include/linux/scatterlist.h:8:0,
from include/linux/dma-mapping.h:11,
from include/drm/drmP.h:37,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/linux/mm.h:615:21: note: previous definition of 'kvmalloc_array' was
here
static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags)
^~
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:114:21: error: redefinition of 'kvcalloc'
static inline void *kvcalloc(size_t n, size_t size, gfp_t flags)
^~~~
In file included from include/linux/scatterlist.h:8:0,
from include/linux/dma-mapping.h:11,
from include/drm/drmP.h:37,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/linux/mm.h:625:21: note: previous definition of 'kvcalloc' was here
static inline void *kvcalloc(size_t n, size_t size, gfp_t flags)
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_mm.h:121:20: error: redefinition of 'mmgrab'
static inline void mmgrab(struct mm_struct *mm)
^~
In file included from include/kcl/kcl_mm.h:6:0,
from
Re: drm/sun4i: Add missing pixel formats to the vi layer
Hi!
Dne sreda, 18. september 2019 ob 13:05:41 CEST je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> According to Allwinner DE2.0 Specification REV 1.0, vi layer supports the
> following pixel formats: ABGR_, ARGB_, BGRA_, RGBA_
It's true that DE2 VI layers support those formats, but it wouldn't change
anything because alpha blending is not supported by those planes. These
formats were deliberately left out because their counterparts without alpha
exist, for example ABGR <-> XBGR. It would also confuse user, which
would expect that alpha blending works if format with alpha channel is
selected.
Admittedly some formats with alpha are still reported as supported due to lack
of their counterparts without alpha, but I'm fine with removing them for
consistency.
Best regards,
Jernej
>
> Signed-off-by: Roman Stratiienko
> ---
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index bd0e6a52d1d8..07c27e6a4b77
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -404,17 +404,21 @@ static const struct drm_plane_funcs
> sun8i_vi_layer_funcs = { static const u32 sun8i_vi_layer_formats[] = {
> DRM_FORMAT_ABGR1555,
> DRM_FORMAT_ABGR,
> + DRM_FORMAT_ABGR,
> DRM_FORMAT_ARGB1555,
> DRM_FORMAT_ARGB,
> + DRM_FORMAT_ARGB,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_BGR888,
> DRM_FORMAT_BGRA5551,
> DRM_FORMAT_BGRA,
> + DRM_FORMAT_BGRA,
> DRM_FORMAT_BGRX,
> DRM_FORMAT_RGB565,
> DRM_FORMAT_RGB888,
> DRM_FORMAT_RGBA,
> DRM_FORMAT_RGBA5551,
> + DRM_FORMAT_RGBA,
> DRM_FORMAT_RGBX,
> DRM_FORMAT_XBGR,
> DRM_FORMAT_XRGB,
Re: [PATCH 02/19] drm/atomic-helper: Make crtc helper funcs optional
On Wed, Sep 18, 2019 at 01:42:09PM +, Lisovskiy, Stanislav wrote: > On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Allow drivers to call drm_atomic_helper_check_modeset() without > > having the crtc helper funcs specified. i915 doesn't need those > > anymore. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Stanislav Lisovskiy 1-2 pushed to drm-misc-next. The rest shall wait until those two make the roundtrip back to dinq. Thanks for the reviews. > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index aa16ea17ff9b..fb2ce692ae5b 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -481,7 +481,7 @@ mode_fixup(struct drm_atomic_state *state) > > continue; > > > > funcs = crtc->helper_private; > > - if (!funcs->mode_fixup) > > + if (!funcs || !funcs->mode_fixup) > > continue; > > > > ret = funcs->mode_fixup(crtc, _crtc_state->mode, -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Use vi plane as primary
Dne četrtek, 19. september 2019 ob 19:17:54 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 19, 2019 at 03:37:03PM +0300, roman.stratiie...@globallogic.com
wrote:
> > From: Roman Stratiienko
> >
> > DE2.0 blender does not take into the account alpha channel of vi layer.
> > Thus makes overlaying of this layer totally opaque.
> > Using vi layer as bottom solves this issue.
What issue? Overlays don't have to be "full screen", thus missing support for
alpha blending doesn't make it less valuable. And VI planes are already placed
at the bottom (zpos = 0).
> >
> > Tested on Android.
> >
> > Signed-off-by: Roman Stratiienko
>
> It sounds like a workaround more than an actual fix.
>
> If the VI planes can't use the alpha, then we should just stop
> reporting that format.
>
> Jernej, what do you think?
Commit message is misleading. What this commit actually does is moving primary
plane from first UI plane to bottom most plane, i.e. first VI plane. However,
VI
planes are scarce resource, almost all mixers have only one. I wouldn't set it
as primary, because it's the only one which provide support for YUV formats.
That could be used for example by video player for zero-copy rendering.
Probably most apps wouldn't touch it if it was primary (that's usually
reserved for window manager, if used).
I left few formats with alpha channel exposed by VI planes, just because they
don't have equivalent format without alpha. But I'm fine with removing them if
you all agree on that.
Best regards,
Jernej
>
> Maxime
>
> > ---
> >
> > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 33 ---
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 +-
> > 2 files changed, 35 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index dd2a1c851939..25183badc85f
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > @@ -99,36 +99,6 @@ static int sun8i_ui_layer_update_coord(struct
> > sun8i_mixer *mixer, int channel,>
> > insize = SUN8I_MIXER_SIZE(src_w, src_h);
> > outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
> >
> > - if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> > - bool interlaced = false;
> > - u32 val;
> > -
> > - DRM_DEBUG_DRIVER("Primary layer, updating global size
W: %u H: %u\n",
> > -dst_w, dst_h);
> > - regmap_write(mixer->engine.regs,
> > -SUN8I_MIXER_GLOBAL_SIZE,
> > -outsize);
> > - regmap_write(mixer->engine.regs,
> > -SUN8I_MIXER_BLEND_OUTSIZE(bld_base),
outsize);
> > -
> > - if (state->crtc)
> > - interlaced = state->crtc->state-
>adjusted_mode.flags
> > - & DRM_MODE_FLAG_INTERLACE;
> > -
> > - if (interlaced)
> > - val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> > - else
> > - val = 0;
> > -
> > - regmap_update_bits(mixer->engine.regs,
> > -
SUN8I_MIXER_BLEND_OUTCTL(bld_base),
> > -
SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> > - val);
> > -
> > - DRM_DEBUG_DRIVER("Switching display mixer interlaced
mode %s\n",
> > -interlaced ? "on" : "off");
> > - }
> > -
> >
> > /* Set height and width */
> > DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
> >
> > state->src.x1 >> 16, state->src.y1 >> 16);
> >
> > @@ -349,9 +319,6 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
> > drm_device *drm,>
> > if (!layer)
> >
> > return ERR_PTR(-ENOMEM);
> >
> > - if (index == 0)
> > - type = DRM_PLANE_TYPE_PRIMARY;
> > -
> >
> > /* possible crtcs are set later */
> > ret = drm_universal_plane_init(drm, >plane, 0,
> >
> >_ui_layer_funcs,
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index 07c27e6a4b77..49c4074e164f
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > @@ -116,6 +116,36 @@ static int sun8i_vi_layer_update_coord(struct
> > sun8i_mixer *mixer, int channel,>
> > insize = SUN8I_MIXER_SIZE(src_w, src_h);
> > outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
> >
> > + if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> > + bool interlaced = false;
> > + u32 val;
> > +
> > + DRM_DEBUG_DRIVER("Primary layer, updating global size
W: %u H: %u\n",
> > +dst_w, dst_h);
> > + regmap_write(mixer->engine.regs,
> > +SUN8I_MIXER_GLOBAL_SIZE,
> > +outsize);
> > +
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #20 from vlad@ivanov.email --- Still seeing the warning with 5.4.0-0.rc0.git2.2.fc32.x86_64; waking up doesn't work. This is fedora kernel though and there's a possibility those patches aren't integrated there yet; is there a way to check? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: remove excess function parameter description
On Thu, Sep 19, 2019 at 10:03 AM yu kuai wrote:
>
> Fixes gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:431: warning: Excess function
> parameter 'sw' description in 'vcn_v2_5_disable_clock_gating'
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:550: warning: Excess function
> parameter 'sw' description in 'vcn_v2_5_enable_clock_gating'
>
> Fixes: cbead2bdfcf1 ("drm/amdgpu: add VCN2.5 VCPU start and stop")
> Signed-off-by: yu kuai
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> index 395c225..9d778a0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> @@ -423,7 +423,6 @@ static void vcn_v2_5_mc_resume(struct amdgpu_device *adev)
> * vcn_v2_5_disable_clock_gating - disable VCN clock gating
> *
> * @adev: amdgpu_device pointer
> - * @sw: enable SW clock gating
> *
> * Disable clock gating for VCN block
> */
> @@ -542,7 +541,6 @@ static void vcn_v2_5_disable_clock_gating(struct
> amdgpu_device *adev)
> * vcn_v2_5_enable_clock_gating - enable VCN clock gating
> *
> * @adev: amdgpu_device pointer
> - * @sw: enable SW clock gating
> *
> * Enable clock gating for VCN block
> */
> --
> 2.7.4
>
> ___
> 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 v5 2/2] drm/bridge: Add NWL MIPI DSI host controller support
Hi Andrzej, thanks for your comments! On Thu, Sep 19, 2019 at 03:56:45PM +0200, Andrzej Hajda wrote: > On 14.09.2019 18:11, Guido Günther wrote: > > Hi Andrzej, > > thanks for having a look! > > > > On Fri, Sep 13, 2019 at 11:31:43AM +0200, Andrzej Hajda wrote: > >> On 09.09.2019 04:25, Guido Günther wrote: > >>> This adds initial support for the NWL MIPI DSI Host controller found on > >>> i.MX8 SoCs. > >>> > >>> It adds support for the i.MX8MQ but the same IP can be found on > >>> e.g. the i.MX8QXP. > >>> > >>> It has been tested on the Librem 5 devkit using mxsfb. > >>> > >>> Signed-off-by: Guido Günther > >>> Co-developed-by: Robert Chiras > >>> Signed-off-by: Robert Chiras > >>> Tested-by: Robert Chiras > >>> --- > >>> drivers/gpu/drm/bridge/Kconfig | 2 + > >>> drivers/gpu/drm/bridge/Makefile | 1 + > >>> drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 + > >>> drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 + > >>> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 499 > >>> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++ > >>> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 696 +++ > >>> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 > >> > >> Why do you need separate files nwl-drv.[ch] and nwl-dsi.[ch] ? I guess > >> you can merge all into one file, maybe with separate file for NWL > >> register definitions. > > Idea is to have driver setup, soc specific hooks and revision specific > > quirks in one file and the dsi specific parts in another. If that > > doesn't fly I can merge into one if that's a requirement. > > > One file looks saner to me :), but more importantly it follows current > practice. O.k., I'll merge things for v6 then. > > > > > >>> 8 files changed, 1395 insertions(+) > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c > >>> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h > >>> > >>> diff --git a/drivers/gpu/drm/bridge/Kconfig > >>> b/drivers/gpu/drm/bridge/Kconfig > >>> index 1cc9f502c1f2..7980b5c2156f 100644 > >>> --- a/drivers/gpu/drm/bridge/Kconfig > >>> +++ b/drivers/gpu/drm/bridge/Kconfig > >>> @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig" > >>> > >>> source "drivers/gpu/drm/bridge/adv7511/Kconfig" > >>> > >>> +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig" > >>> + > >>> source "drivers/gpu/drm/bridge/synopsys/Kconfig" > >>> > >>> endmenu > >>> diff --git a/drivers/gpu/drm/bridge/Makefile > >>> b/drivers/gpu/drm/bridge/Makefile > >>> index 4934fcf5a6f8..d9f6c0f77592 100644 > >>> --- a/drivers/gpu/drm/bridge/Makefile > >>> +++ b/drivers/gpu/drm/bridge/Makefile > >>> @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ > >>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > >>> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > >>> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > >>> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/ > >>> obj-y += synopsys/ > >>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig > >>> b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig > >>> new file mode 100644 > >>> index ..7fa678e3b5e2 > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig > >>> @@ -0,0 +1,16 @@ > >>> +config DRM_NWL_MIPI_DSI > >>> + tristate "Northwest Logic MIPI DSI Host controller" > >>> + depends on DRM > >>> + depends on COMMON_CLK > >>> + depends on OF && HAS_IOMEM > >>> + select DRM_KMS_HELPER > >>> + select DRM_MIPI_DSI > >>> + select DRM_PANEL_BRIDGE > >>> + select GENERIC_PHY_MIPI_DPHY > >>> + select MFD_SYSCON > >>> + select MULTIPLEXER > >>> + select REGMAP_MMIO > >>> + help > >>> + This enables the Northwest Logic MIPI DSI Host controller as > >>> + for example found on NXP's i.MX8 Processors. > >>> + > >>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile > >>> b/drivers/gpu/drm/bridge/nwl-dsi/Makefile > >>> new file mode 100644 > >>> index ..804baf2f1916 > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile > >>> @@ -0,0 +1,4 @@ > >>> +# SPDX-License-Identifier: GPL-2.0 > >>> +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o > >>> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o > >>> +header-test-y += nwl-drv.h nwl-dsi.h > >>> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c > >>> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c > >>> new file mode 100644 > >>> index ..9ff43d2de127 > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c > >>> @@ -0,0 +1,499 @@ > >>> +// SPDX-License-Identifier: GPL-2.0+ > >>> +/* > >>> + * i.MX8 NWL MIPI DSI host driver > >>> + * > >>> + * Copyright (C) 2017 NXP > >>> + * Copyright (C) 2019 Purism SPC > >>> + */ > >>> + > >>> +#include > >>> +#include > >>>
Re: [PATCH 1/2] MAINTAINERS: Update Allwinner DRM drivers entry
On Fri, Sep 20, 2019 at 1:30 AM Maxime Ripard wrote: > > The DRM drivers are more than about the A10 now, so let's make the entry > name a bit more generic. > > Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a > while, is a maintainer of the Allwinner platform for an even longer time, > and has drm-misc commit access. Let's make it formal and add him as a Although I have an account, I haven't actually tried if I have commit access. I also don't think my account was properly migrated over to GitLab, as I had to re-create one. > maintainer. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai > --- > MAINTAINERS | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b2326dece28e..54e222e1d0d6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5352,8 +5352,9 @@ F:include/drm/drm* > F: include/uapi/drm/drm* > F: include/linux/vga* > > -DRM DRIVERS FOR ALLWINNER A10 > +DRM DRIVERS FOR ALLWINNER SOCS > M: Maxime Ripard > +M: Chen-Yu Tsai > L: dri-devel@lists.freedesktop.org > S: Supported > F: drivers/gpu/drm/sun4i/ > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2
The newer Allwinner SoCs have a different layers controller than the older ones. Jernej wrote that support and has been reviewing patches for a while now, so let's make him a formal reviewer. Signed-off-by: Maxime Ripard --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 54e222e1d0d6..fae328f06c17 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5361,6 +5361,15 @@ F: drivers/gpu/drm/sun4i/ F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt T: git git://anongit.freedesktop.org/drm/drm-misc +DRM DRIVER FOR ALLWINNER DE2 ENGINE +M: Maxime Ripard +M: Chen-Yu Tsai +R: Jernej Škrabec +L: dri-devel@lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/sun4i/sun8i* +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVERS FOR AMLOGIC SOCS M: Neil Armstrong L: dri-devel@lists.freedesktop.org -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] MAINTAINERS: Update Allwinner DRM drivers entry
The DRM drivers are more than about the A10 now, so let's make the entry name a bit more generic. Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a while, is a maintainer of the Allwinner platform for an even longer time, and has drm-misc commit access. Let's make it formal and add him as a maintainer. Signed-off-by: Maxime Ripard --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2326dece28e..54e222e1d0d6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5352,8 +5352,9 @@ F:include/drm/drm* F: include/uapi/drm/drm* F: include/linux/vga* -DRM DRIVERS FOR ALLWINNER A10 +DRM DRIVERS FOR ALLWINNER SOCS M: Maxime Ripard +M: Chen-Yu Tsai L: dri-devel@lists.freedesktop.org S: Supported F: drivers/gpu/drm/sun4i/ -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #43 from rol...@rptd.ch --- Sorry, but this is rude. I waited for an answer on my result of testing the patch (as requested) and that's what I get as answer? I can continue trying to find a reproducible task but then please say that you acknowledged my finding so I can continue in a helpful way. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Use vi plane as primary
Hi,
On Thu, Sep 19, 2019 at 03:37:03PM +0300, roman.stratiie...@globallogic.com
wrote:
> From: Roman Stratiienko
>
> DE2.0 blender does not take into the account alpha channel of vi layer.
> Thus makes overlaying of this layer totally opaque.
> Using vi layer as bottom solves this issue.
>
> Tested on Android.
>
> Signed-off-by: Roman Stratiienko
It sounds like a workaround more than an actual fix.
If the VI planes can't use the alpha, then we should just stop
reporting that format.
Jernej, what do you think?
Maxime
> ---
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 33 ---
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 +-
> 2 files changed, 35 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> index dd2a1c851939..25183badc85f 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -99,36 +99,6 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
> *mixer, int channel,
> insize = SUN8I_MIXER_SIZE(src_w, src_h);
> outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
>
> - if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> - bool interlaced = false;
> - u32 val;
> -
> - DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
> %u\n",
> - dst_w, dst_h);
> - regmap_write(mixer->engine.regs,
> - SUN8I_MIXER_GLOBAL_SIZE,
> - outsize);
> - regmap_write(mixer->engine.regs,
> - SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
> -
> - if (state->crtc)
> - interlaced = state->crtc->state->adjusted_mode.flags
> - & DRM_MODE_FLAG_INTERLACE;
> -
> - if (interlaced)
> - val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> - else
> - val = 0;
> -
> - regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_BLEND_OUTCTL(bld_base),
> -SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> -val);
> -
> - DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
> - interlaced ? "on" : "off");
> - }
> -
> /* Set height and width */
> DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
>state->src.x1 >> 16, state->src.y1 >> 16);
> @@ -349,9 +319,6 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
> drm_device *drm,
> if (!layer)
> return ERR_PTR(-ENOMEM);
>
> - if (index == 0)
> - type = DRM_PLANE_TYPE_PRIMARY;
> -
> /* possible crtcs are set later */
> ret = drm_universal_plane_init(drm, >plane, 0,
> _ui_layer_funcs,
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> index 07c27e6a4b77..49c4074e164f 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -116,6 +116,36 @@ static int sun8i_vi_layer_update_coord(struct
> sun8i_mixer *mixer, int channel,
> insize = SUN8I_MIXER_SIZE(src_w, src_h);
> outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
>
> + if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> + bool interlaced = false;
> + u32 val;
> +
> + DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
> %u\n",
> + dst_w, dst_h);
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_GLOBAL_SIZE,
> + outsize);
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
> +
> + if (state->crtc)
> + interlaced = state->crtc->state->adjusted_mode.flags
> + & DRM_MODE_FLAG_INTERLACE;
> +
> + if (interlaced)
> + val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> + else
> + val = 0;
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_OUTCTL(bld_base),
> +SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> +val);
> +
> + DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
> + interlaced ? "on" : "off");
> + }
> +
> /* Set height and width */
> DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
>(state->src.x1 >> 16) & ~(format->hsub - 1),
> @@ -445,6 +475,7 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
> drm_device *drm,
>
Re: [PATCH] drm/radeon: fix a potential NULL pointer dereference
On 2019-09-18 6:31 p.m., Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index bd52f15..1a41764 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -683,6 +683,10 @@ static void radeon_crtc_init(struct drm_device *dev, int
> index)
> drm_mode_crtc_set_gamma_size(_crtc->base, 256);
> radeon_crtc->crtc_id = index;
> radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
> + if (unlikely(!radeon_crtc->flip_queue)) {
> + kfree(radeon_crtc);
> + return;
> + }
> rdev->mode_info.crtcs[index] = radeon_crtc;
>
> if (rdev->family >= CHIP_BONAIRE) {
>
I'm afraid just silently leaving the CRTC uninitialized isn't a good way
to handle this. The failure would need to be propagated, probably
resulting in the driver aborting its initialization altogether.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Fix regulator_get_optional() misuse
On Mon, Sep 9, 2019 at 11:22 AM Steven Price wrote:
>
> On 09/09/2019 16:41, Rob Herring wrote:
> > On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
> >>
> >> On 04/09/2019 13:30, Mark Brown wrote:
> >>> The panfrost driver requests a supply using regulator_get_optional()
> >>> but both the name of the supply and the usage pattern suggest that it is
> >>> being used for the main power for the device and is not at all optional
> >>> for the device for function, there is no meaningful handling for absent
> >>> supplies. Such regulators should use the vanilla regulator_get()
> >>> interface, it will ensure that even if a supply is not described in the
> >>> system integration one will be provided in software.
> >>>
> >>> Signed-off-by: Mark Brown
> >>
> >> Tested-by: Steven Price
> >>
> >> Looks like my approach to this was wrong - so we should also revert the
> >> changes I made previously.
> >>
> >> 8<
> >> From fe20f8abcde8444bb41a8f72fb35de943a27ec5c Mon Sep 17 00:00:00 2001
> >> From: Steven Price
> >> Date: Fri, 6 Sep 2019 15:20:53 +0100
> >> Subject: [PATCH] drm/panfrost: Revert changes to cope with NULL regulator
> >>
> >> Handling a NULL return from devm_regulator_get_optional() doesn't seem
> >> like the correct way of handling this. Instead revert the changes in
> >> favour of switching to using devm_regulator_get() which will return a
> >> dummy regulator instead.
> >>
> >> Reverts commit 52282163dfa6 ("drm/panfrost: Add missing check for
> >> pfdev->regulator")
> >> Reverts commit e21dd290881b ("drm/panfrost: Enable devfreq to work without
> >> regulator")
> >
> > Does a straight revert of these 2 patches not work? If it does work,
> > can you do that and send to the list. I don't want my hand slapped
> > again reverting things.
>
> I wasn't sure what was best here - 52282163dfa6 is a bug fix, so
> reverting that followed by e21dd290881b would (re-)introduce a
> regression for that one commit (i.e. not completely bisectable).
> Reverting in the other order would work, but seems a little odd.
> Squashing the reverts seemed the neatest option - but it's not my hand
> at risk... :)
>
> Perhaps it would be best to simply apply Mark's change followed by
> something like the following. That way it's not actually a revert!
> It also avoids (re-)adding the now redundant check in
> panfrost_devfreq_init().
>
> Steve
>
> ---8<
> From fb2956acdf46ca04095ef11363c136dc94a1ab18 Mon Sep 17 00:00:00 2001
> From: Steven Price
> Date: Fri, 6 Sep 2019 15:20:53 +0100
> Subject: [PATCH] drm/panfrost: Remove NULL checks for regulator
>
> devm_regulator_get() is now used to populate pfdev->regulator which
> ensures that this cannot be NULL (a dummy regulator will be returned if
> necessary). So remove the checks in panfrost_devfreq_target().
>
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
Okay, I've gone this route and applied Mark's patch and this one.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panfrost: Prevent race when handling page fault
On Fri, Sep 13, 2019 at 11:03 AM Steven Price wrote: > > When handling a GPU page fault addr_to_drm_mm_node() is used to > translate the GPU address to a buffer object. However it is possible for > the buffer object to be freed after the function has returned resulting > in a use-after-free of the BO. > > Change addr_to_drm_mm_node to return the panfrost_gem_object with an > extra reference on it, preventing the BO from being freed until after > the page fault has been handled. > > Signed-off-by: Steven Price > --- > Changes since v1: > * Hold the mm_lock around drm_mm_for_each_node() > > I've also posted a new IGT test for this: > https://patchwork.freedesktop.org/patch/330513/ > > drivers/gpu/drm/panfrost/panfrost_mmu.c | 55 - > 1 file changed, 36 insertions(+), 19 deletions(-) Applied. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
Hello Christoph, everyone, On Sat, 7 Sep 2019 at 00:17, John Stultz wrote: > > Here is yet another pass at the dma-buf heaps patchset Andrew > and I have been working on which tries to destage a fair chunk > of ION functionality. > > The patchset implements per-heap devices which can be opened > directly and then an ioctl is used to allocate a dmabuf from the > heap. > > The interface is similar, but much simpler then IONs, only > providing an ALLOC ioctl. > > Also, I've provided relatively simple system and cma heaps. > > I've booted and tested these patches with AOSP on the HiKey960 > using the kernel tree here: > > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > And the userspace changes here: > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 > > Compared to ION, this patchset is missing the system-contig, > carveout and chunk heaps, as I don't have a device that uses > those, so I'm unable to do much useful validation there. > Additionally we have no upstream users of chunk or carveout, > and the system-contig has been deprecated in the common/andoid-* > kernels, so this should be ok. > > I've also removed the stats accounting, since any such accounting > should be implemented by dma-buf core or the heaps themselves. > > Most of the changes in this revision are adddressing the more > concrete feedback from Christoph (many thanks!). Though I'm not > sure if some of the less specific feedback was completely resolved > in discussion last time around. Please let me know! It looks like most of the feedback has been taken care of. If there's no more objection to this series, I'd like to merge it in soon. If there are any more review comments, may I request you to please provide them? > > New in v8: > * Make struct dma_heap_ops consts (Suggested by Christoph) > * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls > (suggested by Christoph) > * Condense dma_heap_buffer and heap_helper_buffer (suggested by > Christoph) > * Get rid of needless struct system_heap (suggested by Christoph) > * Fix indentation by using shorter argument names (suggested by > Christoph) > * Remove unused private_flags value > * Add forgotten include file to fix build issue on x86 > * Checkpatch whitespace fixups > > Thoughts and feedback would be greatly appreciated! > > thanks > -john Best, Sumit. > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: dri-devel@lists.freedesktop.org > > > Andrew F. Davis (1): > dma-buf: Add dma-buf heaps framework > > John Stultz (4): > dma-buf: heaps: Add heap helpers > dma-buf: heaps: Add system heap to dmabuf heaps > dma-buf: heaps: Add CMA heap to dmabuf heaps > kselftests: Add dma-heap test > > MAINTAINERS | 18 ++ > drivers/dma-buf/Kconfig | 11 + > drivers/dma-buf/Makefile | 2 + > drivers/dma-buf/dma-heap.c| 250 > drivers/dma-buf/heaps/Kconfig | 14 + > drivers/dma-buf/heaps/Makefile| 4 + > drivers/dma-buf/heaps/cma_heap.c | 164 +++ > drivers/dma-buf/heaps/heap-helpers.c | 269 ++ > drivers/dma-buf/heaps/heap-helpers.h | 55 > drivers/dma-buf/heaps/system_heap.c | 122 > include/linux/dma-heap.h | 59 > include/uapi/linux/dma-heap.h | 55 > tools/testing/selftests/dmabuf-heaps/Makefile | 9 + > .../selftests/dmabuf-heaps/dmabuf-heap.c | 230 +++ > 14 files changed, 1262 insertions(+) > create mode 100644 drivers/dma-buf/dma-heap.c > create mode 100644 drivers/dma-buf/heaps/Kconfig > create mode 100644 drivers/dma-buf/heaps/Makefile > create mode 100644 drivers/dma-buf/heaps/cma_heap.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.c > create mode 100644 drivers/dma-buf/heaps/heap-helpers.h > create mode 100644 drivers/dma-buf/heaps/system_heap.c > create mode 100644 include/linux/dma-heap.h > create mode 100644 include/uapi/linux/dma-heap.h > create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile > create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c > > -- > 2.17.1 > -- Thanks and regards, Sumit Semwal Linaro Consumer Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] drm/amd/display: hide an unused variable
On Thu, Sep 19, 2019 at 9:45 AM Harry Wentland wrote:
>
> On 2019-09-18 3:53 p.m., Arnd Bergmann wrote:
> > Without CONFIG_DEBUG_FS, we get a warning for an unused
> > variable:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error:
> > unused variable 'source' [-Werror,-Wunused-variable]
> >
> > Hide the variable in an #ifdef like its only users.
> >
> > Fixes: 14b2584636c6 ("drm/amd/display: add functionality to grab DPRX CRC
> > entries.")
> > Signed-off-by: Arnd Bergmann
>
> Reviewed-by: Harry Wentland
>
Applied. thanks!
Alex
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index e1b09bb432bd..74252f57bafb 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6017,7 +6017,9 @@ static void amdgpu_dm_enable_crtc_interrupts(struct
> > drm_device *dev,
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > int i;
> > +#ifdef CONFIG_DEBUG_FS
> > enum amdgpu_dm_pipe_crc_source source;
> > +#endif
> >
> > for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> > new_crtc_state, i) {
> >
> ___
> 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 v2] drm/amdgpu: fix multiple memory leaks
Am 19.09.19 um 16:28 schrieb Sven Van Asbroeck:
> Hi Christian,
>
> On Thu, Sep 19, 2019 at 4:05 AM Koenig, Christian
> wrote:
>>> +out4:
>>> + kfree(i2s_pdata);
>>> +out3:
>>> + kfree(adev->acp.acp_res);
>>> +out2:
>>> + kfree(adev->acp.acp_cell);
>>> +out1:
>>> + kfree(adev->acp.acp_genpd);
>> kfree on a NULL pointer is harmless, so a single error label should be
>> sufficient.
> That is true, but I notice that the adev structure comes from outside this
> driver:
adev is a very integral part of the driver and always zero initialized:
adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
Regards,
Christian.
>
> static int acp_hw_init(void *handle)
> {
> ...
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> ...
> }
>
> As far as I can tell, the init() does not explicitly set these to NULL:
> adev->acp.acp_res
> adev->acp.acp_cell
> adev->acp.acp_genpd
>
> I am assuming that core code sets these to NULL, before calling
> acp_hw_init(). But is that guaranteed or simply a happy accident?
> Ie. if they are NULL today, are they likely to remain NULL tomorrow?
>
> Because calling kfree() on a stale pointer would be, well
> not good. Especially not on an error path, which typically
> does not receive much testing, if any.
>
> My apologies if I have misinterpreted this, I am not familiar with
> this code base.
>
> Sven
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-09-19 16:28:41) > > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson > > wrote: > > > > > > It is expected that processes will pass dma-buf fd between drivers, and > > > only using the fd themselves for mmaping and synchronisation ioctls. > > > However, it may be convenient for an application to read/write into the > > > dma-buf, for instance a test case to check the internal > > > dma_buf->ops->kmap interface. There may also be a small advantage to > > > avoiding the mmap() for very simple/small operations. > > > > > > Note in particular, synchronisation with the device is left to the > > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly > > > inside the read/write, so that the user can avoid synchronisation if > > > they so choose. > > > > > > "It is easier to add synchronisation later, than it is to take it away." > > > > Hm for mmap I think the explicit sync makes sense (we might even want > > to do it in userspace). Not so sure it's a great idea for read/write > > ... I guess we'd need to see what people have/had in mind for the > > userspace for this to decide. > > There's an O_SYNC flag for open(2): > >O_SYNC Write operations on the file will complete according to the > requirements of synchronized I/O file integrity completion (by > contrast with the synchronized I/O data integrity completion > provided by O_DSYNC.) > > By the time write(2) (or similar) returns, the output data and > associated file metadata have been transferred to the underly‐ > ing hardware (i.e., as though each write(2) was followed by a > call to fsync(2)). > > That seems applicable here? Hm yeah, sounds like a neat idea to use O_SYNC to decide whether writes/reads flushes or not. It's a bit a stretch since !O_SYNC would also give you un-coherent reads (or could at least). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] treewide: remove unused argument in lock_release()
Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
in __lock_release"), @nested is no longer used in lock_release(), so
remove it from all lock_release() calls and friends.
Signed-off-by: Qian Cai
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/tty/tty_ldsem.c | 8
fs/dcache.c | 2 +-
fs/jbd2/transaction.c | 4 ++--
fs/kernfs/dir.c | 4 ++--
fs/ocfs2/dlmglue.c| 2 +-
include/linux/jbd2.h | 2 +-
include/linux/lockdep.h | 21 ++---
include/linux/percpu-rwsem.h | 4 ++--
include/linux/rcupdate.h | 2 +-
include/linux/rwlock_api_smp.h| 16
include/linux/seqlock.h | 4 ++--
include/linux/spinlock_api_smp.h | 8
include/linux/ww_mutex.h | 2 +-
include/net/sock.h| 2 +-
kernel/bpf/stackmap.c | 2 +-
kernel/cpu.c | 2 +-
kernel/locking/lockdep.c | 3 +--
kernel/locking/mutex.c| 4 ++--
kernel/locking/rtmutex.c | 6 +++---
kernel/locking/rwsem.c| 10 +-
kernel/printk/printk.c| 10 +-
kernel/sched/core.c | 2 +-
lib/locking-selftest.c| 24
mm/memcontrol.c | 2 +-
net/core/sock.c | 2 +-
tools/lib/lockdep/include/liblockdep/common.h | 3 +--
tools/lib/lockdep/include/liblockdep/mutex.h | 2 +-
tools/lib/lockdep/include/liblockdep/rwlock.h | 2 +-
tools/lib/lockdep/preload.c | 16
33 files changed, 90 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..4a8b2e5c2af6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -719,7 +719,7 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter)
__drm_connector_put_safe(iter->conn);
spin_unlock_irqrestore(>connector_list_lock, flags);
}
- lock_release(_list_iter_dep_map, 0, _RET_IP_);
+ lock_release(_list_iter_dep_map, _RET_IP_);
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index edd21d14e64f..1a51b3598d63 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -509,14 +509,14 @@ void i915_gem_shrinker_taints_mutex(struct
drm_i915_private *i915,
I915_MM_SHRINKER, 0, _RET_IP_);
mutex_acquire(>dep_map, 0, 0, _RET_IP_);
- mutex_release(>dep_map, 0, _RET_IP_);
+ mutex_release(>dep_map, _RET_IP_);
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
fs_reclaim_release(GFP_KERNEL);
if (unlock)
- mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
+ mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
}
#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..7f647243b3b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -52,7 +52,7 @@ static inline unsigned long __timeline_mark_lock(struct
intel_context *ce)
static inline void __timeline_mark_unlock(struct intel_context *ce,
unsigned long flags)
{
- mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>timeline->mutex.dep_map, _THIS_IP_);
local_irq_restore(flags);
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a53777dd371c..e1f1be4d0531 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1456,7 +1456,7 @@ long i915_request_wait(struct i915_request *rq,
dma_fence_remove_callback(>fence, );
out:
- mutex_release(>engine->gt->reset.mutex.dep_map, 0, _THIS_IP_);
+ mutex_release(>engine->gt->reset.mutex.dep_map, _THIS_IP_);
trace_i915_request_wait_end(rq);
return timeout;
}
diff --git a/drivers/tty/tty_ldsem.c b/drivers/tty/tty_ldsem.c
index 60ff236a3d63..ce8291053af3 100644
---
Re: [PATCH] dma-buf: Implement simple read/write vfs ops
Quoting Daniel Vetter (2019-09-19 16:28:41) > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote: > > > > It is expected that processes will pass dma-buf fd between drivers, and > > only using the fd themselves for mmaping and synchronisation ioctls. > > However, it may be convenient for an application to read/write into the > > dma-buf, for instance a test case to check the internal > > dma_buf->ops->kmap interface. There may also be a small advantage to > > avoiding the mmap() for very simple/small operations. > > > > Note in particular, synchronisation with the device is left to the > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly > > inside the read/write, so that the user can avoid synchronisation if > > they so choose. > > > > "It is easier to add synchronisation later, than it is to take it away." > > Hm for mmap I think the explicit sync makes sense (we might even want > to do it in userspace). Not so sure it's a great idea for read/write > ... I guess we'd need to see what people have/had in mind for the > userspace for this to decide. There's an O_SYNC flag for open(2): O_SYNC Write operations on the file will complete according to the requirements of synchronized I/O file integrity completion (by contrast with the synchronized I/O data integrity completion provided by O_DSYNC.) By the time write(2) (or similar) returns, the output data and associated file metadata have been transferred to the underly‐ ing hardware (i.e., as though each write(2) was followed by a call to fsync(2)). That seems applicable here? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Wed, Sep 18, 2019 at 8:04 AM Liviu Dudau wrote:
>
> On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > Hi all,
>
> Hi,
>
> >
> > On Tue, 17 Sep 2019 at 13:53, Daniel Vetter wrote:
> > > On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> > > > Let us ignore how the protected system memory is allocated and for the
> > > > scope of
> > > > this discussion, we want to figure out the best way possible for the
> > > > userspace
> > > > to communicate to the drm driver to turn the protected mode on (for
> > > > accessing the
> > > > framebuffer with the DRM content) or off.
> > > >
> > > > The possible ways by which the userspace could achieve this is via:-
> > > >
> > > > 1. Modifiers :- This looks to me the best way by which the userspace can
> > > > communicate to the kernel to turn the protected mode on for the komeda
> > > > driver
> > > > as it is going to access one of the protected framebuffers. The only
> > > > problem is
> > > > that the current modifiers describe the tiling/compression format.
> > > > However, it
> > > > does not hurt to extend the meaning of modifiers to denote other
> > > > attributes of
> > > > the framebuffer as well.
> > > >
> > > > The other reason is that on Android, we get an info from Gralloc
> > > > (GRALLOC_USAGE_PROTECTED) which tells us that the buffer is protected.
> > > > This can
> > > > be used to set up the modifier/s (AddFB2) during framebuffer creation.
> > >
> > > How does this mesh with other modifiers, like AFBC? That's where I see the
> > > issue here.
> >
> > Yeah. On other SoCs, we certainly have usecases for protected content
> > with different buffer layouts. The i.MX8M can protect particular
> > memory areas and partition them to protect access from particular
> > devices (e.g. display controller and video decoder only, not CPU or
> > GPU). Those memory areas can contain linear buffers, or tiled buffers,
> > or supertiled buffers, or ...
> >
> > Stealing a modifier isn't appropriate.
>
> I tend to agree with you here. Given that the modifiers were introduced
> mostly to
> help vendors add their ideosyncratic bits, having a generic flag as a
> modifier is
> not a good idea.
>
> >
> > > 6. Just track this as part of buffer allocation, i.e. I think it does
> > > matter how you allocate these protected buffers. We could add a "is
> > > protected buffer" flag at the dma_buf level for this.
> >
> > I totally agree. Framebuffers aren't about the underlying memory they
> > point to, but about how to _interpret_ that memory: it decorates a
> > pointer with width, height, stride, format, etc, to allow you to make
> > sense of that memory. I see content protection as being the same as
> > physical contiguity, which is a property of the underlying memory
> > itself. Regardless of the width, height, or format, you just cannot
> > access that memory unless it's under the appropriate ('secure enough')
> > conditions.
> >
> > So I think a dmabuf attribute would be most appropriate, since that's
> > where you have to do all your MMU handling, and everything else you
> > need to do to allow access to that buffer, anyway.
>
> Isn't it how AMD currently implements protected buffers as well?
Our buffer security is implemented as part of our GPU's virtual memory
interface. Our current proposed API is the set a "secure" flag when
memory is allocated and then when a process maps the buffer into its
GPU virtual address space, we set the appropriate flags in the PTEs.
See this series for more info:
https://patchwork.freedesktop.org/series/66531/
You can have the buffers in whatever tiled or linear format makes
sense. The encryption happens on top of that. In order for the
various blocks on the GPU to be able to access the encrypted memory,
they need to be switched into "secure" mode. So for example, if you
submit work to the GPU that included secure memory, you need to flag
that work as secure. I don't think our solution is really shareable
outside of our asics so in our case, we don't really have to worry
about passing secure buffers between drivers.
Alex
>
> >
> > > So yeah for this stuff here I think we do want the full userspace side,
> > > from allocator to rendering something into this protected buffers (no need
> > > to also have the entire "decode a protected bitstream part" imo, since
> > > that will freak people out). Unfortunately, in my experience, that kills
> > > it for upstream :-/ But also in my experience of looking into this for
> > > other gpu's, we really need to have the full picture here to make sure
> > > we're not screwing this up.
> >
> > Yeah. I know there are a few people looking at this at the moment, so
> > hopefully we are able to get something up and out in the open as a
> > strawman.
> >
> > There's a lot of complexity beyond just 'it's protected'; for
> > instance, some CP providers mandate that their content can only be
> > streamed over HDCP 2.2 Type-1 when going through an external
> > connection.
[pull] amdgpu drm-fixes-5.4
Hi Dave, Daniel, A few fixes for 5.4. The following changes since commit 945b584c94f8c665b2df3834a8a6a8faf256cd5f: Merge branch 'linux-5.4' of git://github.com/skeggsb/linux into drm-next (2019-09-17 16:31:34 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.4-2019-09-19 for you to fetch changes up to e16a7cbced7110866dcde84e504909ea85099bbd: drm/amdgpu: flag navi12 and 14 as experimental for 5.4 (2019-09-18 08:29:30 -0500) drm-fixes-5.4-2019-09-19: amdgpu: - Add more navi12 and navi14 PCI ids - Misc fixes for renoir - Fix bandwidth issues with multiple displays on vega20 - Support for Dali - Fix a possible oops with KFD on hawaii - Fix for backlight level after resume on some APUs - Other misc fixes Aaron Liu (3): drm/amdgpu: disable stutter mode for renoir drm/amd/display: update renoir_ip_offset.h drm/amdgpu: remove program of lbpw for renoir Alex Deucher (1): drm/amdgpu: flag navi12 and 14 as experimental for 5.4 Andrey Grodzovsky (2): drm/amdgpu: Add smu lock around in pp_smu_i2c_bus_access drm/amdgpu: Remove clock gating restore. Bhawanpreet Lakha (2): drm/amd/display: add Asic ID for Dali drm/amd/display: Implement voltage limitation for dali Charlene Liu (1): drm/amd/display: dce11.x /dce12 update formula input Felix Kuehling (1): drm/amdgpu: Fix KFD-related kernel oops on Hawaii Hans de Goede (1): drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed Jay Cornwall (1): drm/amdkfd: Swap trap temporary registers in gfx10 trap handler Kai-Heng Feng (1): drm/amd/display: Restore backlight brightness after system resume Prike Liang (2): drm/amd/amdgpu: power up sdma engine when S3 resume back drm/amd/powerplay: implement sysfs for getting dpm clock Roman Li (1): drm/amd/display: Add stereo mux and dig programming calls for dcn21 Tianci.Yin (2): drm/amdgpu: add navi14 PCI ID for work station SKU drm/amdgpu: add navi12 pci id Trek (1): drm/amdgpu: Check for valid number of registers to read Zhan Liu (1): drm/amd/display: Add missing HBM support and raise Vega20's uclk. drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 7 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 3 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 - drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 10 ++-- drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 10 +++- drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 6 +- .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx10.asm | 10 ++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 + drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 4 ++ .../amd/display/dc/clk_mgr/dce110/dce110_clk_mgr.c | 25 ++-- drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 4 +- .../drm/amd/display/dc/dce112/dce112_resource.c| 16 +++-- .../drm/amd/display/dc/dce120/dce120_resource.c| 11 +++- .../amd/display/dc/gpio/dcn21/hw_factory_dcn21.c | 38 +++- .../amd/display/dc/gpio/dcn21/hw_translate_dcn21.c | 3 +- drivers/gpu/drm/amd/display/dc/inc/resource.h | 2 + drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 ++- drivers/gpu/drm/amd/include/renoir_ip_offset.h | 2 +- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 7 ++- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 + drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 70 ++ drivers/gpu/drm/amd/powerplay/renoir_ppt.h | 25 drivers/gpu/drm/radeon/radeon_drv.c| 31 ++ drivers/gpu/drm/radeon/radeon_kms.c| 25 26 files changed, 262 insertions(+), 67 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] drm: Add self_refresh_state debugfs entry
On Thu, Sep 19, 2019 at 11:33:58AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds a debugfs entry to surface the entry and exit times as
> well as the calculated delay.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
> Link to v2:
> https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-3-s...@poorly.run
>
> Changes in v2:
> - Added to the set
> Changes in v3:
> - Move the debugfs out of core and into driver (Daniel)
> - Place a debugfs entry per crtc (Daniel)
> ---
>
> Here's the per-crtc version of this, mostly as an rfc since it still feels
> rough (particularly grabbing drm_minor from crtc->dev->primary). We should
> also probably introduce some drm_debugfs helpers for crtc entries
> instead of opencoding debugfs goo here and in debugfs_crc.
>
> I've got to switch over to MST-related stuff for the moment, but will
> get back to this once we have a clear picture of what we want to do.
>
> drivers/gpu/drm/drm_self_refresh_helper.c | 63 -
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +
> include/drm/drm_self_refresh_helper.h | 5 ++
> 3 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 68f4765a58964..4be7348e105c6 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -14,7 +14,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -167,6 +169,16 @@ void drm_self_refresh_helper_update_avg_times(struct
> drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_self_refresh_helper_update_avg_times);
>
> +static unsigned int
> +drm_self_refresh_calc_idle_delay(struct drm_self_refresh_data *sr_data)
> +{
> + if (WARN_ON(!mutex_is_locked(_data->avg_mutex)))
> + return SELF_REFRESH_AVG_SEED_MS * 4;
> +
> + return (ewma_psr_time_read(_data->entry_avg_ms) +
> + ewma_psr_time_read(_data->exit_avg_ms)) * 2;
> +}
> +
> /**
> * drm_self_refresh_helper_alter_state - Alters the atomic state for SR exit
> * @state: the state currently being checked
> @@ -209,8 +221,7 @@ void drm_self_refresh_helper_alter_state(struct
> drm_atomic_state *state)
> continue;
>
> mutex_lock(_data->avg_mutex);
> - delay = (ewma_psr_time_read(_data->entry_avg_ms) +
> - ewma_psr_time_read(_data->exit_avg_ms)) * 2;
> + delay = drm_self_refresh_calc_idle_delay(sr_data);
> mutex_unlock(_data->avg_mutex);
>
> mod_delayed_work(system_wq, _data->entry_work,
> @@ -275,3 +286,51 @@ void drm_self_refresh_helper_cleanup(struct drm_crtc
> *crtc)
> kfree(sr_data);
> }
> EXPORT_SYMBOL(drm_self_refresh_helper_cleanup);
> +
> +#ifdef CONFIG_DEBUG_FS
> +
> +static int drm_self_refresh_debugfs_show(struct seq_file *m, void *data)
> +{
> + struct drm_crtc *crtc = m->private;
> + struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + if (!sr_data)
> + return 0;
> +
> + mutex_lock(_data->avg_mutex);
> + drm_printf(, "entry_avg_ms=%lu\n",
> +ewma_psr_time_read(_data->entry_avg_ms));
> + drm_printf(, "exit_avg_ms=%lu\n",
> +ewma_psr_time_read(_data->exit_avg_ms));
> + drm_printf(, "idle_delay=%u\n",
> +drm_self_refresh_calc_idle_delay(sr_data));
> + mutex_unlock(_data->avg_mutex);
> + return 0;
> +}
> +
> +static int drm_self_refresh_debugfs_open(struct inode *inode, struct file
> *file)
> +{
> + struct drm_crtc *crtc = inode->i_private;
> +
> + return single_open(file, drm_self_refresh_debugfs_show, crtc);
> +}
> +
> +static const struct file_operations drm_self_refresh_debugfs_fops = {
> + .owner = THIS_MODULE,
> + .open = drm_self_refresh_debugfs_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +int drm_self_refresh_debugfs_init(struct drm_crtc *crtc)
> +{
> + debugfs_create_file("self_refresh_state", S_IFREG | S_IRUGO,
> + crtc->debugfs_entry, crtc,
> + _self_refresh_debugfs_fops);
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_self_refresh_debugfs_init);
> +
> +#endif
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 613404f86668d..181873b7146ac 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1303,6 +1303,19 @@ static struct drm_connector
> *vop_get_edp_connector(struct vop *vop)
> return NULL;
> }
>
> +static int vop_crtc_late_register(struct drm_crtc *crtc)
> +{
> + int ret;
pretend this is
int ret = 0;
:-)
> +#if
[PATCH v3 3/3] drm: Add self_refresh_state debugfs entry
From: Sean Paul
This patch adds a debugfs entry to surface the entry and exit times as
well as the calculated delay.
Suggested-by: Daniel Vetter
Signed-off-by: Sean Paul
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-3-s...@poorly.run
Changes in v2:
- Added to the set
Changes in v3:
- Move the debugfs out of core and into driver (Daniel)
- Place a debugfs entry per crtc (Daniel)
---
Here's the per-crtc version of this, mostly as an rfc since it still feels
rough (particularly grabbing drm_minor from crtc->dev->primary). We should
also probably introduce some drm_debugfs helpers for crtc entries
instead of opencoding debugfs goo here and in debugfs_crc.
I've got to switch over to MST-related stuff for the moment, but will
get back to this once we have a clear picture of what we want to do.
drivers/gpu/drm/drm_self_refresh_helper.c | 63 -
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +
include/drm/drm_self_refresh_helper.h | 5 ++
3 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
b/drivers/gpu/drm/drm_self_refresh_helper.c
index 68f4765a58964..4be7348e105c6 100644
--- a/drivers/gpu/drm/drm_self_refresh_helper.c
+++ b/drivers/gpu/drm/drm_self_refresh_helper.c
@@ -14,7 +14,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -167,6 +169,16 @@ void drm_self_refresh_helper_update_avg_times(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_self_refresh_helper_update_avg_times);
+static unsigned int
+drm_self_refresh_calc_idle_delay(struct drm_self_refresh_data *sr_data)
+{
+ if (WARN_ON(!mutex_is_locked(_data->avg_mutex)))
+ return SELF_REFRESH_AVG_SEED_MS * 4;
+
+ return (ewma_psr_time_read(_data->entry_avg_ms) +
+ ewma_psr_time_read(_data->exit_avg_ms)) * 2;
+}
+
/**
* drm_self_refresh_helper_alter_state - Alters the atomic state for SR exit
* @state: the state currently being checked
@@ -209,8 +221,7 @@ void drm_self_refresh_helper_alter_state(struct
drm_atomic_state *state)
continue;
mutex_lock(_data->avg_mutex);
- delay = (ewma_psr_time_read(_data->entry_avg_ms) +
-ewma_psr_time_read(_data->exit_avg_ms)) * 2;
+ delay = drm_self_refresh_calc_idle_delay(sr_data);
mutex_unlock(_data->avg_mutex);
mod_delayed_work(system_wq, _data->entry_work,
@@ -275,3 +286,51 @@ void drm_self_refresh_helper_cleanup(struct drm_crtc *crtc)
kfree(sr_data);
}
EXPORT_SYMBOL(drm_self_refresh_helper_cleanup);
+
+#ifdef CONFIG_DEBUG_FS
+
+static int drm_self_refresh_debugfs_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ if (!sr_data)
+ return 0;
+
+ mutex_lock(_data->avg_mutex);
+ drm_printf(, "entry_avg_ms=%lu\n",
+ ewma_psr_time_read(_data->entry_avg_ms));
+ drm_printf(, "exit_avg_ms=%lu\n",
+ ewma_psr_time_read(_data->exit_avg_ms));
+ drm_printf(, "idle_delay=%u\n",
+ drm_self_refresh_calc_idle_delay(sr_data));
+ mutex_unlock(_data->avg_mutex);
+ return 0;
+}
+
+static int drm_self_refresh_debugfs_open(struct inode *inode, struct file
*file)
+{
+ struct drm_crtc *crtc = inode->i_private;
+
+ return single_open(file, drm_self_refresh_debugfs_show, crtc);
+}
+
+static const struct file_operations drm_self_refresh_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_self_refresh_debugfs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+int drm_self_refresh_debugfs_init(struct drm_crtc *crtc)
+{
+ debugfs_create_file("self_refresh_state", S_IFREG | S_IRUGO,
+ crtc->debugfs_entry, crtc,
+ _self_refresh_debugfs_fops);
+ return 0;
+}
+EXPORT_SYMBOL(drm_self_refresh_debugfs_init);
+
+#endif
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 613404f86668d..181873b7146ac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1303,6 +1303,19 @@ static struct drm_connector
*vop_get_edp_connector(struct vop *vop)
return NULL;
}
+static int vop_crtc_late_register(struct drm_crtc *crtc)
+{
+ int ret;
+#if defined(CONFIG_DRM_KMS_HELPER)
+ ret = drm_self_refresh_debugfs_init(crtc);
+ if (ret) {
+ DRM_ERROR("Failed to init self refresh debugfs\n");
+ return ret;
+ }
+#endif
+ return ret;
+}
+
static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
Re: [PATCH] dma-buf: Implement simple read/write vfs ops
On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
>
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a test case to check the internal
> dma_buf->ops->kmap interface. There may also be a small advantage to
> avoiding the mmap() for very simple/small operations.
>
> Note in particular, synchronisation with the device is left to the
> caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
> inside the read/write, so that the user can avoid synchronisation if
> they so choose.
>
> "It is easier to add synchronisation later, than it is to take it away."
Hm for mmap I think the explicit sync makes sense (we might even want
to do it in userspace). Not so sure it's a great idea for read/write
... I guess we'd need to see what people have/had in mind for the
userspace for this to decide.
Only other thought I have on this is that many dma-buf exporters don't
bother with the kmap/kunmap interface (probably fewer than those who
bother with kernel vmap and mmap), maybe we want at least a vmap
fallback for this. Or maybe just use that as an excuse to get more
people to wire up the kmap stuff :-)
-Daniel
> v2: Lots of little fixes, plus a real llseek() implements so that the
> first basic little test cases work!
>
> Testcase: igt/prime_rw
> Signed-off-by: Chris Wilson
> Cc: Laura Abbott
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Janusz Krzysztofik
> Tested-by: Laura Abbott
> ---
> Dusting this off again as it would be nice as a user to operate on dmabuf
> agnostic to the underyling driver. We have mmap, so naturally we would
> like to have read/write as well!
>
> ---
> drivers/dma-buf/dma-buf.c | 108 --
> 1 file changed, 93 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 433d91d710e4..a19fc881a99c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -135,28 +135,104 @@ static int dma_buf_mmap_internal(struct file *file,
> struct vm_area_struct *vma)
>
> static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
> {
> - struct dma_buf *dmabuf;
> - loff_t base;
> + struct dma_buf *dmabuf = file->private_data;
>
> if (!is_dma_buf_file(file))
> return -EBADF;
>
> - dmabuf = file->private_data;
> + return fixed_size_llseek(file, offset, whence, dmabuf->size);
> +}
>
> - /* only support discovering the end of the buffer,
> - but also allow SEEK_SET to maintain the idiomatic
> - SEEK_END(0), SEEK_CUR(0) pattern */
> - if (whence == SEEK_END)
> - base = dmabuf->size;
> - else if (whence == SEEK_SET)
> - base = 0;
> - else
> - return -EINVAL;
> +static ssize_t dma_buf_read(struct file *file,
> + char __user *ubuf, size_t remain,
> + loff_t *offset)
> +{
> + struct dma_buf *dmabuf = file->private_data;
> + unsigned long idx;
> + unsigned int start;
> + size_t total;
>
> - if (offset != 0)
> - return -EINVAL;
> + if (!is_dma_buf_file(file))
> + return -EBADF;
> +
> + total = 0;
> + idx = *offset >> PAGE_SHIFT;
> + start = offset_in_page(*offset);
> + while (remain) {
> + unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
> + unsigned int copied;
> + void *vaddr;
> +
> + if (*offset >= dmabuf->size)
> + return total;
> +
> + vaddr = dma_buf_kmap(dmabuf, idx);
> + if (!vaddr)
> + return total ?: -EIO;
> +
> + copied = copy_to_user(ubuf, vaddr + start, len);
> + dma_buf_kunmap(dmabuf, idx, vaddr);
> +
> + total += copied ?: len;
> + if (copied) {
> + *offset += copied;
> + return total ?: -EFAULT;
> + }
> +
> + remain -= len;
> + *offset += len;
> + ubuf += len;
> + start = 0;
> + idx++;
> + }
> +
> + return total;
> +}
> +
> +static ssize_t dma_buf_write(struct file *file,
> +const char __user *ubuf, size_t remain,
> +loff_t *offset)
> +{
> + struct dma_buf *dmabuf = file->private_data;
> + unsigned long idx;
> + unsigned int start;
> + size_t total;
> +
> + if (!is_dma_buf_file(file))
> + return -EBADF;
> +
> + total = 0;
> + idx = *offset >> PAGE_SHIFT;
> + start = offset_in_page(*offset);
> + while (remain) {
> +
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Thu, Sep 19, 2019 at 04:10:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder wrote:
> >
> > On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
> >
> > Hi All,
> > Thanks for your suggestions.
> >
> > > Hi Liviu,
> > >
> > > On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > > > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > > > I totally agree. Framebuffers aren't about the underlying memory they
> > > > > point to, but about how to _interpret_ that memory: it decorates a
> > > > > pointer with width, height, stride, format, etc, to allow you to make
> > > > > sense of that memory. I see content protection as being the same as
> > > > > physical contiguity, which is a property of the underlying memory
> > > > > itself. Regardless of the width, height, or format, you just cannot
> > > > > access that memory unless it's under the appropriate ('secure enough')
> > > > > conditions.
> > > > >
> > > > > So I think a dmabuf attribute would be most appropriate, since that's
> > > > > where you have to do all your MMU handling, and everything else you
> > > > > need to do to allow access to that buffer, anyway.
> > > >
> > > > Isn't it how AMD currently implements protected buffers as well?
> > >
> > > No idea to be honest, I haven't seen anything upstream.
> > >
> > > > > There's a lot of complexity beyond just 'it's protected'; for
> > > > > instance, some CP providers mandate that their content can only be
> > > > > streamed over HDCP 2.2 Type-1 when going through an external
> > > > > connection. One way you could do that is to use a secure world
> > > > > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > > > > or TEE) to examine the display pipe configuration, and only then allow
> > > > > access to the buffers and/or keys. Stuff like that is always going to
> > > > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > > > it should be possible to agree on at least the basic mechanics and
> > > > > expectations of a secure path without things like that.
> > > >
> > > > I also expect that going through the secure world will be pretty much
> > > > transparent for
> > > > the kernel driver, as the most likely hardware implementations would
> > > > enable
> > > > additional signaling that will get trapped and handled by the secure
> > > > OS. I'm not
> > > > trying to simplify things, just taking the stance that it is userspace
> > > > that is
> > > > coordinating all this, we're trying only to find a common ground on how
> > > > to handle
> > > > this in the kernel.
> > >
> > > Yeah, makes sense.
> > >
> > > As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> > > the 'protected' flag on the resulting dmabuf?
> >
> > To be honest, during our internal discussion james.qian.w...@arm.com had a
> > similar suggestion of adding a new flag to dma_buf but I decided
> > against it.
> >
> > As per my understanding, adding custom dma buf flags (like
> > AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. We
> > rely on the dumb allocator and ion allocator for framebuffer creation.
> >
> > I was looking at an allocator independent way of userspace
> > communicating to the drm framework that the framebuffer is protected.
> >
> > Thus, it looked to me that framebuffer modifier is the best (or the least
> > corrupt) way of going forth.
> >
> > We use ion and dumb allocator for framebuffer object creation. The way
> > I see it is as follows :-
> >
> > 1. For ion allocator :-
> > Userspace can specify that it wants the buffer from a secure heap or any
> > other
> > special region of heap. The ion driver will either fault into the secure os
> > to
> > create the buffers or it will do some other magic. Honestly, I have still
> > not
> > figured that out. But it will be agnostic to the drm core.
>
> Allocating buffers from a special heap is what I expected the
> interface to be. The issue is that if we specify the secure mode any
> time later on, then it could be changed. E.g. with Daniel Stone's idea
> of a handle2fd flag, you could export the buffer twice, once secure,
> once non-secure. That sounds like a silly thing to me, and better to
> prevent that - or is this actually possible/wanted, i.e. do we want to
> change the secure mode for a buffer later on?
>
> > The userspace gets a handle to the buffer and then it calls addFB2 with
> > DRM_FORMAT_MOD_ARM_PROTECTED, so that the driver can configure the
> > dpu's protection bits (to access the memory with special signals).
>
> If we allocate a secure buffer there's no need for flags anymore I
> think - it would be a property of the underlying buffer (like a
> contiguous buffer). All we need are two things:
> - make sure secure buffers can only be imported by secure-buffer aware drivers
> - some way for such drivers to figure out whether they deal with a
> secure buffer or not.
I am with you on this. Yes, we
[PATCH] dma-buf: Implement simple read/write vfs ops
It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface. There may also be a small advantage to
avoiding the mmap() for very simple/small operations.
Note in particular, synchronisation with the device is left to the
caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
inside the read/write, so that the user can avoid synchronisation if
they so choose.
"It is easier to add synchronisation later, than it is to take it away."
v2: Lots of little fixes, plus a real llseek() implements so that the
first basic little test cases work!
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Janusz Krzysztofik
Tested-by: Laura Abbott
---
Dusting this off again as it would be nice as a user to operate on dmabuf
agnostic to the underyling driver. We have mmap, so naturally we would
like to have read/write as well!
---
drivers/dma-buf/dma-buf.c | 108 --
1 file changed, 93 insertions(+), 15 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 433d91d710e4..a19fc881a99c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -135,28 +135,104 @@ static int dma_buf_mmap_internal(struct file *file,
struct vm_area_struct *vma)
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
{
- struct dma_buf *dmabuf;
- loff_t base;
+ struct dma_buf *dmabuf = file->private_data;
if (!is_dma_buf_file(file))
return -EBADF;
- dmabuf = file->private_data;
+ return fixed_size_llseek(file, offset, whence, dmabuf->size);
+}
- /* only support discovering the end of the buffer,
- but also allow SEEK_SET to maintain the idiomatic
- SEEK_END(0), SEEK_CUR(0) pattern */
- if (whence == SEEK_END)
- base = dmabuf->size;
- else if (whence == SEEK_SET)
- base = 0;
- else
- return -EINVAL;
+static ssize_t dma_buf_read(struct file *file,
+ char __user *ubuf, size_t remain,
+ loff_t *offset)
+{
+ struct dma_buf *dmabuf = file->private_data;
+ unsigned long idx;
+ unsigned int start;
+ size_t total;
- if (offset != 0)
- return -EINVAL;
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ total = 0;
+ idx = *offset >> PAGE_SHIFT;
+ start = offset_in_page(*offset);
+ while (remain) {
+ unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+ unsigned int copied;
+ void *vaddr;
+
+ if (*offset >= dmabuf->size)
+ return total;
+
+ vaddr = dma_buf_kmap(dmabuf, idx);
+ if (!vaddr)
+ return total ?: -EIO;
+
+ copied = copy_to_user(ubuf, vaddr + start, len);
+ dma_buf_kunmap(dmabuf, idx, vaddr);
+
+ total += copied ?: len;
+ if (copied) {
+ *offset += copied;
+ return total ?: -EFAULT;
+ }
+
+ remain -= len;
+ *offset += len;
+ ubuf += len;
+ start = 0;
+ idx++;
+ }
+
+ return total;
+}
+
+static ssize_t dma_buf_write(struct file *file,
+const char __user *ubuf, size_t remain,
+loff_t *offset)
+{
+ struct dma_buf *dmabuf = file->private_data;
+ unsigned long idx;
+ unsigned int start;
+ size_t total;
+
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ total = 0;
+ idx = *offset >> PAGE_SHIFT;
+ start = offset_in_page(*offset);
+ while (remain) {
+ unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+ unsigned int copied;
+ void *vaddr;
+
+ if (*offset >= dmabuf->size)
+ return total;
+
+ vaddr = dma_buf_kmap(dmabuf, idx);
+ if (!vaddr)
+ return total ?: -EIO;
+
+ copied = copy_from_user(vaddr + start, ubuf, len);
+ dma_buf_kunmap(dmabuf, idx, vaddr);
+
+ total += copied ?: len;
+ if (copied) {
+ *offset += copied;
+ return total ?: -EFAULT;
+ }
+
+ remain -= len;
+ *offset += len;
+ ubuf += len;
+ start = 0;
+ idx++;
+ }
- return base + offset;
+ return
Re: [PATCH v7 3/4] ASoC: rockchip_max98090: Add dai_link for HDMI
Hi!
Dne četrtek, 19. september 2019 ob 15:54:49 CEST je Cheng-Yi Chiang
napisal(a):
> Use two dai_links. One for HDMI and one for max98090.
> With this setup, audio can play to speaker and HDMI selectively.
>
> Signed-off-by: Cheng-Yi Chiang
> ---
> .../boot/dts/rk3288-veyron-analog-audio.dtsi | 1 +
> sound/soc/rockchip/rockchip_max98090.c| 129 ++
> 2 files changed, 103 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
> b/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi index
> 445270aa136e..51208d161d65 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi
> @@ -17,6 +17,7 @@
> rockchip,hp-det-gpios = < RK_PA5
GPIO_ACTIVE_HIGH>;
> rockchip,mic-det-gpios = < RK_PB3
GPIO_ACTIVE_LOW>;
> rockchip,headset-codec = <>;
> + rockchip,hdmi-codec = <>;
> };
> };
>
> diff --git a/sound/soc/rockchip/rockchip_max98090.c
> b/sound/soc/rockchip/rockchip_max98090.c index c5fc24675a33..6c217492bb30
> 100644
> --- a/sound/soc/rockchip/rockchip_max98090.c
> +++ b/sound/soc/rockchip/rockchip_max98090.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -41,6 +42,7 @@ static const struct snd_soc_dapm_widget rk_dapm_widgets[]
> = { SND_SOC_DAPM_MIC("Headset Mic", NULL),
> SND_SOC_DAPM_MIC("Int Mic", NULL),
> SND_SOC_DAPM_SPK("Speaker", NULL),
> + SND_SOC_DAPM_LINE("HDMI", NULL),
> };
>
> static const struct snd_soc_dapm_route rk_audio_map[] = {
> @@ -52,6 +54,7 @@ static const struct snd_soc_dapm_route rk_audio_map[] = {
> {"Headphone", NULL, "HPR"},
> {"Speaker", NULL, "SPKL"},
> {"Speaker", NULL, "SPKR"},
> + {"HDMI", NULL, "TX"},
> };
>
> static const struct snd_kcontrol_new rk_mc_controls[] = {
> @@ -59,6 +62,7 @@ static const struct snd_kcontrol_new rk_mc_controls[] = {
> SOC_DAPM_PIN_SWITCH("Headset Mic"),
> SOC_DAPM_PIN_SWITCH("Int Mic"),
> SOC_DAPM_PIN_SWITCH("Speaker"),
> + SOC_DAPM_PIN_SWITCH("HDMI"),
> };
>
> static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
> @@ -92,38 +96,63 @@ static int rk_aif1_hw_params(struct snd_pcm_substream
> *substream,
>
> ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
>SND_SOC_CLOCK_OUT);
> - if (ret < 0) {
> - dev_err(codec_dai->dev, "Can't set codec clock %d\n",
ret);
> + if (ret) {
> + dev_err(cpu_dai->dev, "Can't set cpu dai clock %d\n",
ret);
> return ret;
> }
>
> + /* HDMI codec dai does not need to set sysclk. */
> + if (!strcmp(rtd->dai_link->name, "HDMI"))
> + return 0;
> +
> ret = snd_soc_dai_set_sysclk(codec_dai, 0, mclk,
>SND_SOC_CLOCK_IN);
> - if (ret < 0) {
> - dev_err(codec_dai->dev, "Can't set codec clock %d\n",
ret);
> + if (ret) {
> + dev_err(codec_dai->dev, "Can't set codec dai clock
%d\n", ret);
> return ret;
> }
>
> - return ret;
> + return 0;
> }
>
> static const struct snd_soc_ops rk_aif1_ops = {
> .hw_params = rk_aif1_hw_params,
> };
>
> -SND_SOC_DAILINK_DEFS(hifi,
> - DAILINK_COMP_ARRAY(COMP_EMPTY()),
> - DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "HiFi")),
> - DAILINK_COMP_ARRAY(COMP_EMPTY()));
> -
> -static struct snd_soc_dai_link rk_dailink = {
> - .name = "max98090",
> - .stream_name = "Audio",
> - .ops = _aif1_ops,
> - /* set max98090 as slave */
> - .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
> - SND_SOC_DAIFMT_CBS_CFS,
> - SND_SOC_DAILINK_REG(hifi),
> +SND_SOC_DAILINK_DEFS(analog,
> + DAILINK_COMP_ARRAY(COMP_EMPTY()),
> + DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "HiFi")),
> + DAILINK_COMP_ARRAY(COMP_EMPTY()));
> +
> +SND_SOC_DAILINK_DEFS(hdmi,
> + DAILINK_COMP_ARRAY(COMP_EMPTY()),
> + DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "i2s-hifi")),
> + DAILINK_COMP_ARRAY(COMP_EMPTY()));
> +
> +enum {
> + DAILINK_MAX98090,
> + DAILINK_HDMI,
> +};
> +
> +/* max98090 and HDMI codec dai_link */
> +static struct snd_soc_dai_link rk_dailinks[] = {
> + [DAILINK_MAX98090] = {
> + .name = "max98090",
> + .stream_name = "Analog",
> + .ops = _aif1_ops,
> + /* set max98090 as slave */
> + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
> + SND_SOC_DAIFMT_CBS_CFS,
> + SND_SOC_DAILINK_REG(analog),
> + },
> + [DAILINK_HDMI] = {
> + .name = "HDMI",
> + .stream_name = "HDMI",
> + .ops = _aif1_ops,
> + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
> +
Re: [PATCH] drm: damage_helper: Fix race checking plane->state->fb
On Thu, Sep 05, 2019 at 12:41:27PM +0200, Daniel Vetter wrote:
> On Wed, Sep 4, 2019 at 10:29 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Since the dirtyfb ioctl doesn't give us any hints as to which plane is
> > scanning out the fb it's marking as damaged, we need to loop through
> > planes to find it.
> >
> > Currently we just reach into plane state and check, but that can race
> > with another commit changing the fb out from under us. This patch locks
> > the plane before checking the fb and will release the lock if the plane
> > is not displaying the dirty fb.
> >
> > Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
> > Cc: Rob Clark
> > Cc: Deepak Rawat
> > Cc: Daniel Vetter
> > Cc: Thomas Hellstrom
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: # v5.0+
> > Reported-by: Daniel Vetter
> > Signed-off-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_damage_helper.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_damage_helper.c
> > b/drivers/gpu/drm/drm_damage_helper.c
> > index 8230dac01a89..3a4126dc2520 100644
> > --- a/drivers/gpu/drm/drm_damage_helper.c
> > +++ b/drivers/gpu/drm/drm_damage_helper.c
> > @@ -212,8 +212,14 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer
> > *fb,
> > drm_for_each_plane(plane, fb->dev) {
> > struct drm_plane_state *plane_state;
> >
> > - if (plane->state->fb != fb)
> > + ret = drm_modeset_lock(>mutex, state->acquire_ctx);
> > + if (ret)
>
> I think for paranoid safety we should have a WARN_ON(ret == -EALREADY)
> here. It should be impossible, but if it's not for some oddball
> reason, we'll blow up.
drm_modeset_lock eats EALREADY and returns 0 for that case, so I guess it
depends _how_ paranoid you want to be here :-)
>
> With that: Reviewed-by: Daniel Vetter
>
> But please give this a spin with some workloads and the ww_mutex
> slowpath debugging enabled, just to makre sure.
Ok, had a chance to run through some tests this morning with
CONFIG_DEBUG_WW_MUTEX_SLOWPATH and things lgtm
Sean
> -Daniel
>
> > + goto out;
> > +
> > + if (plane->state->fb != fb) {
> > + drm_modeset_unlock(>mutex);
> > continue;
> > + }
> >
> > plane_state = drm_atomic_get_plane_state(state, plane);
> > if (IS_ERR(plane_state)) {
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: pxafb: Use devm_platform_ioremap_resource() in pxafb_probe()
From: Markus Elfring
Date: Thu, 19 Sep 2019 16:51:38 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/pxafb.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index f70c9f79622e..237f8f436fdb 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2237,7 +2237,6 @@ static int pxafb_probe(struct platform_device *dev)
{
struct pxafb_info *fbi;
struct pxafb_mach_info *inf, *pdata;
- struct resource *r;
int i, irq, ret;
dev_dbg(>dev, "pxafb_probe\n");
@@ -2303,14 +2302,7 @@ static int pxafb_probe(struct platform_device *dev)
fbi->lcd_supply = NULL;
}
- r = platform_get_resource(dev, IORESOURCE_MEM, 0);
- if (r == NULL) {
- dev_err(>dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed;
- }
-
- fbi->mmio_base = devm_ioremap_resource(>dev, r);
+ fbi->mmio_base = devm_platform_ioremap_resource(dev, 0);
if (IS_ERR(fbi->mmio_base)) {
dev_err(>dev, "failed to get I/O memory\n");
ret = -EBUSY;
--
2.23.0
Re: [PATCH] drm/msm: include linux/sched/task.h
On Wed, Sep 18, 2019 at 09:57:07PM +0200, Arnd Bergmann wrote:
> Without this header file, compile-testing may run into a missing
> declaration:
>
> drivers/gpu/drm/msm/msm_gpu.c:444:4: error: implicit declaration of function
> 'put_task_struct' [-Werror,-Wimplicit-function-declaration]
>
> Fixes: 482f96324a4e ("drm/msm: Fix task dump in gpu recovery")
Reviewed-by: Jordan Crouse
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index a052364a5d74..edd45f434ccd 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Power Management:
> --
> 2.20.0
>
--
The Qualcomm Innovation Center, Inc. is a member of 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
Re: [PATCH] drm/komeda: Fix FLIP_COMPLETE timestamp on CRTC enable
On Thursday, 19 September 2019 14:30:02 BST Mihail Atanassov wrote:
> When initially turning a crtc on, drm_reset_vblank_timestamp will
> set the vblank timestamp to 0 for any driver that doesn't provide
> a ->get_vblank_timestamp() hook.
>
> Unfortunately, the FLIP_COMPLETE event depends on that timestamp,
> and the only way to regenerate a valid one is to have vblank
> interrupts enabled and have a valid in-ISR call to
> drm_crtc_handle_vblank.
>
> Wrap the call to komeda_crtc_do_flush in ->atomic_enable() with a
> drm_crtc_vblank_{get,put} pair so we can have a vblank ISR prior to
> the FLIP_COMPLETE ISR (or more likely, they'll get handled in the same
> ISR, which is equally valid).
>
> Cc: Daniel Vetter
> Cc: Liviu Dudau
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index f4400788ab94..87420a767bc4 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -258,7 +258,9 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc,
> {
> komeda_crtc_prepare(to_kcrtc(crtc));
> drm_crtc_vblank_on(crtc);
> + WARN_ON(drm_crtc_vblank_get(crtc));
> komeda_crtc_do_flush(crtc, old);
> + drm_crtc_vblank_put(crtc);
> }
>
> static void
>
Please ignore, this doesn't work (page flips after 5 seconds don't get
an updated timestamp because of the delayed vsync disable). I'll push
a v2 soon where vsync on/off tracks crtc enable/disable.
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: ocfb: Use devm_platform_ioremap_resource() in ocfb_probe()
From: Markus Elfring
Date: Thu, 19 Sep 2019 16:26:56 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/ocfb.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
index a970edc2a6f8..be308b4dc91d 100644
--- a/drivers/video/fbdev/ocfb.c
+++ b/drivers/video/fbdev/ocfb.c
@@ -297,7 +297,6 @@ static int ocfb_probe(struct platform_device *pdev)
{
int ret = 0;
struct ocfb_dev *fbdev;
- struct resource *res;
int fbsize;
fbdev = devm_kzalloc(>dev, sizeof(*fbdev), GFP_KERNEL);
@@ -319,13 +318,7 @@ static int ocfb_probe(struct platform_device *pdev)
ocfb_init_var(fbdev);
ocfb_init_fix(fbdev);
- /* Request I/O resource */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(>dev, "I/O resource request failed\n");
- return -ENXIO;
- }
- fbdev->regs = devm_ioremap_resource(>dev, res);
+ fbdev->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbdev->regs))
return PTR_ERR(fbdev->regs);
--
2.23.0
[RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
The following patchset adds interconnect[1][2] framework support to the exynos-bus devfreq driver. Extending the devfreq driver with interconnect capabilities started as a response to the issue referenced in [3]. The patches can be subdivided into four logical groups: (a) Refactoring the existing devfreq driver in order to improve readability and accommodate for adding new code (patches 01--04/11). (b) Tweaking the interconnect framework to support the exynos-bus use case (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to avoid hardcoding every single graph edge in the DT or driver source, and relaxing the requirement contained in that function removes the need to provide dummy node IDs in the DT. Adjusting the logic in apply_constraints() (drivers/interconnect/core.c) accounts for the fact that every bus is a separate entity and therefore a separate interconnect provider, albeit constituting a part of a larger hierarchy. (c) Implementing interconnect providers in the exynos-bus devfreq driver and adding required DT properties for one selected platform, namely Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a generic driver for various Exynos SoCs, node IDs are generated dynamically rather than hardcoded. This has been determined to be a simpler approach, but depends on changes described in (b). (d) Implementing a sample interconnect consumer for exynos-mixer targeted at the issue referenced in [3], again with DT info only for Exynos4412 (patches 10--11/11). Integration of devfreq and interconnect functionalities is achieved by using dev_pm_qos_*() API[5]. All new code works equally well when CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all interconnect API functions are no-ops. This patchset depends on [5]. --- Changes since v1 [6]: * Rebase on [4] (coupled regulators). * Rebase on [5] (dev_pm_qos for devfreq). * Use dev_pm_qos_*() API[5] instead of overriding frequency in exynos_bus_target(). * Use IDR for node ID allocation. * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04). * Reverse order of multiplication and division in mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow. --- Artur Świgoń Samsung R Institute Poland Samsung Electronics --- References: [1] Documentation/interconnect/interconnect.rst [2] Documentation/devicetree/bindings/interconnect/interconnect.txt [3] https://patchwork.kernel.org/patch/10861757/ (original issue) [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged) [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq) [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) Artur Świgoń (10): devfreq: exynos-bus: Extract exynos_bus_profile_init() devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() devfreq: exynos-bus: Change goto-based logic to if-else logic devfreq: exynos-bus: Clean up code interconnect: Export of_icc_get_from_provider() interconnect: Relax requirement in of_icc_get_from_provider() interconnect: Relax condition in apply_constraints() arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412 devfreq: exynos-bus: Add interconnect functionality to exynos-bus arm: dts: exynos: Add interconnects to Exynos4412 mixer Marek Szyprowski (1): drm: exynos: mixer: Add interconnect support .../boot/dts/exynos4412-odroid-common.dtsi| 1 + arch/arm/boot/dts/exynos4412.dtsi | 10 + drivers/devfreq/exynos-bus.c | 319 +- drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++- drivers/interconnect/core.c | 12 +- include/linux/interconnect-provider.h | 6 + 6 files changed, 327 insertions(+), 92 deletions(-) -- 2.17.1
[RFC PATCH v2 11/11] drm: exynos: mixer: Add interconnect support
From: Marek Szyprowski
This patch adds interconnect support to exynos-mixer. Please note that the
mixer works the same as before when CONFIG_INTERCONNECT is 'n'.
Co-developed-by: Artur Świgoń
Signed-off-by: Marek Szyprowski
Signed-off-by: Artur Świgoń
---
drivers/gpu/drm/exynos/exynos_mixer.c | 71 +--
1 file changed, 66 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 7b24338fad3c..a44f3284b071 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,6 +98,7 @@ struct mixer_context {
struct exynos_drm_crtc *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
unsigned long flags;
+ struct icc_path *soc_path;
int irq;
void __iomem*mixer_regs;
@@ -931,6 +933,40 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
+static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
+{
+ struct drm_display_mode *mode = >base.state->adjusted_mode;
+ struct mixer_context *ctx = crtc->ctx;
+ unsigned long bw, bandwidth = 0;
+ int i, j, sub;
+
+ if (!ctx->soc_path)
+ return;
+
+ for (i = 0; i < MIXER_WIN_NR; i++) {
+ struct drm_plane *plane = >planes[i].base;
+ const struct drm_format_info *format;
+
+ if (plane->state && plane->state->crtc && plane->state->fb) {
+ format = plane->state->fb->format;
+ bw = mode->hdisplay * mode->vdisplay *
+ drm_mode_vrefresh(mode);
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ bw /= 2;
+ for (j = 0; j < format->num_planes; j++) {
+ sub = j ? (format->vsub * format->hsub) : 1;
+ bandwidth += format->cpp[j] * bw / sub;
+ }
+ }
+ }
+
+ /* add 20% safety margin */
+ bandwidth = bandwidth / 4 * 5;
+
+ dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
+ icc_set_bw(ctx->soc_path, Bps_to_icc(bandwidth), 0);
+}
+
static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
@@ -982,6 +1018,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc
*crtc)
if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
+ mixer_set_memory_bandwidth(crtc);
mixer_enable_sync(mixer_ctx);
exynos_crtc_handle_event(crtc);
}
@@ -1029,6 +1066,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);
+ mixer_set_memory_bandwidth(crtc);
exynos_drm_pipe_clk_enable(crtc, false);
pm_runtime_put(ctx->dev);
@@ -1220,12 +1258,22 @@ static int mixer_probe(struct platform_device *pdev)
struct device *dev = >dev;
const struct mixer_drv_data *drv;
struct mixer_context *ctx;
+ struct icc_path *path;
int ret;
+ /*
+* Returns NULL if CONFIG_INTERCONNECT is disabled.
+* May return ERR_PTR(-EPROBE_DEFER).
+*/
+ path = of_icc_get(dev, NULL);
+ if (IS_ERR(path))
+ return PTR_ERR(path);
+
ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
DRM_DEV_ERROR(dev, "failed to alloc mixer context.\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
drv = of_device_get_match_data(dev);
@@ -1233,6 +1281,7 @@ static int mixer_probe(struct platform_device *pdev)
ctx->pdev = pdev;
ctx->dev = dev;
ctx->mxr_ver = drv->version;
+ ctx->soc_path = path;
if (drv->is_vp_enabled)
__set_bit(MXR_BIT_VP_ENABLED, >flags);
@@ -1242,17 +1291,29 @@ static int mixer_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ret = component_add(>dev, _component_ops);
- if (!ret)
- pm_runtime_enable(dev);
+ if (ret < 0)
+ goto err;
+
+ pm_runtime_enable(dev);
+
+ return 0;
+
+err:
+ icc_put(path);
return ret;
}
static int mixer_remove(struct platform_device *pdev)
{
- pm_runtime_disable(>dev);
+ struct device *dev = >dev;
+ struct mixer_context *ctx = dev_get_drvdata(dev);
- component_del(>dev, _component_ops);
+ pm_runtime_disable(dev);
+
+ component_del(dev, _component_ops);
+
+
[RFC PATCH v2 07/11] interconnect: Relax condition in apply_constraints()
From: Artur Świgoń
The exynos-bus devfreq driver is extended with interconnect functionality
by a subsequent patch. This patch removes a check from the interconnect
framework that prevents interconnect from working on exynos-bus, in which
every bus is a separate interconnect provider.
Signed-off-by: Artur Świgoń
---
drivers/interconnect/core.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index f357c3a78858..e8243665d5ba 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -224,11 +224,8 @@ static int apply_constraints(struct icc_path *path)
for (i = 0; i < path->num_nodes; i++) {
next = path->reqs[i].node;
- /*
-* Both endpoints should be valid master-slave pairs of the
-* same interconnect provider that will be configured.
-*/
- if (!prev || next->provider != prev->provider) {
+ /* both endpoints should be valid master-slave pairs */
+ if (!prev) {
prev = next;
continue;
}
--
2.17.1
[RFC PATCH v2 03/11] devfreq: exynos-bus: Change goto-based logic to if-else logic
From: Artur Świgoń This patch improves code readability by changing the following construct: >if (cond) >goto passive; >foo(); >goto out; >passive: >bar(); >out: into this: >if (cond) >bar(); >else >foo(); Signed-off-by: Artur Świgoń --- drivers/devfreq/exynos-bus.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c index f85bed241631..60ad4319fd80 100644 --- a/drivers/devfreq/exynos-bus.c +++ b/drivers/devfreq/exynos-bus.c @@ -420,19 +420,13 @@ static int exynos_bus_probe(struct platform_device *pdev) goto err_reg; if (passive) - goto passive; + ret = exynos_bus_profile_init_passive(bus, profile); + else + ret = exynos_bus_profile_init(bus, profile); - ret = exynos_bus_profile_init(bus, profile); if (ret < 0) goto err; - goto out; -passive: - ret = exynos_bus_profile_init_passive(bus, profile); - if (ret < 0) - goto err; - -out: max_state = bus->devfreq->profile->max_state; min_freq = (bus->devfreq->profile->freq_table[0] / 1000); max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000); -- 2.17.1
[PATCH 3/3] drm/atomic-helper: Improve drm_atomic_helper_check_plane_state() debugs
From: Ville Syrjälä
Dump out the plane/crtc id/name in the failure debug messages.
Makes a bit easier to figure out which plane exactly has failed
when you have tons of them.
Cc: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9de39da54c48..86a2839dbfdd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -761,6 +761,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
bool can_update_disabled)
{
struct drm_plane *plane = plane_state->plane;
+ struct drm_crtc *crtc = crtc_state->crtc;
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = _state->src;
struct drm_rect *dst = _state->dst;
@@ -785,7 +786,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
}
if (!crtc_state->enable && !can_update_disabled) {
- DRM_DEBUG_KMS("Cannot update plane of a disabled CRTC.\n");
+ DRM_DEBUG_KMS("Cannot update [PLANE:%d:%s] of disabled
[CRTC:%d:%s].\n",
+ plane->base.id, plane->name,
+ crtc->base.id, crtc->name);
return -EINVAL;
}
@@ -831,7 +834,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
return 0;
if (!can_position && !drm_rect_equals(dst, )) {
- DRM_DEBUG_KMS("Plane must cover entire CRTC\n");
+ DRM_DEBUG_KMS("[PLANE:%d:%s] must cover entire [CRTC:%d:%s]\n",
+ plane->base.id, plane->name,
+ crtc->base.id, crtc->name);
drm_rect_debug_print("dst: ", dst, false);
drm_rect_debug_print("clip: ", , false);
return -EINVAL;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/atomic: Pimp the debugs for scaling fails
From: Ville Syrjälä
When the calculate scaling factors are out of range let's
print out the calculated value and the min/max. Should make
life a bit less confusing when decoding failure logs.
I decided to print them in decimal rather than hex. Not sure
which people prefer but maybe this is less confusing to the
casual reader at least.
Also write out the magic 15625 constant we use in
the binary->decimal conversion as '100 >> (16-10)'
to make it more clear how it relates to the final '>> 10'.
Suggested-by: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 19 ---
include/drm/drm_rect.h | 29 ++---
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c60db3bf2a83..9de39da54c48 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -760,6 +760,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
bool can_position,
bool can_update_disabled)
{
+ struct drm_plane *plane = plane_state->plane;
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = _state->src;
struct drm_rect *dst = _state->dst;
@@ -792,12 +793,24 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
/* Check scaling */
ret = drm_rect_calc_hscale(src, dst, min_scale, max_scale, );
- ret |= drm_rect_calc_vscale(src, dst, min_scale, max_scale, );
if (ret) {
- DRM_DEBUG_KMS("Invalid scaling of plane\n");
+ DRM_DEBUG_KMS("[PLANE:%d:%s] Invalid horizontal scaling factor:
"
+ DRM_FP_FMT " (limits: " DRM_FP_FMT " - "
DRM_FP_FMT ")\n",
+ plane->base.id, plane->name, DRM_FP_ARG(hscale),
+ DRM_FP_ARG(min_scale), DRM_FP_ARG(max_scale));
drm_rect_debug_print("src: ", _state->src, true);
drm_rect_debug_print("dst: ", _state->dst, false);
- return -ERANGE;
+ return ret;
+ }
+ ret = drm_rect_calc_vscale(src, dst, min_scale, max_scale, );
+ if (ret) {
+ DRM_DEBUG_KMS("[PLANE:%d:%s] Invalid vertical scaling factor: "
+ DRM_FP_FMT " (limits: " DRM_FP_FMT " - "
DRM_FP_FMT ")\n",
+ plane->base.id, plane->name, DRM_FP_ARG(vscale),
+ DRM_FP_ARG(min_scale), DRM_FP_ARG(max_scale));
+ drm_rect_debug_print("src: ", _state->src, true);
+ drm_rect_debug_print("dst: ", _state->dst, false);
+ return ret;
}
if (crtc_state->enable)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 34a88ba9ca7b..f700ef39f328 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -53,21 +53,36 @@ struct drm_rect {
#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, (r)->y1
/**
- * DRM_RECT_FP_FMT - printf string for drm_rect in 16.16 fixed point
+ * DRM_FP_FMT - printf string for 16.16 binary fixed point
+ *
+ * Format a 16.16 binary fixed point number as .6 decimal fixed point.
+ */
+#define DRM_FP_FMT "%d.%06u"
+/**
+ * DRM_FP_ARG - printf arguments for 16.16 binary fixed point
+ * @f: 16.16 binary fixed point number
+ *
+ * This is useful for e.g. printing plane scaling factors, which are in 16.16
+ * binary fixed point.
+ */
+#define DRM_FP_ARG(f) (f) >> 16, (((f) & 0x) * (100 >> (16 - 10))) >>
10
+
+/**
+ * DRM_RECT_FP_FMT - printf string for drm_rect in 16.16 binary fixed
point
+ *
+ * Format a 16.16 binary fixed point rectangle as .6 decimal fixed point.
*/
#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
/**
- * DRM_RECT_FP_ARG - printf arguments for drm_rect in 16.16 fixed point
+ * DRM_RECT_FP_ARG - printf arguments for drm_rect in 16.16 binary
fixed point
* @r: rectangle struct
*
* This is useful for e.g. printing plane source rectangles, which are in 16.16
- * fixed point.
+ * binary fixed point.
*/
#define DRM_RECT_FP_ARG(r) \
- drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625)
>> 10, \
- drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) *
15625) >> 10, \
- (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
- (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
+ DRM_FP_ARG(drm_rect_width(r)), DRM_FP_ARG(drm_rect_height(r)), \
+ DRM_FP_ARG((r)->x1), DRM_FP_ARG((r)->y1)
/**
* drm_rect_adjust_size - adjust the size of the rectangle
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/rect: Return scaling factor and error code separately
From: Ville Syrjälä
We may want to dump out the calculated scaling factor(s) when
they exceed the limits. To achieve that we need to return the
error code and scaling factor separately.
Side note: the code in dpu_plane_validate_multirect_v2()
looks rather dubious on account of it not using fixed point
numbers. Not sure the rounding behaviour we have really
satisfies what it's trying to do. Maybe it should just do
(src_w!=dst_w || src_h!=dst_h) ?
Cc: Jeykumar Sankaran
Suggested-by: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 8 ++---
drivers/gpu/drm/drm_rect.c | 34 -
drivers/gpu/drm/i915/display/intel_sprite.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 +++--
include/drm/drm_rect.h | 6 ++--
5 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c861a871299d..c60db3bf2a83 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -765,7 +765,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
struct drm_rect *dst = _state->dst;
unsigned int rotation = plane_state->rotation;
struct drm_rect clip = {};
- int hscale, vscale;
+ int hscale, vscale, ret;
WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
@@ -791,9 +791,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
/* Check scaling */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
- vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
- if (hscale < 0 || vscale < 0) {
+ ret = drm_rect_calc_hscale(src, dst, min_scale, max_scale, );
+ ret |= drm_rect_calc_vscale(src, dst, min_scale, max_scale, );
+ if (ret) {
DRM_DEBUG_KMS("Invalid scaling of plane\n");
drm_rect_debug_print("src: ", _state->src, true);
drm_rect_debug_print("dst: ", _state->dst, false);
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index b8363aaa9032..f014107d11a5 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -145,6 +145,7 @@ static int drm_calc_scale(int src, int dst)
* @dst: destination window rectangle
* @min_hscale: minimum allowed horizontal scaling factor
* @max_hscale: maximum allowed horizontal scaling factor
+ * @hscale: calculated horizontal scaling factor
*
* Calculate the horizontal scaling factor as
* (@src width) / (@dst width).
@@ -154,23 +155,25 @@ static int drm_calc_scale(int src, int dst)
* pessimistic limit calculation.
*
* RETURNS:
- * The horizontal scaling factor, or errno of out of limits.
+ * Zero on success, or errno on out of limits.
*/
int drm_rect_calc_hscale(const struct drm_rect *src,
const struct drm_rect *dst,
-int min_hscale, int max_hscale)
+int min_hscale, int max_hscale,
+int *hscale)
{
int src_w = drm_rect_width(src);
int dst_w = drm_rect_width(dst);
- int hscale = drm_calc_scale(src_w, dst_w);
- if (hscale < 0 || dst_w == 0)
- return hscale;
+ *hscale = drm_calc_scale(src_w, dst_w);
- if (hscale < min_hscale || hscale > max_hscale)
+ if (*hscale < 0 || dst_w == 0)
+ return *hscale;
+
+ if (*hscale < min_hscale || *hscale > max_hscale)
return -ERANGE;
- return hscale;
+ return 0;
}
EXPORT_SYMBOL(drm_rect_calc_hscale);
@@ -180,6 +183,7 @@ EXPORT_SYMBOL(drm_rect_calc_hscale);
* @dst: destination window rectangle
* @min_vscale: minimum allowed vertical scaling factor
* @max_vscale: maximum allowed vertical scaling factor
+ * @hscale: calculated vertical scaling factor
*
* Calculate the vertical scaling factor as
* (@src height) / (@dst height).
@@ -189,23 +193,25 @@ EXPORT_SYMBOL(drm_rect_calc_hscale);
* pessimistic limit calculation.
*
* RETURNS:
- * The vertical scaling factor, or errno of out of limits.
+ * Zero on success, or errno on out of limits.
*/
int drm_rect_calc_vscale(const struct drm_rect *src,
const struct drm_rect *dst,
-int min_vscale, int max_vscale)
+int min_vscale, int max_vscale,
+int *vscale)
{
int src_h = drm_rect_height(src);
int dst_h = drm_rect_height(dst);
- int vscale = drm_calc_scale(src_h, dst_h);
- if (vscale < 0 || dst_h == 0)
- return vscale;
+ *vscale = drm_calc_scale(src_h, dst_h);
+
+ if (*vscale < 0 || dst_h == 0)
+ return *vscale;
- if (vscale < min_vscale || vscale >
[PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2019-09-19: - Extend old HSW workaround to fix some GPU hangs on Haswell GT2 - Fix return error code on GEM mmap. - White list a chicken bit register for push constants legacy mode on Mesa - Fix resume issue related to GGTT restore - Remove incorrect BUG_ON on execlist's schedule-out - Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL Thanks, Rodrigo. The following changes since commit 6e5c5272ca00809aae20817efb6f25881268b50b: drm/i915: Use NOEVICT for first pass on attemping to pin a GGTT mmap (2019-09-06 09:53:15 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-09-19 for you to fetch changes up to a95819a173788bec7414d260f76f42a9934890b4: drm/i915: Extend Haswell GT1 PSMI workaround to all (2019-09-18 10:53:38 -0700) - Extend old HSW workaround to fix some GPU hangs on Haswell GT2 - Fix return error code on GEM mmap. - White list a chicken bit register for push constants legacy mode on Mesa - Fix resume issue related to GGTT restore - Remove incorrect BUG_ON on execlist's schedule-out - Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL Chris Wilson (5): drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ drm/i915/execlists: Remove incorrect BUG_ON for schedule-out drm/i915: Perform GGTT restore much earlier during resume drm/i915: Don't mix srcu tag and negative error codes drm/i915: Extend Haswell GT1 PSMI workaround to all Kenneth Graunke (1): drm/i915: Whitelist COMMON_SLICE_CHICKEN2 drivers/gpu/drm/i915/gem/i915_gem_mman.c| 6 ++ drivers/gpu/drm/i915/gem/i915_gem_pm.c | 3 --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 - drivers/gpu/drm/i915/gt/intel_reset.c | 8 +++- drivers/gpu/drm/i915/gt/intel_reset.h | 2 +- drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++- drivers/gpu/drm/i915/i915_drv.c | 5 + drivers/gpu/drm/i915/selftests/i915_gem.c | 6 ++ 9 files changed, 21 insertions(+), 20 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm: Measure Self Refresh Entry/Exit times to avoid thrashing
On Wed, Sep 18, 2019 at 04:07:29PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Currently the self refresh idle timer is a const set by the crtc. This
> is fine if the self refresh entry/exit times are well-known for all
> panels used on that crtc. However panels and workloads can vary quite a
> bit, and a timeout which works well for one doesn't work well for
> another.
>
> In the extreme, if the timeout is too short we could get in a situation
> where the self refresh exits are taking so long we queue up a self refresh
> entry before the exit commit is even finished.
>
> This patch changes the idle timeout to a moving average of the entry
> times + a moving average of exit times + the crtc constant.
>
> This patch was tested on rockchip, with a kevin CrOS panel the idle
> delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
> the same board, the bob panel idle delay lands around ~340ms (90 entry
> + 150 exit + 100 const).
>
> WRT the dedicated mutex in self_refresh_data, it would be nice if we
> could rely on drm_crtc.mutex to protect the average times, but there are
> a few reasons why a separate lock is a better choice:
> - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
> commit
> - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
> whether the lock was already held in the acquire context (it eats
> -EALREADY), so we can't tell if we should drop it or not
> - We don't need such a heavy-handed lock for what we're trying to do,
> commit ordering doesn't matter, so a point-of-use lock will be less
> contentious
>
> Reviewed-by: Daniel Vetter
Pushed the first 2 to drm-misc-next-fixes to fix the gru-bob regression. I'll
fix up the 3rd patch separately.
Thank you for the reviews!
Sean
> Signed-off-by: Sean Paul
> Link to v1:
> https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-s...@poorly.run
>
> Changes in v2:
> - Migrate locking explanation from comment to commit msg (Daniel)
> - Turf constant entry delay and multiply the avg times by 2 (Daniel)
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++
> drivers/gpu/drm/drm_self_refresh_helper.c | 72 +++--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +-
> include/drm/drm_self_refresh_helper.h | 6 +-
> 4 files changed, 90 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9d7e4da6c292..3f13fa9a9e24 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -26,6 +26,7 @@
> */
>
> #include
> +#include
>
> #include
> #include
> @@ -1570,9 +1571,23 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> const struct drm_mode_config_helper_funcs *funcs;
> + ktime_t start;
> + s64 commit_time_ms;
>
> funcs = dev->mode_config.helper_private;
>
> + /*
> + * We're measuring the _entire_ commit, so the time will vary depending
> + * on how many fences and objects are involved. For the purposes of self
> + * refresh, this is desirable since it'll give us an idea of how
> + * congested things are. This will inform our decision on how often we
> + * should enter self refresh after idle.
> + *
> + * These times will be averaged out in the self refresh helpers to avoid
> + * overreacting over one outlier frame
> + */
> + start = ktime_get();
> +
> drm_atomic_helper_wait_for_fences(dev, old_state, false);
>
> drm_atomic_helper_wait_for_dependencies(old_state);
> @@ -1582,6 +1597,11 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> else
> drm_atomic_helper_commit_tail(old_state);
>
> + commit_time_ms = ktime_ms_delta(ktime_get(), start);
> + if (commit_time_ms > 0)
> + drm_self_refresh_helper_update_avg_times(old_state,
> + (unsigned long)commit_time_ms);
> +
> drm_atomic_helper_commit_cleanup_done(old_state);
>
> drm_atomic_state_put(old_state);
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 9095cebf2147..68f4765a5896 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -5,6 +5,7 @@
> * Authors:
> * Sean Paul
> */
> +#include
> #include
> #include
> #include
> @@ -50,10 +51,17 @@
> * atomic_check when _crtc_state.self_refresh_active is true.
> */
>
> +#define SELF_REFRESH_AVG_SEED_MS 200
> +
> +DECLARE_EWMA(psr_time, 4, 4)
> +
> struct drm_self_refresh_data {
> struct drm_crtc *crtc;
> struct delayed_work entry_work;
> - unsigned int entry_delay_ms;
> +
> + struct mutex avg_mutex;
> + struct ewma_psr_time entry_avg_ms;
> + struct ewma_psr_time
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder wrote:
>
> On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
>
> Hi All,
> Thanks for your suggestions.
>
> > Hi Liviu,
> >
> > On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > > I totally agree. Framebuffers aren't about the underlying memory they
> > > > point to, but about how to _interpret_ that memory: it decorates a
> > > > pointer with width, height, stride, format, etc, to allow you to make
> > > > sense of that memory. I see content protection as being the same as
> > > > physical contiguity, which is a property of the underlying memory
> > > > itself. Regardless of the width, height, or format, you just cannot
> > > > access that memory unless it's under the appropriate ('secure enough')
> > > > conditions.
> > > >
> > > > So I think a dmabuf attribute would be most appropriate, since that's
> > > > where you have to do all your MMU handling, and everything else you
> > > > need to do to allow access to that buffer, anyway.
> > >
> > > Isn't it how AMD currently implements protected buffers as well?
> >
> > No idea to be honest, I haven't seen anything upstream.
> >
> > > > There's a lot of complexity beyond just 'it's protected'; for
> > > > instance, some CP providers mandate that their content can only be
> > > > streamed over HDCP 2.2 Type-1 when going through an external
> > > > connection. One way you could do that is to use a secure world
> > > > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > > > or TEE) to examine the display pipe configuration, and only then allow
> > > > access to the buffers and/or keys. Stuff like that is always going to
> > > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > > it should be possible to agree on at least the basic mechanics and
> > > > expectations of a secure path without things like that.
> > >
> > > I also expect that going through the secure world will be pretty much
> > > transparent for
> > > the kernel driver, as the most likely hardware implementations would
> > > enable
> > > additional signaling that will get trapped and handled by the secure OS.
> > > I'm not
> > > trying to simplify things, just taking the stance that it is userspace
> > > that is
> > > coordinating all this, we're trying only to find a common ground on how
> > > to handle
> > > this in the kernel.
> >
> > Yeah, makes sense.
> >
> > As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> > the 'protected' flag on the resulting dmabuf?
>
> To be honest, during our internal discussion james.qian.w...@arm.com had a
> similar suggestion of adding a new flag to dma_buf but I decided
> against it.
>
> As per my understanding, adding custom dma buf flags (like
> AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. We
> rely on the dumb allocator and ion allocator for framebuffer creation.
>
> I was looking at an allocator independent way of userspace
> communicating to the drm framework that the framebuffer is protected.
>
> Thus, it looked to me that framebuffer modifier is the best (or the least
> corrupt) way of going forth.
>
> We use ion and dumb allocator for framebuffer object creation. The way
> I see it is as follows :-
>
> 1. For ion allocator :-
> Userspace can specify that it wants the buffer from a secure heap or any other
> special region of heap. The ion driver will either fault into the secure os to
> create the buffers or it will do some other magic. Honestly, I have still not
> figured that out. But it will be agnostic to the drm core.
Allocating buffers from a special heap is what I expected the
interface to be. The issue is that if we specify the secure mode any
time later on, then it could be changed. E.g. with Daniel Stone's idea
of a handle2fd flag, you could export the buffer twice, once secure,
once non-secure. That sounds like a silly thing to me, and better to
prevent that - or is this actually possible/wanted, i.e. do we want to
change the secure mode for a buffer later on?
> The userspace gets a handle to the buffer and then it calls addFB2 with
> DRM_FORMAT_MOD_ARM_PROTECTED, so that the driver can configure the
> dpu's protection bits (to access the memory with special signals).
If we allocate a secure buffer there's no need for flags anymore I
think - it would be a property of the underlying buffer (like a
contiguous buffer). All we need are two things:
- make sure secure buffers can only be imported by secure-buffer aware drivers
- some way for such drivers to figure out whether they deal with a
secure buffer or not.
There's no need for any flags anywhere else with the ion/secure
dma-buf heap solution. E.g. for contig buffer we also dont pass around
a DRM_FORMAT_MOD_PHYSICALLY_CONTIG for addfb2.
> 2. For dumb allocator :-
> I am curious to know if we can add 'IS_PROTECTED' flag to
> drm_mode_create_dumb.flags. This
Re: [PATCH] drm: tweak drm_print_bits()
On Thu, 19 Sep 2019, Gerd Hoffmann wrote:
> There is little reason for the from/to logic, printing a subset of
> the bits can be done by simply shifting/masking value if needed.
>
> Also use for_each_set_bit().
Oh, I don't know why I stumbled upon and reviewed a patch that had
already been merged. Can't keep track of everything it seems...
>
> Suggested-by: Jani Nikula
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_print.h | 5 ++---
> drivers/gpu/drm/drm_gem_ttm_helper.c | 4 ++--
> drivers/gpu/drm/drm_print.c | 20 +---
> 3 files changed, 13 insertions(+), 16 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 12d4916254b4..5b9947d157f4 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -89,9 +89,8 @@ __printf(2, 3)
> void drm_printf(struct drm_printer *p, const char *f, ...);
> void drm_puts(struct drm_printer *p, const char *str);
> void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32
> *regset);
> -void drm_print_bits(struct drm_printer *p,
> - unsigned long value, const char *bits[],
> - unsigned int from, unsigned int to);
> +void drm_print_bits(struct drm_printer *p, unsigned long value,
> + const char * const bits[], int nbits);
>
> __printf(2, 0)
> /**
> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> b/drivers/gpu/drm/drm_gem_ttm_helper.c
> index 9a4bafcf20df..a534104d8bee 100644
> --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> @@ -23,7 +23,7 @@
> void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> const struct drm_gem_object *gem)
> {
> - static const char const *plname[] = {
> + static const char * const plname[] = {
> [ TTM_PL_SYSTEM ] = "system",
> [ TTM_PL_TT ] = "tt",
> [ TTM_PL_VRAM ] = "vram",
> @@ -40,7 +40,7 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
> int indent,
> const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
>
> drm_printf_indent(p, indent, "placement=");
> - drm_print_bits(p, bo->mem.placement, plname, 0, ARRAY_SIZE(plname));
> + drm_print_bits(p, bo->mem.placement, plname, ARRAY_SIZE(plname));
> drm_printf(p, "\n");
>
> if (bo->mem.bus.is_iomem) {
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index dfa27367ebb8..a495fe3ad909 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -189,28 +189,26 @@ EXPORT_SYMBOL(drm_printf);
> * drm_print_bits - print bits to a _printer stream
> *
> * Print bits (in flag fields for example) in human readable form.
> - * The first name in the @bits array is for the bit indexed by @from.
> *
> * @p: the _printer
> * @value: field value.
> * @bits: Array with bit names.
> - * @from: start of bit range to print (inclusive).
> - * @to: end of bit range to print (exclusive).
> + * @nbits: Size of bit names array.
> */
> -void drm_print_bits(struct drm_printer *p,
> - unsigned long value, const char *bits[],
> - unsigned int from, unsigned int to)
> +void drm_print_bits(struct drm_printer *p, unsigned long value,
> + const char * const bits[], int nbits)
> {
> bool first = true;
> unsigned int i;
>
> - for (i = from; i < to; i++) {
> - if (!(value & (1 << i)))
> - continue;
> - if (WARN_ON_ONCE(!bits[i-from]))
> + if (WARN_ON_ONCE(nbits > sizeof(unsigned long) * 8))
> + nbits = sizeof(unsigned long) * 8;
Might be neater with BITS_PER_TYPE(value) instead of open coding, but
either way,
Reviewed-by: Jani Nikula
> +
> + for_each_set_bit(i, , nbits) {
> + if (WARN_ON_ONCE(!bits[i]))
> continue;
> drm_printf(p, "%s%s", first ? "" : ",",
> -bits[i-from]);
> +bits[i]);
> first = false;
> }
> if (first)
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] backlight: pwm_bl: drop use of int_pow()
The scheduler uses a (currently private) fixed_power_int() in its load
average computation for computing powers of numbers 0 < x < 1
expressed as fixed-point numbers, which is also what we want here. But
that requires the scale to be a power-of-2.
We could (and a following patch will) change to use a power-of-2 scale,
but for a fixed small exponent of 3, there's no advantage in using
repeated squaring.
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 9252d51f31b9..aee6839e024a 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -179,7 +179,8 @@ static u64 cie1931(unsigned int lightness, unsigned int
scale)
if (lightness <= (8 * scale)) {
retval = DIV_ROUND_CLOSEST(lightness * 10, 9033);
} else {
- retval = int_pow((lightness + (16 * scale)) / 116, 3);
+ retval = (lightness + (16 * scale)) / 116;
+ retval *= retval * retval;
retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
}
--
2.20.1
[PATCH 2/5] backlight: pwm_bl: eliminate a 64/32 division
lightness*1000 is nowhere near overflowing 32 bits, so we can just use
an ordinary 32/32 division, which is much cheaper than the 64/32 done
via do_div().
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index be36be1cacb7..9252d51f31b9 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -177,7 +177,7 @@ static u64 cie1931(unsigned int lightness, unsigned int
scale)
*/
lightness *= 100;
if (lightness <= (8 * scale)) {
- retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9033);
+ retval = DIV_ROUND_CLOSEST(lightness * 10, 9033);
} else {
retval = int_pow((lightness + (16 * scale)) / 116, 3);
retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
--
2.20.1
[PATCH 1/5] backlight: pwm_bl: fix cie1913 comments and constant
The "break-even" point for the two formulas is L==8, which is also
what the code actually implements. [Incidentally, at that point one
has Y=0.008856, not 0.08856].
Moreover, all the sources I can find say the linear factor is 903.3
rather than 902.3, which makes sense since then the formulas agree at
L==8, both yielding the 0.008856 figure to four significant digits.
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 2201b8c78641..be36be1cacb7 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -155,8 +155,8 @@ static const struct backlight_ops pwm_backlight_ops = {
*
* The CIE 1931 lightness formula is what actually describes how we perceive
* light:
- * Y = (L* / 902.3) if L* ≤ 0.08856
- * Y = ((L* + 16) / 116)^3if L* > 0.08856
+ * Y = (L* / 903.3) if L* ≤ 8
+ * Y = ((L* + 16) / 116)^3if L* > 8
*
* Where Y is the luminance, the amount of light coming out of the screen, and
* is a number between 0.0 and 1.0; and L* is the lightness, how bright a human
@@ -169,9 +169,15 @@ static u64 cie1931(unsigned int lightness, unsigned int
scale)
{
u64 retval;
+ /*
+* @lightness is given as a number between 0 and 1, expressed
+* as a fixed-point number in scale @scale. Convert to a
+* percentage, still expressed as a fixed-point number, so the
+* above formulas can be applied.
+*/
lightness *= 100;
if (lightness <= (8 * scale)) {
- retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9023);
+ retval = DIV_ROUND_CLOSEST_ULL(lightness * 10, 9033);
} else {
retval = int_pow((lightness + (16 * scale)) / 116, 3);
retval = DIV_ROUND_CLOSEST_ULL(retval, (scale * scale));
--
2.20.1
Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
Hi All,
Thanks for your suggestions.
> Hi Liviu,
>
> On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > I totally agree. Framebuffers aren't about the underlying memory they
> > > point to, but about how to _interpret_ that memory: it decorates a
> > > pointer with width, height, stride, format, etc, to allow you to make
> > > sense of that memory. I see content protection as being the same as
> > > physical contiguity, which is a property of the underlying memory
> > > itself. Regardless of the width, height, or format, you just cannot
> > > access that memory unless it's under the appropriate ('secure enough')
> > > conditions.
> > >
> > > So I think a dmabuf attribute would be most appropriate, since that's
> > > where you have to do all your MMU handling, and everything else you
> > > need to do to allow access to that buffer, anyway.
> >
> > Isn't it how AMD currently implements protected buffers as well?
>
> No idea to be honest, I haven't seen anything upstream.
>
> > > There's a lot of complexity beyond just 'it's protected'; for
> > > instance, some CP providers mandate that their content can only be
> > > streamed over HDCP 2.2 Type-1 when going through an external
> > > connection. One way you could do that is to use a secure world
> > > (external controller like Intel's ME, or CPU-internal enclave like SGX
> > > or TEE) to examine the display pipe configuration, and only then allow
> > > access to the buffers and/or keys. Stuff like that is always going to
> > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > it should be possible to agree on at least the basic mechanics and
> > > expectations of a secure path without things like that.
> >
> > I also expect that going through the secure world will be pretty much
> > transparent for
> > the kernel driver, as the most likely hardware implementations would enable
> > additional signaling that will get trapped and handled by the secure OS.
> > I'm not
> > trying to simplify things, just taking the stance that it is userspace that
> > is
> > coordinating all this, we're trying only to find a common ground on how to
> > handle
> > this in the kernel.
>
> Yeah, makes sense.
>
> As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> the 'protected' flag on the resulting dmabuf?
To be honest, during our internal discussion james.qian.w...@arm.com had a
similar suggestion of adding a new flag to dma_buf but I decided
against it.
As per my understanding, adding custom dma buf flags (like
AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. We
rely on the dumb allocator and ion allocator for framebuffer creation.
I was looking at an allocator independent way of userspace
communicating to the drm framework that the framebuffer is protected.
Thus, it looked to me that framebuffer modifier is the best (or the least
corrupt) way of going forth.
We use ion and dumb allocator for framebuffer object creation. The way
I see it is as follows :-
1. For ion allocator :-
Userspace can specify that it wants the buffer from a secure heap or any other
special region of heap. The ion driver will either fault into the secure os to
create the buffers or it will do some other magic. Honestly, I have still not
figured that out. But it will be agnostic to the drm core.
The userspace gets a handle to the buffer and then it calls addFB2 with
DRM_FORMAT_MOD_ARM_PROTECTED, so that the driver can configure the
dpu's protection bits (to access the memory with special signals).
2. For dumb allocator :-
I am curious to know if we can add 'IS_PROTECTED' flag to
drm_mode_create_dumb.flags. This can/might be used to set dma_buf
flags. Let me know if this is an incorrect/forbidden path.
In a nutshell, my objective is to figure out if the userspace is able
to communicate to the drm core about the 'protection' status of the
buffer without introducing Arm specific buffer allocator.
Thanks,
Ayan
> Cheers,
> Daniel
Re: [PATCH v2] drm/ioctl: Add a ioctl to label GEM objects
Hi
Am 19.09.19 um 14:53 schrieb Rohan Garg:
> DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
>
> Changes in v2:
> - Hoist the IOCTL up into the drm_driver framework
>
> Signed-off-by: Rohan Garg
> ---
> drivers/gpu/drm/drm_gem.c | 64 ++
> drivers/gpu/drm/drm_internal.h | 4 +++
> drivers/gpu/drm/drm_ioctl.c| 1 +
> include/drm/drm_drv.h | 18 ++
> include/drm/drm_gem.h | 7
> include/uapi/drm/drm.h | 20 +++
> 6 files changed, 114 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6854f5867d51..785ac561619a 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -941,6 +941,65 @@ drm_gem_release(struct drm_device *dev, struct drm_file
> *file_private)
> idr_destroy(_private->object_idr);
> }
>
> +int drm_bo_set_label_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file_priv)
> +{
> + struct drm_label_object *args = data;
> +
> + if (!args->len || !args->name)
> + return -EINVAL;
> +
> + if (dev->driver->label)
> + return dev->driver->label(dev, args, file_priv);
> +
> + return -EOPNOTSUPP;
> +}
> +
> +/**
> + * drm_gem_label - label a given GEM object
> + * @dev: drm_device for the associated GEM object
> + * @data: drm_label_bo struct with a label, label length and any relevant
> flags
> + * @file_private: drm file-private structure to clean up
> + */
> +
> +int drm_gem_set_label(struct drm_device *dev, struct drm_label_object *args,
> struct drm_file *file_priv)
I'd like to set labels for internal GEM objects. Could you split off the
object update code into something that is easily callable from within
drivers? Something like
// called by ioctl
int drm_gem_object_adopt_label(struct drm_gem_object *gem,
char *label)
{
// your object update code goes here
}
// called by drivers
int drm_gem_object_set_label(struct drm_gem_object *gem,
const char *label)
{
char* new_label = strdup(label)
return drm_gem_object_adopt_label(gem, new_label);
}
We have debugfs support for TTM-based GEM objects at [1]. I think the
label would be a welcome addition to the output.
Best regards
Thomas
[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_gem_ttm_helper.c#n23
> +{
> + struct drm_gem_object *gem_obj;
> + int err = 0;
> + char *label;
> +
> + if (args->len > 0)
> + label = strndup_user(u64_to_user_ptr(args->name), args->len);
> +
> + gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> + if (!gem_obj) {
> + DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
> + err = -ENOENT;
> + goto err;
> + }
> +
> + if ((args->len == 0 && args->name == NULL) || gem_obj->label) {
> + kfree(gem_obj->label);
> + gem_obj->label = NULL;
> + }
> +
> + gem_obj->label = label;
> +
> + drm_gem_object_put_unlocked(gem_obj);
> +
> + if (IS_ERR(gem_obj->label)) {
> + err = PTR_ERR(gem_obj->label);
> + goto err;
> + }
> +
> +err:
> + if (err != 0)
> + args->flags = err;
> +
> + return err;
> +}
> +
> +
> /**
> * drm_gem_object_release - release GEM buffer object resources
> * @obj: GEM buffer object
> @@ -958,6 +1017,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
>
> dma_resv_fini(>_resv);
> drm_gem_free_mmap_offset(obj);
> +
> + if (obj->label) {
> + kfree(obj->label);
> + obj->label = NULL;
> + }
> }
> EXPORT_SYMBOL(drm_gem_object_release);
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51a2055c8f18..8259622f9ab6 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -137,6 +137,10 @@ int drm_gem_pin(struct drm_gem_object *obj);
> void drm_gem_unpin(struct drm_gem_object *obj);
> void *drm_gem_vmap(struct drm_gem_object *obj);
> void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int drm_bo_set_label_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> +int drm_gem_set_label(struct drm_device *dev, struct drm_label_object *args,
> + struct drm_file *file_priv);
>
> /* drm_debugfs.c drm_debugfs_crc.c */
> #if defined(CONFIG_DEBUG_FS)
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f675a3bb2c88..079d1422f9c5 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -709,6 +709,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
> DRM_MASTER),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE,
