Re: [PATCH] fbtft: add tearing signal detect
On Sun, Jan 24, 2021 at 11:35:37PM +0800, Carlis wrote:
> +static irqreturn_t spi_panel_te_handler(int irq, void *data)
> +{
> + complete(_panel_te);
> + return IRQ_HANDLED;
> +}
> +
> +static void enable_spi_panel_te_irq(struct fbtft_par *par, bool enable)
It quite confused me that enable actually disables. I always feel like
it's clearer to write these as two separate functions.
> +{
> + static int te_irq_count;
> +
> + if (!par->gpio.te) {
This is always checked in the caller. And it's when it's NULL that
means it's deliberate so don't print a message.
> + pr_err("%s:%d,SPI panel TE GPIO not configured\n",
> +__func__, __LINE__);
> + return;
> + }
> +
> + mutex_lock(_mutex);
> +
> + if (enable) {
> + if (++te_irq_count == 1)
> + enable_irq(gpiod_to_irq(par->gpio.te));
> + } else {
> + if (--te_irq_count == 0)
> + disable_irq(gpiod_to_irq(par->gpio.te));
> + }
> + mutex_unlock(_mutex);
> +}
> +
> /**
> * init_display() - initialize the display controller
> *
> @@ -82,6 +117,28 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (par->gpio.te) {
devm_gpiod_get_index_optional() can return NULL or error pointers. If
it returns NULL then don't print an error message. NULL reports are
deliberate.
par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
if (IS_ERR(par->gpio.te)) {
pr_err("%s:%d, TE gpio not specified\n", __func__, __LINE__);
return PTR_ERR(par->gpio.te);
}
if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> + spi_panel_te_handler, IRQF_TRIGGER_RISING,
> + "TE_GPIO", par);
> + if (rc) {
> + pr_err("TE request_irq failed.\n");
> + par->gpio.te = NULL;
> + } else {
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + pr_err("TE request_irq completion.\n");
Why is this printing an error message if devm_request_irq() succeeds?
> + }
> + } else {
> + pr_err("%s:%d, TE gpio not specified\n",
> +__func__, __LINE__);
> + }
> /* turn off sleep mode */
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> mdelay(120);
> @@ -137,6 +194,9 @@ static int init_display(struct fbtft_par *par)
>*/
> write_reg(par, PWCTRL1, 0xA4, 0xA1);
>
> +/*Tearing Effect Line On*/
> + if (par->gpio.te)
> + write_reg(par, 0x35, 0x00);
> write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
>
> if (HSD20_IPS)
> @@ -145,6 +205,76 @@ static int init_display(struct fbtft_par *par)
> return 0;
> }
>
> +/*
> + *
> + * int (*write_vmem)(struct fbtft_par *par);
> + *
> +
> */
> +
> +/* 16 bit pixel over 8-bit databus */
> +int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t
> len)
> +{
> + u16 *vmem16;
> + __be16 *txbuf16 = par->txbuf.buf;
> + size_t remain;
> + size_t to_copy;
> + size_t tx_array_size;
> + int i;
> + int rc, ret = 0;
Delete one of these "rc" or "rec" variables.
> + size_t startbyte_size = 0;
> +
> + fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
> len=%zu)\n",
> + __func__, offset, len);
> +
> + remain = len / 2;
> + vmem16 = (u16 *)(par->info->screen_buffer + offset);
> +
> + if (par->gpio.dc)
> + gpiod_set_value(par->gpio.dc, 1);
> +
> + /* non buffered write */
> + if (!par->txbuf.buf)
> + return par->fbtftops.write(par, vmem16, len);
> +
> + /* buffered write */
> + tx_array_size = par->txbuf.len / 2;
> +
> + if (par->startbyte) {
> + txbuf16 = par->txbuf.buf + 1;
> + tx_array_size -= 2;
> + *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
> + startbyte_size = 1;
> + }
> +
> + while (remain) {
> + to_copy = min(tx_array_size, remain);
> + dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
> + to_copy, remain - to_copy);
> +
> + for (i = 0; i < to_copy; i++)
> + txbuf16[i] = cpu_to_be16(vmem16[i]);
> +
> + vmem16 = vmem16 + to_copy;
> + if (par->gpio.te) {
> +
Re: [PATCH] drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources()
On Mon, Jan 25, 2021 at 07:13:43PM +, Zack Rusin wrote:
>
>
> > On Jan 25, 2021, at 03:45, Dan Carpenter wrote:
> >
> > The devm_memremap() function never returns NULL, it returns error
> > pointers so the test needs to be fixed. Also we need to call
> > pci_release_regions() to avoid a memory leak.
> >
> > Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling")
> > Signed-off-by: Dan Carpenter
>
> Thanks, Dan.
>
> I have a patch based on your report that fixes that too but it comes with a
> refactoring. I’d be happy to rebase it on top of yours just to get yours in
> before. If you’d like I can push your patch through drm-misc-next, if not:
No no. Sorry, just apply your patch and drop mine. The problem is that
the report I sent was from kbuild and I do my devel work on a different
system so it's harder to track those emails and I forgot.
Looking at it now, the bug report I sent earlier was only for the
pci_release_regions() and not the NULL vs error pointer. The kbuild
bot is not using full cross function analysis so it can't find those
bugs. My dev system does much slower builds so it's a tradeoff.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()
On 2021.01.25 09:44:53 +, Chris Wilson wrote:
> Quoting Dan Carpenter (2021-01-25 08:48:30)
> > Smatch found an uninitialized variable bug in this code:
> >
> > drivers/gpu/drm/i915/gvt/cmd_parser.c:3191
> > intel_gvt_update_reg_whitelist()
> > error: uninitialized symbol 'ret'.
> >
> > The first thing that Smatch complains about is that "ret" isn't set if
> > we don't enter the "for_each_engine(engine, _priv->gt, id) {" loop.
> > Presumably we always have at least one engine so that's a false
> > positive.
> >
> > But it's definitely a bug to not set "ret" if i915_gem_object_pin_map()
> > fails.
>
> True.
>
> > Let's fix the bug and silence the false positive.
> >
> > Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd
> > accessible reg whitelist")
> > Signed-off-by: Dan Carpenter
> Reviewed-by: Chris Wilson
Thanks, Dan & Chris! Queued this up.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #44 from MajorGonzo (majorgo...@juno.com) --- Here's another thing I tried which also may have made a difference. Gonna sound weird, but worth a try. I had a 675VA UPS that my system was plugged into. One time, it started shrieking (weird beepish sounds) as I was doing heavy gaming with lots of visual effects going on. I looked it up, and it seems that if your UPS, or your power strip, can't deliver enough power, it can cause the issues with these GPU cards. I mentioned Dec 10th as the date I made the change for my boot parameters, but it's also the date I plugged my system directly into the wall. Responding yesterday reminded me I have a new, more powerful UPS and I plugged my system into that today. I'll see if it changes anything. P.S. I know the argument...power is power...but it's not. If the surge protector, or UPS has cheap, thin wiring, then that restricts the amount of amps that can flow though them. -- You may reply to this email to add a comment. 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 v5 00/21] Host1x/TegraDRM UAPI
On 1/20/21 12:29 AM, Dmitry Osipenko wrote:
11.01.2021 15:59, Mikko Perttunen пишет:
Hi all,
here's the fifth revision of the Host1x/TegraDRM UAPI proposal,
containing primarily small bug fixes. It has also been
rebased on top of recent linux-next.
vaapi-tegra-driver has been updated to support the new UAPI
as well as Tegra186:
https://github.com/cyndis/vaapi-tegra-driver
The `putsurface` program has been tested to work.
The test suite for the new UAPI is available at
https://github.com/cyndis/uapi-test
The series can be also found in
https://github.com/cyndis/linux/commits/work/host1x-uapi-v5.
Older versions:
v1: https://www.spinics.net/lists/linux-tegra/msg51000.html
v2: https://www.spinics.net/lists/linux-tegra/msg53061.html
v3: https://www.spinics.net/lists/linux-tegra/msg54370.html
v4: https://www.spinics.net/lists/dri-devel/msg279897.html
Thank you,
Mikko
The basic support for the v5 UAPI is added now to the Opentegra driver.
In overall UAPI works, but there are couple things that we need to
improve, I'll focus on them here.
Problems
1. The channel map/unmap API needs some more thought.
The main problem is a difficulty to track liveness of BOs and mappings.
The kernel driver refs BO for each mapping and userspace needs to track
both BO and its mappings together, it's too easy to make mistake and
leak BOs without noticing.
2. Host1x sync point UAPI should not be used for tracking DRM jobs. I
remember we discussed this previously, but this pops up again and I
don't remember where we ended previously.
This creates unnecessary complexity for userspace. Userspace needs to
go through a lot of chores just to get a sync point and then to manage
it for the jobs.
Nothing stops two different channels to reuse a single sync point and
use it for a job, fixing this will only add more complexity to the
kernel driver instead of removing it.
3. The signalling of DMA fences doesn't work properly in v5 apparently
because of the host1x waiter bug. I see that sync point interrupt
happens, but waiter callback isn't invoked.
4. The sync_file API is not very suitable for DRM purposes because of
-EMFILE "Too many open files", which I saw while was running x11perf.
It also adds complexity to userspace, instead of removing it. This
approach not suitable for DRM scheduler as well.
5. Sync points have a dirty hardware state when allocated / requested.
The special sync point reservation is meaningless in this case.
6. I found that the need to chop cmdstream into gathers is a bit
cumbersome for userspace of older SoCs which don't have h/w firewall.
Can we support option where all commands are collected into a single
dedicated cmdstream for a job?
Possible solutions for the above problems
=
1. Stop to use concept of "channels". Switch to DRM context-only.
Each DRM context should get access to all engines once DRM context is
created. Think of it like "when DRM context is opened, it opens a
channel for each engine".
Then each DRM context will get one instance of mapping per-engine for
each BO.
enum tegra_engine {
TEGRA_GR2D,
TEGRA_GR3D,
TEGRA_VIC,
...
NUM_ENGINES
};
struct tegra_bo_mapping {
dma_addr_t ioaddr;
...
};
struct tegra_bo {
...
struct tegra_bo_mapping *hw_maps[NUM_ENGINES];
};
Instead of DRM_IOCTL_TEGRA_CHANNEL_MAP we should have
DRM_IOCTL_TEGRA_GEM_MAP_TO_ENGINE, which will create a BO mapping for a
specified h/w engine.
Once BO is closed, all its mappings should be closed too. This way
userspace doesn't need to track both BOs and mappings.
Everything that userspace needs to do is:
1) Open DRM context
2) Create GEM
3) Map GEM to required hardware engines
4) Submit job that uses GEM handle
5) Close GEM
If GEM wasn't mapped prior to the job's submission, then job will fail
because kernel driver won't resolve the IO mapping of the GEM.
Perhaps we can instead change the reference counting such that if you
close the GEM object, the mappings will be dropped as well automatically.
2. We will probably need a dedicated drm_tegra_submit_cmd for sync point
increments. The job's sync point will be allocated dynamically when job
is submitted. We will need a fag for the sync_incr and wait_syncpt
commands, saying "it's a job's sync point increment/wait"
Negative. Like I have explained in previous discussions, with the
current way the usage of hardware resources is much more deterministic
and obvious. I disagree on the point that this is much more complicated
for the userspace. Separating syncpoint and channel allocation is one of
the primary motivations of this series for me.
3. We should use dma-fence API directly and waiter-shim should be
removed. It's great that you're already working on this.
4. Sync file shouldn't be needed for the part of DRM API which doesn't
interact with external non-DRM devices. We
[PATCH v11 4/4] drm/panfrost: Add mt8183-mali compatible string
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
Reviewed-by: Steven Price
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conflicts, reflow the code.
- Use ARRAY_SIZE for power domains too.
Changes in v5:
- Change power domain name from 2d to core2.
Changes in v4:
- Add power domain names.
Changes in v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
Changes in v2: None
drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
.vendor_quirk = panfrost_gpu_amlogic_quirk,
};
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2"
};
+static const struct panfrost_compatible mediatek_mt8183_data = {
+ .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+ .supply_names = mediatek_mt8183_supplies,
+ .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+ .pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
static const struct of_device_id dt_match[] = {
/* Set first to probe before the generic compatibles */
{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = _data, },
{ .compatible = "arm,mali-t880", .data = _data, },
{ .compatible = "arm,mali-bifrost", .data = _data, },
+ { .compatible = "mediatek,mt8183-mali", .data = _mt8183_data },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.30.0.280.ga3ce27912f-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
does not support multiple regulators, so we'll need custom
handlers.
2. Generally, platforms with 2 regulators have platform-specific
constraints on how the voltages should be set (e.g.
minimum/maximum voltage difference between them), so we
should not just create generic handlers that simply
change the voltages without taking care of those constraints.
Disable devfreq for now on those GPUs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
Reviewed-by: Steven Price
---
Changes in v11: None
Changes in v10: None
Changes in v9:
- Explain why devfreq needs to be disabled for GPUs with >1
regulators.
Changes in v8:
- Use DRM_DEV_INFO instead of ERROR
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- devfreq: New change
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 7c5ffc81dce1..a544ae1e560a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -93,6 +93,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
+ if (pfdev->comp->num_supplies > 1) {
+ /*
+* GPUs with more than 1 supply require platform-specific
handling:
+* continue without devfreq
+*/
+ DRM_DEV_INFO(dev, "More than 1 supply is not supported yet\n");
+ return 0;
+ }
+
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {
--
2.30.0.280.ga3ce27912f-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat --- Changes in v11: - binding: power-domain-names not power-domainS-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: - Rebased, actually tested with recent mesa driver. Changes in v5: - Rename "2d" power domain to "core2" Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) Changes in v3: None Changes in v2: None .../bindings/gpu/arm,mali-bifrost.yaml| 28 +++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 184492162e7e..3e758f88e2cd 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -41,6 +42,8 @@ properties: mali-supply: true + sram-supply: true + operating-points-v2: true power-domains: @@ -87,6 +90,31 @@ allOf: then: required: - resets + - if: + properties: +compatible: + contains: +const: mediatek,mt8183-mali +then: + properties: +power-domains: + description: +List of phandle and PM domain specifier as documented in +Documentation/devicetree/bindings/power/power_domain.txt + minItems: 3 + maxItems: 3 +power-domain-names: + items: +- const: core0 +- const: core1 +- const: core2 + required: +- sram-supply +- power-domains +- power-domain-names +else: + properties: +sram-supply: false examples: - | -- 2.30.0.280.ga3ce27912f-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 0/4] drm/panfrost: Add support for mt8183 GPU
Hi! Follow-up on the v5 [1], things have gotten significantly better in the last 9 months, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 28 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 6 files changed, 162 insertions(+) -- 2.30.0.280.ga3ce27912f-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 5/5] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.
Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 30 +++-
drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
4 files changed, 187 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c6367035970e..70dc1a79a3f0 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1615,23 +1616,38 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
}
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and
uses a
+ * fixed time delay from the vbios…
+ */
static void
nv50_sor_disable(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(nv_encoder, state);
+ int ret;
nv_encoder->crtc = NULL;
if (nv_crtc) {
struct drm_dp_aux *aux = _connector->aux;
+ struct nouveau_backlight *backlight = nv_connector->backlight;
u8 pwr;
+ if (backlight && backlight->uses_dpcd) {
+ ret = drm_edp_backlight_disable(aux,
>edp_info);
+ if (ret < 0)
+ NV_ERROR(drm, "Failed to disable backlight on
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id,
nv_connector->base.name, ret);
+ }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
- int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
+ ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
@@ -1667,6 +1683,9 @@ nv50_sor_enable(struct drm_encoder *encoder, struct
drm_atomic_state *state)
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = >vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1741,6 +1760,14 @@ nv50_sor_enable(struct drm_encoder *encoder, struct
drm_atomic_state *state)
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
nv50_audio_enable(encoder, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ backlight = nv_connector->backlight;
+ if (backlight && backlight->uses_dpcd)
+ drm_edp_backlight_enable(_connector->aux,
>edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2263,6 +2290,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 42b498e7e2bf..a11811b5e63e 100644
---
[RFC v2 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.
The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.
Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):
* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/drm_dp_helper.c | 332 ++
.../drm/i915/display/intel_display_types.h| 3 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 288 ++-
include/drm/drm_dp_helper.h | 48 +++
4 files changed, 413 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..04cb2b6970a8 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3082,3 +3082,335 @@ int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux
*aux, u8 color_spc)
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the
panel's backlight must
+ * already have been enabled by the driver by calling
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+ u16 level)
+{
+ int ret;
+ u8 buf[2] = { 0 };
+
+ if (bl->lsb_reg_used) {
+ buf[0] = (level & 0xFF00) >> 8;
+ buf[1] = (level & 0x00FF);
+ } else {
+ buf[0] = level;
+ }
+
+ ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
sizeof(buf));
+ if (ret != sizeof(buf)) {
+ DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
drm_edp_backlight_info *bl,
+bool enable)
+{
+ int ret;
+ u8 buf;
+
+ /* The panel uses something other then DPCD for enabling it's backlight
*/
+ if (!bl->aux_enable)
+ return 0;
+
+ ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, );
+ if (ret != 1) {
+ DRM_ERROR("%s: Failed to read eDP display control register:
%d\n", aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+ if (enable)
+ buf |= DP_EDP_BACKLIGHT_ENABLE;
+ else
+ buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+ if (ret != 1) {
+ DRM_ERROR("%s: Failed to write eDP display control register:
%d\n", aux->name, ret);
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over
DPCD, while additionally
+ * restoring any important backlight state such as the given backlight level,
the brightness byte
+ * count, backlight frequency, etc.
+ *
+ * Note that certain panels, while supporting brightness level controls over
DPCD, may not support
+ * having their backlights enabled via the standard
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
+ * _edp_backlight_info.aux_enable will
[RFC v2 3/5] drm/i915/dp: Remove redundant AUX backlight frequency calculations
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_dp_aux_backlight.c | 65 ++-
2 files changed, 20 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 927a8aeae324..8450ab8fb245 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -264,6 +264,7 @@ struct intel_panel {
union {
struct {
u8 pwmgen_bit_count;
+ u8 pwm_freq_pre_divider;
} vesa;
struct {
bool sdr_uses_aux;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..62294967f430 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -373,50 +373,6 @@ intel_dp_aux_vesa_set_backlight(const struct
drm_connector_state *conn_state,
}
}
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
-{
- struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct intel_dp *intel_dp = intel_attached_dp(connector);
- const u8 pn = connector->panel.backlight.edp.vesa.pwmgen_bit_count;
- int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
- freq = dev_priv->vbt.backlight.pwm_freq_hz;
- if (!freq) {
- drm_dbg_kms(_priv->drm,
- "Use panel default backlight frequency\n");
- return false;
- }
-
- fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
-
- /* Ensure frequency is within 25% of desired value */
- fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
- fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
- if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
- drm_dbg_kms(_priv->drm, "Actual frequency out of range\n");
- return false;
- }
-
- if (drm_dp_dpcd_writeb(_dp->aux,
- DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
- drm_dbg_kms(_priv->drm,
- "Failed to write aux backlight freq\n");
- return false;
- }
- return true;
-}
-
static void
intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state, u32 level)
@@ -459,9 +415,13 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
break;
}
- if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
- if (intel_dp_aux_vesa_set_pwm_freq(connector))
+ if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET,
+
panel->backlight.edp.vesa.pwm_freq_pre_divider) == 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+ else
+ drm_dbg_kms(>drm, "Failed to write aux backlight
frequency\n");
+ }
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
@@ -482,6 +442,14 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
false);
}
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P =
[RFC v2 1/5] drm/nouveau/kms/nv40-/backlight: Assign prop type once
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 72f35a2babcb..42b498e7e2bf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -106,7 +106,6 @@ nv40_backlight_init(struct nouveau_encoder *encoder,
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return -ENODEV;
- props->type = BACKLIGHT_RAW;
props->max_brightness = 31;
*ops = _bl_ops;
return 0;
@@ -212,7 +211,6 @@ nv50_backlight_init(struct nouveau_encoder *nv_encoder,
else
*ops = _bl_ops;
- props->type = BACKLIGHT_RAW;
props->max_brightness = 100;
return 0;
@@ -226,7 +224,7 @@ nouveau_backlight_init(struct drm_connector *connector)
struct nouveau_encoder *nv_encoder = NULL;
struct nvif_device *device = >client.device;
char backlight_name[BL_NAME_SIZE];
- struct backlight_properties props = {0};
+ struct backlight_properties props = { .type = BACKLIGHT_RAW, 0 };
const struct backlight_ops *ops;
int ret;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 2/5] drm/nouveau/kms: Don't probe eDP connectors more then once
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a connection status change is being forced, of course). Signed-off-by: Lyude Paul Cc: Jani Nikula Cc: Dave Airlie Cc: greg.depo...@gmail.com --- drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 14c29e68db8f..f4d16576a7da 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -556,6 +556,12 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) int ret; enum drm_connector_status conn_status = connector_status_disconnected; + /* eDP doesn't do hotplugging, never probe more then once */ + if (nv_connector->type == DCB_CONNECTOR_eDP && + connector->force == DRM_FORCE_UNSPECIFIED && + connector->status != connector_status_unknown) + return connector->status; + /* Outputs are only polled while runtime active, so resuming the * device here is unnecessary (and would deadlock upon runtime suspend * because it waits for polling to finish). We do however, want to -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 0/5] drm: Extract DPCD backlight helpers from i915, add support in nouveau
This series: * Cleans up i915's DPCD backlight code a little bit * Extracts i915's DPCD backlight code into a set of shared DRM helpers * Starts using those helpers in nouveau to add support to nouveau for DPCD backlight control v2 series-wide changes: * Rebase Cc: Jani Nikula Cc: Dave Airlie Cc: greg.depo...@gmail.com Lyude Paul (5): drm/nouveau/kms/nv40-/backlight: Assign prop type once drm/nouveau/kms: Don't probe eDP connectors more then once drm/i915/dp: Remove redundant AUX backlight frequency calculations drm/dp: Extract i915's eDP backlight code into DRM helpers drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau drivers/gpu/drm/drm_dp_helper.c | 332 ++ .../drm/i915/display/intel_display_types.h| 2 +- .../drm/i915/display/intel_dp_aux_backlight.c | 315 ++--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 30 +- drivers/gpu/drm/nouveau/nouveau_backlight.c | 170 +++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 6 + drivers/gpu/drm/nouveau/nouveau_connector.h | 9 +- drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 + include/drm/drm_dp_helper.h | 48 +++ 9 files changed, 607 insertions(+), 306 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Fri, 2020-12-11 at 17:01 +0200, Jani Nikula wrote:
> On Wed, 09 Dec 2020, Lyude Paul wrote:
> > Since we're about to implement eDP backlight support in nouveau using the
> > standard protocol from VESA, we might as well just take the code that's
> > already written for this and move it into a set of shared DRM helpers.
> >
> > Note that these helpers are intended to handle DPCD related backlight
> > control bits such as setting the brightness level over AUX, probing the
> > backlight's TCON, enabling/disabling the backlight over AUX if supported,
> > etc. Any PWM-related portions of backlight control are explicitly left up
> > to the driver, as these will vary from platform to platform.
> >
> > The only exception to this is the calculation of the PWM frequency
> > pre-divider value. This is because the only platform-specific information
> > required for this is the PWM frequency of the panel, which the driver is
> > expected to provide if available. The actual algorithm for calculating this
> > value is standard and is defined in the eDP specification from VESA.
> >
> > Note that these helpers do not yet implement the full range of features
> > the VESA backlight interface provides, and only provide the following
> > functionality (all of which was already present in i915's DPCD backlight
> > support):
> >
> > * Basic control of brightness levels
> > * Basic probing of backlight capabilities
> > * Helpers for enabling and disabling the backlight
>
> Overall I like where this is going. Again, not a full review yet, just a
> few notes below.
>
> >
> > Signed-off-by: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Dave Airlie
> > Cc: greg.depo...@gmail.com
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 332 ++
> > .../drm/i915/display/intel_display_types.h | 5 +-
> > .../drm/i915/display/intel_dp_aux_backlight.c | 304 ++--
> > include/drm/drm_dp_helper.h | 48 +++
> > 4 files changed, 419 insertions(+), 270 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 5bd0934004e3..06fdddf44e54 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -2596,3 +2596,335 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> > device *dev,
> > #undef DP_SDP_LOG
> > }
> > EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> > +
> > +/**
> > + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> > via AUX
> > + * @aux: The DP AUX channel to use
> > + * @bl: Backlight capability info from drm_edp_backlight_init()
> > + * @level: The brightness level to set
> > + *
> > + * Sets the brightness level of an eDP panel's backlight. Note that the
> > panel's backlight must
> > + * already have been enabled by the driver by calling
> > drm_edp_backlight_enable().
> > + *
> > + * Returns: %0 on success, negative error code on failure
> > + */
> > +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + u16 level)
>
> I think I'd go for s/backlight/brightness/g function naming thoughout,
> to account for OLED. "Backlight" unnecessarily underlines the
> technology.
Hm, are we sure about this part? It makes sense in some places, but:
* The eDP spec refers to these as backlights
* "Brightness capability info" makes a bit less sense then backlight capability
info
* In general, it seems like we'd have a weird mix of "brightness" and
"backlight" in the docs in order for things to make sense
I'm fine with either though, although my vote is on backlight. In the mean time
I'm going to send a respin that's refactored + the one small change you
suggested in patch 3.
>
> > +{
> > + int ret;
> > + u8 buf[2] = { 0 };
> > +
> > + if (bl->lsb_reg_used) {
> > + buf[0] = (level & 0xFF00) >> 8;
> > + buf[1] = (level & 0x00FF);
> > + } else {
> > + buf[0] = level;
> > + }
> > +
> > + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> > sizeof(buf));
> > + if (ret != sizeof(buf)) {
> > + DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> > aux->name, ret);
>
> I'd really like to have a way to get from struct drm_dp_aux to struct
> drm_device to retain the device specific logging here. It'd be useful in
> the lower level dpcd access functions too.
I'll put this on my todo list and try to get to this in the near future, I've
been thinking the same thing myself for a while now.
>
> > + return ret < 0 ? ret : -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> > +
> > +static int
> > +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> > drm_edp_backlight_info *bl,
> > + bool enable)
> > +{
> > + int ret;
> > + u8 buf;
> > +
> > + /*
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #43 from Randune (randyk...@gmail.com) --- (In reply to Panagiotis Polychronis from comment #41) > (In reply to j.cordoba from comment #40) > > (In reply to Randune from comment #39) > > > There doesn't appear to be any progress on this bug, does anyone have any > > > suggestions with regards on how to fix this issue? > > > > Try to add iommu=pt as parameter > > I'm running Linux Kernel 5.10.9 with those kernel parameters > "amdgpu.ppfeaturemask=0xbffb amdgpu.noretry=0 amdgpu.lockup_timeout=0 > amdgpu.gpu_recovery=1 amdgpu.audio=0 amdgpu.deep_color=1 amd_iommu=on > iommu=pt" My graphics card is Radeon 5600XT and i can confirm that this > issue still exist :) > Meanwhile i looked at > https://lists.freedesktop.org/archives/amd-gfx/2021-January/date.html and > there are some patches about ring timeout which i think they aren't yet > merged for the next Linux Kernel release. Probably Alex Deucher will merge > them later. Thanks for the suggestion Panagliotis Polychronis, I've tried that in the past and it didn't seem to help. I'm running Manjaro currently and I'm on the Linux 5.11.rc3 kernel as supposedly there are many changes regarding AMDGPU (I'm not sure if there are many changes for my RX580) but it's worth a shot, I'm basically shooting in the dark at this point :). -- You may reply to this email to add a comment. 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 2/2] dt-bindings: display: Document BOE BF060Y8M-AJ0 panel compatible
On Thu, 14 Jan 2021 18:50:24 +0100, AngeloGioacchino Del Regno wrote: > Document the boe,bf060y8m-aj0 panel. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../display/panel/boe,bf060y8m-aj0.yaml | 67 +++ > 1 file changed, 67 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Mon, Jan 25, 2021 at 6:29 PM Oliver Graute wrote: > Ok I fixed the pin conflict with regulator-gpio and added a 5V > regulator node in my dts file. Now the display is working fine! That's good news :-) > I'll post the dts files soon and check if there is something to > improve for this patch. Did the panel patch I sent earlier work? https://pastebin.com/raw/diTMVsh8 If it does, I can send it formally if you want. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge binding
On Thu, Jan 14, 2021 at 05:22:09PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
> * Side note i.MX8qxp LDB official name 'pixel mapper'. (Laurent)
>
> .../bindings/display/bridge/fsl,imx8qxp-ldb.yaml | 176
> +
> 1 file changed, 176 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
> b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
> new file mode 100644
> index ..514ac90
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
> @@ -0,0 +1,176 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qm/qxp LVDS Display Bridge
> +
> +maintainers:
> + - Liu Ying
> +
> +description: |
> + The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels.
> +
> + For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color
> + format and can map the input to VESA or JEIDA standards. The two channels
> + cannot be used simultaneously, that is to say, the user should pick one of
> + them to use. Two LDB channels from two LDB instances can work together in
> + LDB split mode to support a dual link LVDS display. The channel indexes
> + have to be different. Channel0 outputs odd pixels and channel1 outputs
> + even pixels.
> +
> + For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel
> + input color format. The two channels can be used simultaneously, either
> + in dual mode or split mode. In dual mode, the two channels output
> identical
> + data. In split mode, channel0 outputs odd pixels and channel1 outputs even
> + pixels.
> +
> + A side note is that i.MX8qm/qxp LDB is officially called pixel mapper in
> + the SoC reference manuals. The pixel mapper uses logic of LDBs embedded in
> + i.MX6qdl/sx SoCs, i.e., it is essentially based on them. To keep the
> naming
> + consistency, this binding calls it LDB.
> +
> +properties:
> + compatible:
> +enum:
> + - fsl,imx8qm-ldb
> + - fsl,imx8qxp-ldb
> +
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + clocks:
> +items:
> + - description: pixel clock
> + - description: bypass clock
> +
> + clock-names:
> +items:
> + - const: pixel
> + - const: bypass
> +
> + power-domains:
> +maxItems: 1
> +
> + fsl,syscon:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: |
> + A phandle which points to Control and Status Registers(CSR) module.
Again, seems like this binding should be a child of the syscon.
> +
> + fsl,companion-ldb:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: |
> + A phandle which points to companion LDB which is used in LDB split
> mode.
> +
> +patternProperties:
> + "^channel@[0-1]$":
> +type: object
> +description: Represents a channel of LDB.
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + reg:
> +description: The channel index.
> +enum: [ 0, 1 ]
> +
> + phys:
> +description: A phandle to the phy module representing the LVDS PHY.
> +maxItems: 1
> +
> + phy-names:
> +const: lvds_phy
> +
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Input port of the channel.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Output port of the channel.
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - reg
> + - phys
> + - phy-names
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - "#address-cells"
> + - "#size-cells"
> + - clocks
> + - clock-names
> + - power-domains
> + - fsl,syscon
> + - channel@0
> + - channel@1
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: fsl,imx8qm-ldb
> +then:
> + properties:
> +fsl,companion-ldb: false
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +ldb {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "fsl,imx8qxp-ldb";
> +clocks = < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
> + < IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
> +clock-names = "pixel", "bypass";
> +power-domains = < IMX_SC_R_LVDS_0>;
> +fsl,syscon = <_lvds_0_csr>;
> +
> +channel@0 {
> +
Re: [PATCH v2 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
On Thu, Jan 14, 2021 at 05:22:06PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
>
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use graph schema. (Laurent)
>
> .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 105
> +
> 1 file changed, 105 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> new file mode 100644
> index ..187824e
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
> +
> +maintainers:
> + - Liu Ying
> +
> +description: |
> + The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
> + interfaces the pixel link 36-bit data output and the DSI controller’s
> + MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
> + used in LVDS mode, to remap the pixel color codings between those modules.
> + This module is purely combinatorial.
> +
> +properties:
> + compatible:
> +const: fsl,imx8qxp-pxl2dpi
> +
> + power-domains:
> +maxItems: 1
> +
> + fsl,syscon:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: |
> + A phandle which points to Control and Status Registers(CSR) module.
If this is the only control interface, then make it a child node of the
phandle.
> +
> + fsl,companion-pxl2dpi:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: |
> + A phandle which points to companion PXL2DPI which is used by downstream
> + LVDS Display Bridge(LDB) in split mode.
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: The PXL2DPI input port node from pixel link.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: The PXL2DPI output port node to downstream bridge.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - power-domains
> + - fsl,syscon
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +pxl2dpi {
> +compatible = "fsl,imx8qxp-pxl2dpi";
> +power-domains = < IMX_SC_R_MIPI_0>;
> +fsl,syscon = <_lvds_0_csr>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <0>;
> +
> +mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <_pixel_link0_mipi_lvds_0_pxl2dpi>;
> +};
> +
> +mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_pixel_link1_mipi_lvds_0_pxl2dpi>;
> +};
> +};
> +
> +port@1 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <1>;
> +
> +mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
> +reg = <0>;
> +remote-endpoint =
> <_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
> +};
> +
> +mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
> +reg = <1>;
> +remote-endpoint =
> <_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
> +};
> +};
> +};
> +};
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding
On Thu, 14 Jan 2021 17:22:04 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qm/qxp display pixel link. > > Signed-off-by: Liu Ying > --- > v1->v2: > * Use graph schema. (Laurent) > * Require all four pixel link output ports. (Laurent) > * Mention pixel link is accessed via SCU firmware. (Rob) > > .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106 > + > 1 file changed, 106 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
On Thu, 14 Jan 2021 17:22:02 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qm/qxp pixel combiner. > > Signed-off-by: Liu Ying > --- > v1->v2: > * Use graph schema. (Laurent) > * Use enum instead of oneOf + const for the reg property of pixel combiner > channels. (Rob) > > .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 > + > 1 file changed, 144 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4] dt-bindings: gpu: Convert v3d to json-schema
On Wed, 13 Jan 2021 20:08:37 +0100, Stefan Wahren wrote: > This converts the v3d bindings to yaml format. > > Signed-off-by: Stefan Wahren > --- > > Changes in V4: > - define order for required reg-names > - adapt example > > Changes in V3: > - drop redundant maxItems in case we already have items defined > - fix order of reg-names enum > - tag required items in description > - add reg-names to required properties > - drop clock-names > > .../devicetree/bindings/gpu/brcm,bcm-v3d.txt | 33 -- > .../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 75 > ++ > 2 files changed, 75 insertions(+), 33 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt > create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml > Applied, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Mon, Jan 25, 2021 at 5:05 PM Simon Ser wrote: > ‐‐‐ Original Message ‐‐‐ > > On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner < > mario.kleiner...@gmail.com> wrote: > > > On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote: > > > > > > This is not an uapi defintion anyway so fixing should be fine. > > > > > > Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah > > > > > > should be completely fine to fix it. > > > > Good! The beginning of the end of a sad story ;). So i guess i can > > get your r-b's for it? > > Sorry, I haven't verified that this wouldn't break the world, so I'm > not comfortable giving a R-b. > > Breaking the world is pretty unlikely for an unused #define, but I understand. I guess Ville will have access to the relevant spec to verify: It is the CTA-861-G spec, table 44 in section 6.9 and also specifically section 6.9.1. > > Will this fix propagate into igt and libdrm? Or are separate fixup > patches needed? > > No, since this is not part of UAPI. > Ok. I'll submit patches once this one landed in the kernel. > > > Simon, could you let the Kodi devs know in case you have a line to > > them? I didn't know that there is even one more real-world HDR client > > for Linux, apart from AMD's amdvlk Vulkan driver, which does things > > right and doesn't need fixing. > > Seems like Kodi hardcodes the bad version: > > > https://github.com/xbmc/xbmc/blob/aa5c2e79c069ba7d0ab1d8ad930e4294bf554680/xbmc/cores/VideoPlayer/Buffers/VideoBufferDRMPRIME.h#L24 > > Thanks. I've filed an issue to them under: https://github.com/xbmc/xbmc/issues/19122 > Maybe we should add the good version in UAPI header? > I'm scared that future HDR definitions would be as carefully done and reviewed as this one, given how much harder it would be to fix them :/ But maybe that's just exhausted me who spent too many weeks dealing with HDR bugs everywhere. -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v7 0/6] Add user space dma-buf support
This is the seventh version of the patch series. Change log: v7: * Rebase to the latest rdma-core master (commit a4885eda9addc4) * Rerun kernel-headers/update against linux-rdma for-next so that the kernel commit id in the commit message is correct v6: https://www.spinics.net/lists/linux-rdma/msg99221.html * Rebase to the latest rdma-core master (commit 14006f2f841b0c) * Update the ABI symbol version to match new package version; also bump the private ABI version because new function has been added to the provider interface * Avoid changing 'struct ibv_context_ops' by replacing SET_OP() with SET_PRIV_OP_IC() * Replace sprintf() with snprintf() * Keep the ops in verbs_set_ops() sorted * Fix some styling issues: extra spaces, struct 0-initialization, error checking control flow v5: https://www.spinics.net/lists/linux-rdma/msg99015.html * Use a different mr_type for dmabuf so that ibv_dofork_range() is not called inside ibv_dereg_mr() for dmabuf based mr v4: https://www.spinics.net/lists/linux-rdma/msg98135.html * Rework the cmake funciton rdma_cython_module to support both single source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead of using two separate functions * Rename 'dri_*' to 'drm_*' for the dmabuf allocation interface * Add option to dmabuf allocation routine to allow allocation from GTT instead of VRAM * Add proper CPU access flags when allocating dmabufs * Remove 'radeon' driver support from the dmabuf allocation routines * Add comand line arguments to the tests for selecting GPU unit and setting the option for allocating from GTT v3: https://www.spinics.net/lists/linux-rdma/msg98059.html * Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API * Change the way of allocating dma-buf object - use /dev/dri/renderD* instead of /dev/dri/card* and use GEM object instead of dumb buffer * Add cmake function to allow building modules with mixed cython and C source files * Add new tests that use dma-buf MRs for send/recv and rdma traffic * Skip dma-buf tests on unsupported systems * Remove some use of random values in the new tests * Add dealloc() and close() methods to the new classes * Replace string.format with f-string in python code * Fix some coding style issues: spacing, indentation, typo, comments v2: https://www.spinics.net/lists/linux-rdma/msg97936.html * Put the kernel header updates into a separate commit * Add comments for the data structure used in python ioctl calls * Fix issues related to symbol versioning * Fix styling issues: extra spaces, unncecessary variable, typo * Fix an inproper error code usage * Put the new op into ibv_context_ops instead if verbs_context v1: https://www.spinics.net/lists/linux-rdma/msg97865.html * Add user space API for registering dma-buf based memory regions * Update pyverbs with the new API * Add new tests This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This series consists of six patches. The first patch updates the kernel headers for dma-buf support. Patch 2 adds the new API function and updates the man pages. Patch 3 implements the new API in the mlx5 provider. Patch 4 adds new class definitions to pyverbs for the new API. Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in the utility code of the tests. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895 Jianxin Xiong (6): Update kernel headers verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() buildlib/pyverbs_functions.cmake | 78 ++--- debian/libibverbs1.symbols | 2 + kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++ libibverbs/CMakeLists.txt| 2 +- libibverbs/cmd_mr.c | 38 + libibverbs/driver.h | 8 + libibverbs/dummy_ops.c | 11 ++ libibverbs/libibverbs.map.in | 6 + libibverbs/man/ibv_reg_mr.3 | 27 ++- libibverbs/verbs.c | 19 +++ libibverbs/verbs.h | 7 + providers/mlx5/mlx5.c| 2 + providers/mlx5/mlx5.h| 3 + providers/mlx5/verbs.c | 22 +++ pyverbs/CMakeLists.txt | 11 +- pyverbs/dmabuf.pxd | 15 ++ pyverbs/dmabuf.pyx | 73 pyverbs/dmabuf_alloc.c | 278 +++ pyverbs/dmabuf_alloc.h | 19 +++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 6 + pyverbs/mr.pyx | 105 +++- tests/args_parser.py | 4 + tests/test_mr.py | 266 - tests/utils.py
[PATCH rdma-core v7 5/6] tests: Add tests for dma-buf based memory regions
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py | 4 +
tests/test_mr.py | 266 ++-
tests/utils.py | 26 +
3 files changed, 295 insertions(+), 1 deletion(-)
diff --git a/tests/args_parser.py b/tests/args_parser.py
index 446535a..5bc53b0 100644
--- a/tests/args_parser.py
+++ b/tests/args_parser.py
@@ -19,6 +19,10 @@ class ArgsParser(object):
parser.add_argument('--port',
help='Use port of RDMA device', type=int,
default=1)
+parser.add_argument('--gpu', nargs='?', type=int, const=0, default=0,
+help='GPU unit to allocate dmabuf from')
+parser.add_argument('--gtt', action='store_true', default=False,
+help='Allocate dmabuf from GTT instead of VRAM')
parser.add_argument('-v', '--verbose', dest='verbosity',
action='store_const',
const=2, help='Verbose output')
diff --git a/tests/test_mr.py b/tests/test_mr.py
index b88ad23..03a645f 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019 Mellanox Technologies, Inc. All rights reserved. See
COPYING file
+# Copyright (c) 2020 Intel Corporation. All rights reserved. See COPYING file
"""
Test module for pyverbs' mr module.
"""
@@ -9,15 +10,18 @@ import errno
from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.mem_alloc import posix_memalign, free
from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
import pyverbs.device as d
from pyverbs.pd import PD
import pyverbs.enums as e
import tests.utils as u
+MAX_IO_LEN = 1048576
+
class MRRes(RCResources):
def __init__(self, dev_name, ib_port, gid_index,
@@ -423,3 +427,263 @@ class DMMRTest(PyverbsAPITestCase):
dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
dm=dm, offset=dm_mr_offset)
dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.ENOENT:
+raise unittest.SkipTest(f'Device /dev/dri/renderD{device_num} is
not present')
+if ex.error_code == errno.EACCES:
+raise unittest.SkipTest(f'Lack of permission to access
/dev/dri/renderD{device_num}')
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest(f'Allocating dmabuf is not supported by
/dev/dri/renderD{device_num}')
+
+
+def check_dmabuf_mr_support(pd, unit=0):
+"""
+Check if dma-buf MR registration is supported by the driver.
+Skip the test on failure
+"""
+try:
+DmaBufMR(pd, 1, 0, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest('Reg dma-buf MR is not supported by the
RDMA driver')
+
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def setUp(self):
+super().setUp()
+self.unit = self.config['gpu']
+self.gtt = self.config['gtt']
+
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+ gtt=self.gtt) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+
[PATCH rdma-core v7 3/6] mlx5: Support dma-buf based memory region
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index a2a1696..b3c49af 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -95,6 +96,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+ .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr = mlx5_rereg_mr,
.dereg_mr = mlx5_dereg_mr,
.alloc_mw = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index bafe077..decc7f8 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -941,6 +942,8 @@ void mlx5_async_event(struct ibv_context *context,
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int access);
int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void
*addr,
size_t length, int access);
int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index 30c7b6e..7790b50 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -628,6 +629,27 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr,
size_t length,
return >vmr.ibv_mr;
}
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int acc)
+{
+ struct mlx5_mr *mr;
+ int ret;
+
+ mr = calloc(1, sizeof(*mr));
+ if (!mr)
+ return NULL;
+
+ ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, acc,
+ >vmr);
+ if (ret) {
+ free(mr);
+ return NULL;
+ }
+ mr->alloc_flags = acc;
+
+ return >vmr.ibv_mr;
+}
+
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
{
struct mlx5_mr *mr;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v7 4/6] pyverbs: Add dma-buf based MR support
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by: Jianxin Xiong
---
buildlib/pyverbs_functions.cmake | 78 +++
pyverbs/CMakeLists.txt | 11 +-
pyverbs/dmabuf.pxd | 15 +++
pyverbs/dmabuf.pyx | 73 ++
pyverbs/dmabuf_alloc.c | 278 +++
pyverbs/dmabuf_alloc.h | 19 +++
pyverbs/libibverbs.pxd | 2 +
pyverbs/mr.pxd | 6 +
pyverbs/mr.pyx | 105 ++-
9 files changed, 557 insertions(+), 30 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
create mode 100644 pyverbs/dmabuf_alloc.c
create mode 100644 pyverbs/dmabuf_alloc.h
diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index 953cec2..0792410 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -1,35 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2018, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved. See COPYING file
+
+function(build_module_from_cfiles PY_MODULE MODULE_NAME ALL_CFILES
LINKER_FLAGS)
+ string(REGEX REPLACE "\\.so$" "" SONAME
"${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
+ add_library(${SONAME} SHARED ${ALL_CFILES})
+ set_target_properties(${SONAME} PROPERTIES
+COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
+LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
+PREFIX "")
+ target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
+ install(TARGETS ${SONAME}
+DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+endfunction()
function(rdma_cython_module PY_MODULE LINKER_FLAGS)
- foreach(PYX_FILE ${ARGN})
-get_filename_component(FILENAME ${PYX_FILE} NAME_WE)
-get_filename_component(DIR ${PYX_FILE} DIRECTORY)
- if (DIR)
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}/${FILENAME}.pyx")
- else()
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}.pyx")
- endif()
-set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
-include_directories(${PYTHON_INCLUDE_DIRS})
-add_custom_command(
- OUTPUT "${CFILE}"
- MAIN_DEPENDENCY "${PYX}"
- COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
- "-I${PYTHON_INCLUDE_DIRS}"
- COMMENT "Cythonizing ${PYX}"
+ set(ALL_CFILES "")
+ set(MODULE_NAME "")
+ foreach(SRC_FILE ${ARGN})
+get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
+get_filename_component(DIR ${SRC_FILE} DIRECTORY)
+get_filename_component(EXT ${SRC_FILE} EXT)
+if (DIR)
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
+else()
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+endif()
+if (${EXT} STREQUAL ".pyx")
+ # each .pyx file starts a new module, finish the previous module first
+ if (ALL_CFILES AND MODULE_NAME)
+build_module_from_cfiles(${PY_MODULE} ${MODULE_NAME} "${ALL_CFILES}"
"${LINKER_FLAGS}")
+ endif()
+ set(PYX "${SRC_PATH}/${FILENAME}.pyx")
+ set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+ include_directories(${PYTHON_INCLUDE_DIRS})
+ add_custom_command(
+OUTPUT "${CFILE}"
+MAIN_DEPENDENCY "${PYX}"
+COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
+"-I${PYTHON_INCLUDE_DIRS}"
+COMMENT "Cythonizing ${PYX}"
)
-
-string(REGEX REPLACE "\\.so$" "" SONAME
"${FILENAME}${CMAKE_PYTHON_SO_SUFFIX}")
-add_library(${SONAME} SHARED ${CFILE})
-set_target_properties(${SONAME} PROPERTIES
- COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
- LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
- PREFIX "")
-target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
-install(TARGETS ${SONAME}
- DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+ set(MODULE_NAME ${FILENAME})
+ set(ALL_CFILES "${CFILE}")
+elseif(${EXT} STREQUAL ".c")
+ # .c files belong to the same module as the most recent .pyx file,
+ # ignored if appearing before all .pyx files
+ set(CFILE
[PATCH rdma-core v7 1/6] Update kernel headers
To commit bfe0cc6eb249 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
};
enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
};
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+ UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
};
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v7 6/6] tests: Bug fix for get_access_flags()
The filter definition is wrong and causes get_access_flags() always returning empty list. As the result the MR tests using this function are effectively skipped (but report success). Signed-off-by: Jianxin Xiong --- tests/utils.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/utils.py b/tests/utils.py index 8546329..c41cb3b 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -58,8 +58,8 @@ def filter_illegal_access_flags(element): :param element: A list of access flags to check :return: True if this list is legal, else False """ -if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE: -if e.IBV_ACCESS_LOCAL_WRITE: +if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in element: +if not e.IBV_ACCESS_LOCAL_WRITE in element: return False return True -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v7 2/6] verbs: Support dma-buf based memory region
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 ++
libibverbs/driver.h | 8
libibverbs/dummy_ops.c | 11 +++
libibverbs/libibverbs.map.in | 6 ++
libibverbs/man/ibv_reg_mr.3 | 27 +--
libibverbs/verbs.c | 19 +++
libibverbs/verbs.h | 7 +++
9 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/debian/libibverbs1.symbols b/debian/libibverbs1.symbols
index 7f59d0a..6cf5c2f 100644
--- a/debian/libibverbs1.symbols
+++ b/debian/libibverbs1.symbols
@@ -9,6 +9,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
IBVERBS_1.9@IBVERBS_1.9 30
IBVERBS_1.10@IBVERBS_1.10 31
IBVERBS_1.11@IBVERBS_1.11 32
+ IBVERBS_1.12@IBVERBS_1.12 34
(symver)IBVERBS_PRIVATE_34 34
_ibv_query_gid_ex@IBVERBS_1.11 32
_ibv_query_gid_table@IBVERBS_1.11 32
@@ -99,6 +100,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
ibv_rate_to_mbps@IBVERBS_1.1 1.1.8
ibv_rate_to_mult@IBVERBS_1.0 1.1.6
ibv_read_sysfs_file@IBVERBS_1.0 1.1.6
+ ibv_reg_dmabuf_mr@IBVERBS_1.12 34
ibv_reg_mr@IBVERBS_1.0 1.1.6
ibv_reg_mr@IBVERBS_1.1 1.1.6
ibv_reg_mr_iova@IBVERBS_1.7 25
diff --git a/libibverbs/CMakeLists.txt b/libibverbs/CMakeLists.txt
index 0fe4256..d075225 100644
--- a/libibverbs/CMakeLists.txt
+++ b/libibverbs/CMakeLists.txt
@@ -21,7 +21,7 @@ configure_file("libibverbs.map.in"
rdma_library(ibverbs "${CMAKE_CURRENT_BINARY_DIR}/libibverbs.map"
# See Documentation/versioning.md
- 1 1.11.${PACKAGE_VERSION}
+ 1 1.12.${PACKAGE_VERSION}
all_providers.c
cmd.c
cmd_ah.c
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..af0fad7 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mellanox Technologies, Ltd. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr
*vmr,
return 0;
}
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+ DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
+ 9);
+ struct ib_uverbs_attr *handle;
+ uint32_t lkey, rkey;
+ int ret;
+
+ handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, );
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, );
+
+ fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
access);
+
+ ret = execute_ioctl(pd->context, cmdb);
+ if (ret)
+ return errno;
+
+ vmr->ibv_mr.handle = read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ handle);
+ vmr->ibv_mr.context = pd->context;
+ vmr->ibv_mr.lkey = lkey;
+ vmr->ibv_mr.rkey = rkey;
+ vmr->ibv_mr.pd = pd;
+ vmr->ibv_mr.addr = (void *)offset;
+ vmr->ibv_mr.length = length;
+ vmr->mr_type = IBV_MR_TYPE_DMABUF_MR;
+ return 0;
+}
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index 9bbd3b4..3965fa3 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -2,6 +2,7 @@
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005, 2006 Cisco Systems, Inc. All rights reserved.
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -91,6 +92,7 @@ enum ibv_mr_type {
IBV_MR_TYPE_MR,
IBV_MR_TYPE_NULL_MR,
IBV_MR_TYPE_IMPORTED_MR,
+ IBV_MR_TYPE_DMABUF_MR,
};
struct verbs_mr {
@@ -375,6 +377,9 @@ struct verbs_context_ops {
struct ibv_mr *(*reg_dm_mr)(struct ibv_pd *pd, struct ibv_dm *dm,
uint64_t dm_offset, size_t length,
unsigned int access);
+
Re: [PATCH 22/24] dt-bindings: memory: mediatek: update mediatek, smi-larb.yaml references
On Wed, 13 Jan 2021 11:59:23 +0100, Mauro Carvalho Chehab wrote:
> Changeset 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT
> schema")
> renamed:
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> to:
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml.
>
> Update its cross-references accordingly.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
> .../devicetree/bindings/media/mediatek-jpeg-decoder.txt | 2 +-
> .../devicetree/bindings/media/mediatek-jpeg-encoder.txt | 2 +-
> Documentation/devicetree/bindings/media/mediatek-mdp.txt| 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/24] dt-bindings: display: mediatek: update mediatek, dpi.yaml reference
On Wed, 13 Jan 2021 11:59:22 +0100, Mauro Carvalho Chehab wrote:
> Changeset 9273cf7d3942 ("dt-bindings: display: mediatek: convert the dpi
> bindings to yaml")
> renamed: Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> to: Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml.
>
> Update its cross-reference accordingly.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/24] ASoC: audio-graph-card: update audio-graph-card.yaml reference
On Wed, 13 Jan 2021 11:59:21 +0100, Mauro Carvalho Chehab wrote:
> Changeset 97198614f6c3 ("ASoC: audio-graph-card: switch to yaml base
> Documentation")
> renamed: Documentation/devicetree/bindings/sound/audio-graph-card.txt
> to: Documentation/devicetree/bindings/sound/audio-graph-card.yaml.
>
> Update its cross-reference accordingly.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Wed, 13 Jan 2021 14:07:00 +0800, Nicolas Boichat wrote: > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > --- > > Changes in v10: > - Fix the binding to make sure sram-supply property can be provided. > > Changes in v6: > - Rebased, actually tested with recent mesa driver. > - No change > > Changes in v5: > - Rename "2d" power domain to "core2" > > Changes in v4: > - Add power-domain-names description >(kept Alyssa's reviewed-by as the change is minor) > > Changes in v3: > - No change > > .../bindings/gpu/arm,mali-bifrost.yaml| 28 +++ > 1 file changed, 28 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amd/display: Fix HDMI deep color output for DCE 6-11.
Thanks Alex and Nicholas! Brings quite a bit of extra shiny to those older
asics :)
Nicholas, any thoughts on my cover-letter wrt. why a similar patch (that I
wrote and tested to no good or bad effect) not seem to be needed on DCN,
and probably not DCE-11.2+ either? Is what is left in DC for those asic's
just dead code? My Atombios disassembly sort of pointed into that
direction, but reading disassembly is not easy on the brain, and my brain
was getting quite mushy towards the end of digging through all the code. So
some official statement would add peace of mind on my side. Is there a
certain DCE version at which your team starts validating output precision /
HDR etc. on hw?
Thanks,
-mario
On Mon, Jan 25, 2021 at 8:16 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:
> On 2021-01-25 12:57 p.m., Alex Deucher wrote:
> > On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner
> > wrote:
> >>
> >> This fixes corrupted display output in HDMI deep color
> >> 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
> >>
> >> It will hopefully also provide fixes for other DCE's up to
> >> DCE-11, assuming those will need similar fixes, but i could
> >> not test that for HDMI due to lack of suitable hw, so viewer
> >> discretion is advised.
> >>
> >> dce110_stream_encoder_hdmi_set_stream_attribute() is used for
> >> HDMI setup on all DCE's and is missing color_depth assignment.
> >>
> >> dce110_program_pix_clk() is used for pixel clock setup on HDMI
> >> for DCE 6-11, and is missing color_depth assignment.
> >>
> >> Additionally some of the underlying Atombios specific encoder
> >> and pixelclock setup functions are missing code which is in
> >> the classic amdgpu kms modesetting path and the in the radeon
> >> kms driver for DCE6/DCE8.
> >>
> >> encoder_control_digx_v3() - Was missing setup code wrt. amdgpu
> >> and radeon kms classic drivers. Added here, but untested due to
> >> lack of suitable test hw.
> >>
> >> encoder_control_digx_v4() - Added missing setup code.
> >> Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color
> >> output at 10 bpc and 12 bpc.
> >>
> >> Note that encoder_control_digx_v5() has proper setup code in place
> >> and is used, e.g., by DCE-11.2, but this code wasn't used for deep
> >> color setup due to the missing cntl.color_depth setup in the calling
> >> function for HDMI.
> >>
> >> set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon
> >> kms. Added here, but untested due to lack of hw.
> >>
> >> set_pixel_clock_v6() - Missing setup code added. Successfully tested
> >> on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
> >> deep color output with 10 bpc or 12 bpc.
> >>
> >> Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> >>
> >> Signed-off-by: Mario Kleiner
> >> Cc: Harry Wentland
> >
> > These make sense. I've applied the series. I'll let the display guys
> > gauge the other points in your cover letter.
> >
> > Alex
>
> I don't have any concerns with this patch.
>
> Even though it's already applied feel free to have my:
>
> Reviewed-by: Nicholas Kazlauskas
>
> Regards,
> Nicholas Kazlauskas
>
> >
> >
> >> ---
> >> .../drm/amd/display/dc/bios/command_table.c | 61 +++
> >> .../drm/amd/display/dc/dce/dce_clock_source.c | 14 +
> >> .../amd/display/dc/dce/dce_stream_encoder.c | 1 +
> >> 3 files changed, 76 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> >> index 070459e3e407..afc10b954ffa 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> >> @@ -245,6 +245,23 @@ static enum bp_result encoder_control_digx_v3(
> >> cntl->enable_dp_audio);
> >> params.ucLaneNum = (uint8_t)(cntl->lanes_number);
> >>
> >> + switch (cntl->color_depth) {
> >> + case COLOR_DEPTH_888:
> >> + params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
> >> + break;
> >> + case COLOR_DEPTH_101010:
> >> + params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
> >> + break;
> >> + case COLOR_DEPTH_121212:
> >> + params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
> >> + break;
> >> + case COLOR_DEPTH_161616:
> >> + params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
> >> + break;
> >> + default:
> >> + break;
> >> + }
> >> +
> >> if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
> >> result = BP_RESULT_OK;
> >>
> >> @@ -274,6 +291,23 @@ static enum bp_result encoder_control_digx_v4(
> >> cntl->enable_dp_audio));
> >> params.ucLaneNum = (uint8_t)(cntl->lanes_number);
> >>
> >> + switch (cntl->color_depth) {
> >> + case COLOR_DEPTH_888:
> >> +
Re: [PATCH 1/2] drm/dp/mst: Export drm_dp_get_vc_payload_bw()
On Mon, 2021-01-25 at 19:36 +0200, Imre Deak wrote:
> This function will be needed by the next patch where the driver
> calculates the BW based on driver specific parameters, so export it.
>
> At the same time sanitize the function params, passing the more natural
> link rate instead of the encoding of the same rate.
>
> Cc: Lyude Paul
> Cc: Ville Syrjala
> Cc:
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++--
> include/drm/drm_dp_mst_helper.h | 1 +
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 475939138b21..dc96cbf78cc6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3629,14 +3629,26 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> return 0;
> }
>
> -static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> +/**
> + * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
> + * @rate: link rate in 10kbits/s units
> + * @lane_count: lane count
> + *
> + * Calculate the toal bandwidth of a MultiStream Transport link. The returned
s/toal/total/
With that fixed, this patch is:
Reviewed-by: Lyude Paul
> + * value is in units of PBNs/(timeslots/1 MTP). This value can be used to
> + * convert the number of PBNs required for a given stream to the number of
> + * timeslots this stream requires in each MTP.
> + */
> +int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
> {
> - if (dp_link_bw == 0 || dp_link_count == 0)
> - DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count:
> %d)\n",
> - dp_link_bw, dp_link_count);
> + if (link_rate == 0 || link_lane_count == 0)
> + DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
> + link_rate, link_lane_count);
>
> - return dp_link_bw * dp_link_count / 2;
> + /* See DP v2.0 2.6.4.2,
> VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> + return link_rate * link_lane_count / 54000;
> }
> +EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
>
> /**
> * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> @@ -3692,7 +3704,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> goto out_unlock;
> }
>
> - mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
> + mgr->pbn_div =
> drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
> mgr->dpcd[2] &
> DP_MAX_LANE_COUNT_MASK);
> if (mgr->pbn_div == 0) {
> ret = -EINVAL;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index f5e92fe9151c..bd1c39907b92 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -783,6 +783,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
>
> struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
> drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
>
> +int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
>
> int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amd/display: Fix HDMI deep color output for DCE 6-11.
On 2021-01-25 12:57 p.m., Alex Deucher wrote:
On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner
wrote:
This fixes corrupted display output in HDMI deep color
10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
It will hopefully also provide fixes for other DCE's up to
DCE-11, assuming those will need similar fixes, but i could
not test that for HDMI due to lack of suitable hw, so viewer
discretion is advised.
dce110_stream_encoder_hdmi_set_stream_attribute() is used for
HDMI setup on all DCE's and is missing color_depth assignment.
dce110_program_pix_clk() is used for pixel clock setup on HDMI
for DCE 6-11, and is missing color_depth assignment.
Additionally some of the underlying Atombios specific encoder
and pixelclock setup functions are missing code which is in
the classic amdgpu kms modesetting path and the in the radeon
kms driver for DCE6/DCE8.
encoder_control_digx_v3() - Was missing setup code wrt. amdgpu
and radeon kms classic drivers. Added here, but untested due to
lack of suitable test hw.
encoder_control_digx_v4() - Added missing setup code.
Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color
output at 10 bpc and 12 bpc.
Note that encoder_control_digx_v5() has proper setup code in place
and is used, e.g., by DCE-11.2, but this code wasn't used for deep
color setup due to the missing cntl.color_depth setup in the calling
function for HDMI.
set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon
kms. Added here, but untested due to lack of hw.
set_pixel_clock_v6() - Missing setup code added. Successfully tested
on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
deep color output with 10 bpc or 12 bpc.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
These make sense. I've applied the series. I'll let the display guys
gauge the other points in your cover letter.
Alex
I don't have any concerns with this patch.
Even though it's already applied feel free to have my:
Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
---
.../drm/amd/display/dc/bios/command_table.c | 61 +++
.../drm/amd/display/dc/dce/dce_clock_source.c | 14 +
.../amd/display/dc/dce/dce_stream_encoder.c | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index 070459e3e407..afc10b954ffa 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -245,6 +245,23 @@ static enum bp_result encoder_control_digx_v3(
cntl->enable_dp_audio);
params.ucLaneNum = (uint8_t)(cntl->lanes_number);
+ switch (cntl->color_depth) {
+ case COLOR_DEPTH_888:
+ params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_101010:
+ params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_121212:
+ params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_161616:
+ params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ break;
+ default:
+ break;
+ }
+
if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
result = BP_RESULT_OK;
@@ -274,6 +291,23 @@ static enum bp_result encoder_control_digx_v4(
cntl->enable_dp_audio));
params.ucLaneNum = (uint8_t)(cntl->lanes_number);
+ switch (cntl->color_depth) {
+ case COLOR_DEPTH_888:
+ params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_101010:
+ params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_121212:
+ params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_161616:
+ params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ break;
+ default:
+ break;
+ }
+
if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
result = BP_RESULT_OK;
@@ -1057,6 +1091,19 @@ static enum bp_result set_pixel_clock_v5(
* driver choose program it itself, i.e. here we program it
* to 888 by default.
*/
+ if (bp_params->signal_type == SIGNAL_TYPE_HDMI_TYPE_A)
+ switch (bp_params->color_depth) {
+ case TRANSMITTER_COLOR_DEPTH_30:
+ /* yes this is correct, the atom define is
wrong */
+ clk.sPCLKInput.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_32BPP;
+ break;
+ case TRANSMITTER_COLOR_DEPTH_36:
+
Re: [PATCH] drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources()
> On Jan 25, 2021, at 03:45, Dan Carpenter wrote:
>
> The devm_memremap() function never returns NULL, it returns error
> pointers so the test needs to be fixed. Also we need to call
> pci_release_regions() to avoid a memory leak.
>
> Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling")
> Signed-off-by: Dan Carpenter
Thanks, Dan.
I have a patch based on your report that fixes that too but it comes with a
refactoring. I’d be happy to rebase it on top of yours just to get yours in
before. If you’d like I can push your patch through drm-misc-next, if not:
Reviewed-by: Zack Rusin
z
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.10 029/199] drm/syncobj: Fix use-after-free
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
drm_syncobj_find_fence v4")
Reviewed-by: Christian König
Cc: Christian König
Cc: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_syncobj.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -388,19 +388,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(, 0, sizeof(wait));
wait.task = current;
@@ -432,6 +431,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, );
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.4 16/86] drm/syncobj: Fix use-after-free
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
drm_syncobj_find_fence v4")
Reviewed-by: Christian König
Cc: Christian König
Cc: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_syncobj.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -326,19 +326,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(, 0, sizeof(wait));
wait.task = current;
@@ -370,6 +369,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, );
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Drop drm_simple_kms_format_mod_supported.
On Mon, Jan 25, 2021 at 5:34 PM Ville Syrjälä
wrote:
> On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> > On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > > > The check was introduced to make sure that only the
> > > > DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
> > > >
> > > > However, if .format_mod_supported is not hooked up to
> > > > drm_simple_kms_format_mod_supported then the core will
> > > > simply validate modifiers against the format_modifiers
> > > > list passed into drm_simple_display_pipe_init() or
> > > > drm_universal_plane_init() and perform the same validation
> > > > as drm_simple_kms_format_mod_supported() would have done.
> > > >
> > > > Additionally, if a kms driver / plane does not support
> > > > modifiers, it will not reject fb updates with no modifiers/
> > > > DRM_FORMAT_MOD_INVALID. This is important, because some
> > > > simple drm drivers, e.g., pl111, pass NULL as format_modifiers
> > > > list, so modifier support is disabled for these drivers,
> > > > userspace would fall back to drmAddFB() without modifiers,
> > > > and ergo the current drm_simple_kms_format_mod_supported()
> > > > function would reject valid modifier-less fb's.
> > > >
> > > > So this should fix display on non-tinydrm drivers like
> > > > pl111, and probably also for non-atomic clients?
> > > >
> > > > The Mesa vc4 gallium driver mentions pl111 as one possible
> > > > display driver in render_only mode, so i assume this matters
> > > > for some SoC's?
> > > >
> > > > The background for the patch that introduced this was to
> > > > fix atomic modesetting in the X-Servers modesetting-ddx,
> > > > but with atomic modesetting and format modifiers disabled
> > > > in modesetting-ddx (and also current kernels when interacting
> > > > with modesetting-ddx), i assume this should fix some panels.
> > > >
> > > > Note that i don't have any of the hw required for testing
> > > > this, this is purely based on looking at the code, so this
> > > > patch is only compile-tested.
> > > >
> > > > For more reference, this fix was motivated by some discussions
> > > > around broken page-flipping on VideoCore6 / RaspberryPi 4
> > > > with current Raspbian OS, so the experts may want to weigh
> > > > in on that Mesa bug report as well, under the following link:
> > > >
> > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
> > > >
> > > > Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
> > > DRM_FORMAT_MOD_LINEAR.")
> > > > Signed-off-by: Mario Kleiner
> > > > Cc: Eric Anholt
> > > > Cc: Noralf Trønnes
> > > > Cc: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/drm_simple_kms_helper.c | 8
> > > > 1 file changed, 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > index 743e57c1b44f..5f3e30553172 100644
> > > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > @@ -229,13 +229,6 @@ static void
> drm_simple_kms_plane_cleanup_fb(struct
> > > drm_plane *plane,
> > > > pipe->funcs->cleanup_fb(pipe, state);
> > > > }
> > > >
> > > > -static bool drm_simple_kms_format_mod_supported(struct drm_plane
> *plane,
> > > > - uint32_t format,
> > > > - uint64_t modifier)
> > > > -{
> > > > - return modifier == DRM_FORMAT_MOD_LINEAR;
> > > > -}
> > > > -
> > > > static const struct drm_plane_helper_funcs
> > > drm_simple_kms_plane_helper_funcs = {
> > > > .prepare_fb = drm_simple_kms_plane_prepare_fb,
> > > > .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
> > > > @@ -250,7 +243,6 @@ static const struct drm_plane_funcs
> > > drm_simple_kms_plane_funcs = {
> > > > .reset = drm_atomic_helper_plane_reset,
> > > > .atomic_duplicate_state =
> drm_atomic_helper_plane_duplicate_state,
> > > > .atomic_destroy_state =
> drm_atomic_helper_plane_destroy_state,
> > > > - .format_mod_supported = drm_simple_kms_format_mod_supported,
> > >
> > > This will now cause also this driver to report a totally borked
> > > IN_FORMATS blob.
> > >
> > > Would need this
> > > https://patchwork.freedesktop.org/series/83018/
> > >
> > >
> > The slight problem with that (see my comments in the linked Mesa bug
> > report), is that at least one common userspace driver - modesetting-ddx -
> > treat a lack of an IN_FORMATS blob not as "don't use modifiers for
> > drm_framebuffers", but as "everything goes" -- Use every modifier and
> > tiling format that the graphics driver exposes also for scanout buffers.
> > I'm arguing in that bug report that modesetting-ddx shouldn't use atomic
> or
> > modifiers at all, given how broken that driver is atm. in that area, so
> i'm
> > not sure if my argument
Re: [PATCH 2/2] drm/amd/display: Fix HDMI deep color output for DCE 6-11.
On Thu, Jan 21, 2021 at 1:17 AM Mario Kleiner
wrote:
>
> This fixes corrupted display output in HDMI deep color
> 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
>
> It will hopefully also provide fixes for other DCE's up to
> DCE-11, assuming those will need similar fixes, but i could
> not test that for HDMI due to lack of suitable hw, so viewer
> discretion is advised.
>
> dce110_stream_encoder_hdmi_set_stream_attribute() is used for
> HDMI setup on all DCE's and is missing color_depth assignment.
>
> dce110_program_pix_clk() is used for pixel clock setup on HDMI
> for DCE 6-11, and is missing color_depth assignment.
>
> Additionally some of the underlying Atombios specific encoder
> and pixelclock setup functions are missing code which is in
> the classic amdgpu kms modesetting path and the in the radeon
> kms driver for DCE6/DCE8.
>
> encoder_control_digx_v3() - Was missing setup code wrt. amdgpu
> and radeon kms classic drivers. Added here, but untested due to
> lack of suitable test hw.
>
> encoder_control_digx_v4() - Added missing setup code.
> Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color
> output at 10 bpc and 12 bpc.
>
> Note that encoder_control_digx_v5() has proper setup code in place
> and is used, e.g., by DCE-11.2, but this code wasn't used for deep
> color setup due to the missing cntl.color_depth setup in the calling
> function for HDMI.
>
> set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon
> kms. Added here, but untested due to lack of hw.
>
> set_pixel_clock_v6() - Missing setup code added. Successfully tested
> on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
> deep color output with 10 bpc or 12 bpc.
>
> Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
>
> Signed-off-by: Mario Kleiner
> Cc: Harry Wentland
These make sense. I've applied the series. I'll let the display guys
gauge the other points in your cover letter.
Alex
> ---
> .../drm/amd/display/dc/bios/command_table.c | 61 +++
> .../drm/amd/display/dc/dce/dce_clock_source.c | 14 +
> .../amd/display/dc/dce/dce_stream_encoder.c | 1 +
> 3 files changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> index 070459e3e407..afc10b954ffa 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
> @@ -245,6 +245,23 @@ static enum bp_result encoder_control_digx_v3(
> cntl->enable_dp_audio);
> params.ucLaneNum = (uint8_t)(cntl->lanes_number);
>
> + switch (cntl->color_depth) {
> + case COLOR_DEPTH_888:
> + params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_101010:
> + params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_121212:
> + params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_161616:
> + params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
> + break;
> + default:
> + break;
> + }
> +
> if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
> result = BP_RESULT_OK;
>
> @@ -274,6 +291,23 @@ static enum bp_result encoder_control_digx_v4(
> cntl->enable_dp_audio));
> params.ucLaneNum = (uint8_t)(cntl->lanes_number);
>
> + switch (cntl->color_depth) {
> + case COLOR_DEPTH_888:
> + params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_101010:
> + params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_121212:
> + params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
> + break;
> + case COLOR_DEPTH_161616:
> + params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
> + break;
> + default:
> + break;
> + }
> +
> if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
> result = BP_RESULT_OK;
>
> @@ -1057,6 +1091,19 @@ static enum bp_result set_pixel_clock_v5(
> * driver choose program it itself, i.e. here we program it
> * to 888 by default.
> */
> + if (bp_params->signal_type == SIGNAL_TYPE_HDMI_TYPE_A)
> + switch (bp_params->color_depth) {
> + case TRANSMITTER_COLOR_DEPTH_30:
> + /* yes this is correct, the atom define is
> wrong */
> + clk.sPCLKInput.ucMiscInfo |=
> PIXEL_CLOCK_V5_MISC_HDMI_32BPP;
> + break;
> + case TRANSMITTER_COLOR_DEPTH_36:
> +
[PATCH 1/2] drm/dp/mst: Export drm_dp_get_vc_payload_bw()
This function will be needed by the next patch where the driver
calculates the BW based on driver specific parameters, so export it.
At the same time sanitize the function params, passing the more natural
link rate instead of the encoding of the same rate.
Cc: Lyude Paul
Cc: Ville Syrjala
Cc:
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++--
include/drm/drm_dp_mst_helper.h | 1 +
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 475939138b21..dc96cbf78cc6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3629,14 +3629,26 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
-static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
+/**
+ * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
+ * @rate: link rate in 10kbits/s units
+ * @lane_count: lane count
+ *
+ * Calculate the toal bandwidth of a MultiStream Transport link. The returned
+ * value is in units of PBNs/(timeslots/1 MTP). This value can be used to
+ * convert the number of PBNs required for a given stream to the number of
+ * timeslots this stream requires in each MTP.
+ */
+int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
{
- if (dp_link_bw == 0 || dp_link_count == 0)
- DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count:
%d)\n",
- dp_link_bw, dp_link_count);
+ if (link_rate == 0 || link_lane_count == 0)
+ DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
+ link_rate, link_lane_count);
- return dp_link_bw * dp_link_count / 2;
+ /* See DP v2.0 2.6.4.2,
VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
+ return link_rate * link_lane_count / 54000;
}
+EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
/**
* drm_dp_read_mst_cap() - check whether or not a sink supports MST
@@ -3692,7 +3704,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
- mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
+ mgr->pbn_div =
drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
mgr->dpcd[2] &
DP_MAX_LANE_COUNT_MASK);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index f5e92fe9151c..bd1c39907b92 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -783,6 +783,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: fix NULL check before some freeing functions is not needed
Am Montag, dem 25.01.2021 um 11:27 +0800 schrieb Tian Tao: > fixed the below warning: > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check > before some freeing functions is not needed. Thanks, I've added this patch to my etnaviv/next branch. Regards, Lucas > Signed-off-by: Tian Tao > --- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > index b390dd4..d741b1d 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c > @@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct > etnaviv_gem_object *etnaviv_obj) > /* Don't drop the pages for imported dmabuf, as they are not > * ours, just free the array we allocated: > */ > - if (etnaviv_obj->pages) > - kvfree(etnaviv_obj->pages); > + kvfree(etnaviv_obj->pages); > > > > > drm_prime_gem_destroy(_obj->base, etnaviv_obj->sgt); > } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: dump: fix sparse warnings
Am Mittwoch, dem 23.12.2020 um 20:51 +0100 schrieb Marc Kleine-Budde:
> This patch fixes the following sparse warnings, by adding the missing
> endianess
> conversion functions.
>
> > etnaviv/etnaviv_dump.c:78:26: warning: restricted __le32 degrades to integer
> > etnaviv/etnaviv_dump.c:88:26: warning: incorrect type in assignment
> > (different base types)
> > etnaviv/etnaviv_dump.c:88:26:expected restricted __le32 [usertype] reg
> > etnaviv/etnaviv_dump.c:88:26:got unsigned short const
> > etnaviv/etnaviv_dump.c:89:28: warning: incorrect type in assignment
> > (different base types)
> > etnaviv/etnaviv_dump.c:89:28:expected restricted __le32 [usertype] value
> > etnaviv/etnaviv_dump.c:89:28:got unsigned int
> > etnaviv/etnaviv_dump.c:210:43: warning: incorrect type in assignment
> > (different base types)
> > etnaviv/etnaviv_dump.c:210:43:expected restricted __le32
> > etnaviv/etnaviv_dump.c:210:43:got long
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Marc Kleine-Budde
> ---
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 706af0304ca4..f418e0b75772 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -75,7 +75,7 @@ static void etnaviv_core_dump_header(struct
> core_dump_iterator *iter,
> hdr->file_size = cpu_to_le32(data_end - iter->data);
>
>
>
>
> iter->hdr++;
> - iter->data += hdr->file_size;
> + iter->data += le32_to_cpu(hdr->file_size);
> }
>
>
>
>
> static void etnaviv_core_dump_registers(struct core_dump_iterator *iter,
> @@ -85,8 +85,8 @@ static void etnaviv_core_dump_registers(struct
> core_dump_iterator *iter,
> unsigned int i;
>
>
>
>
> for (i = 0; i < ARRAY_SIZE(etnaviv_dump_registers); i++, reg++) {
> - reg->reg = etnaviv_dump_registers[i];
> - reg->value = gpu_read(gpu, etnaviv_dump_registers[i]);
> + reg->reg = cpu_to_le32(etnaviv_dump_registers[i]);
> + reg->value = cpu_to_le32(gpu_read(gpu,
> etnaviv_dump_registers[i]));
> }
>
>
>
>
> etnaviv_core_dump_header(iter, ETDUMP_BUF_REG, reg);
> @@ -207,7 +207,7 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
> if (!IS_ERR(pages)) {
> int j;
>
>
>
>
> - iter.hdr->data[0] = bomap - bomap_start;
> + iter.hdr->data[0] = cpu_to_le32((bomap - bomap_start));
>
>
>
>
> for (j = 0; j < obj->base.size >> PAGE_SHIFT; j++)
> *bomap++ = cpu_to_le64(page_to_phys(*pages++));
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: provide more ID values via GET_PARAM ioctl.
Am Mittwoch, dem 16.12.2020 um 12:42 +0100 schrieb Christian Gmeiner:
> Make it possible for the user space to access these ID values.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
> include/uapi/drm/etnaviv_drm.h| 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index c6404b8d067f..ec16991ba8b6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -156,6 +156,18 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = ~0ULL;
> break;
>
>
>
>
> + case ETNAVIV_PARAM_GPU_PRODUCT_ID:
> + *value = gpu->identity.product_id;
> + break;
> +
> + case ETNAVIV_PARAM_GPU_CUSTOMER_ID:
> + *value = gpu->identity.customer_id;
> + break;
> +
> + case ETNAVIV_PARAM_GPU_ECO_ID:
> + *value = gpu->identity.eco_id;
> + break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> index 09d0df8b71c5..af024d90453d 100644
> --- a/include/uapi/drm/etnaviv_drm.h
> +++ b/include/uapi/drm/etnaviv_drm.h
> @@ -74,6 +74,9 @@ struct drm_etnaviv_timespec {
> #define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
> #define ETNAVIV_PARAM_GPU_NUM_VARYINGS 0x1a
> #define ETNAVIV_PARAM_SOFTPIN_START_ADDR0x1b
> +#define ETNAVIV_PARAM_GPU_PRODUCT_ID0x1c
> +#define ETNAVIV_PARAM_GPU_CUSTOMER_ID 0x1d
> +#define ETNAVIV_PARAM_GPU_ECO_ID0x1e
>
>
>
>
> #define ETNA_MAX_PIPES 4
>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Drop drm_simple_kms_format_mod_supported.
On Mon, Jan 25, 2021 at 04:32:48PM +0100, Mario Kleiner wrote:
> On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
> wrote:
>
> > On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > > The check was introduced to make sure that only the
> > > DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
> > >
> > > However, if .format_mod_supported is not hooked up to
> > > drm_simple_kms_format_mod_supported then the core will
> > > simply validate modifiers against the format_modifiers
> > > list passed into drm_simple_display_pipe_init() or
> > > drm_universal_plane_init() and perform the same validation
> > > as drm_simple_kms_format_mod_supported() would have done.
> > >
> > > Additionally, if a kms driver / plane does not support
> > > modifiers, it will not reject fb updates with no modifiers/
> > > DRM_FORMAT_MOD_INVALID. This is important, because some
> > > simple drm drivers, e.g., pl111, pass NULL as format_modifiers
> > > list, so modifier support is disabled for these drivers,
> > > userspace would fall back to drmAddFB() without modifiers,
> > > and ergo the current drm_simple_kms_format_mod_supported()
> > > function would reject valid modifier-less fb's.
> > >
> > > So this should fix display on non-tinydrm drivers like
> > > pl111, and probably also for non-atomic clients?
> > >
> > > The Mesa vc4 gallium driver mentions pl111 as one possible
> > > display driver in render_only mode, so i assume this matters
> > > for some SoC's?
> > >
> > > The background for the patch that introduced this was to
> > > fix atomic modesetting in the X-Servers modesetting-ddx,
> > > but with atomic modesetting and format modifiers disabled
> > > in modesetting-ddx (and also current kernels when interacting
> > > with modesetting-ddx), i assume this should fix some panels.
> > >
> > > Note that i don't have any of the hw required for testing
> > > this, this is purely based on looking at the code, so this
> > > patch is only compile-tested.
> > >
> > > For more reference, this fix was motivated by some discussions
> > > around broken page-flipping on VideoCore6 / RaspberryPi 4
> > > with current Raspbian OS, so the experts may want to weigh
> > > in on that Mesa bug report as well, under the following link:
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
> > >
> > > Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
> > DRM_FORMAT_MOD_LINEAR.")
> > > Signed-off-by: Mario Kleiner
> > > Cc: Eric Anholt
> > > Cc: Noralf Trønnes
> > > Cc: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/drm_simple_kms_helper.c | 8
> > > 1 file changed, 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > index 743e57c1b44f..5f3e30553172 100644
> > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > @@ -229,13 +229,6 @@ static void drm_simple_kms_plane_cleanup_fb(struct
> > drm_plane *plane,
> > > pipe->funcs->cleanup_fb(pipe, state);
> > > }
> > >
> > > -static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
> > > - uint32_t format,
> > > - uint64_t modifier)
> > > -{
> > > - return modifier == DRM_FORMAT_MOD_LINEAR;
> > > -}
> > > -
> > > static const struct drm_plane_helper_funcs
> > drm_simple_kms_plane_helper_funcs = {
> > > .prepare_fb = drm_simple_kms_plane_prepare_fb,
> > > .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
> > > @@ -250,7 +243,6 @@ static const struct drm_plane_funcs
> > drm_simple_kms_plane_funcs = {
> > > .reset = drm_atomic_helper_plane_reset,
> > > .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > - .format_mod_supported = drm_simple_kms_format_mod_supported,
> >
> > This will now cause also this driver to report a totally borked
> > IN_FORMATS blob.
> >
> > Would need this
> > https://patchwork.freedesktop.org/series/83018/
> >
> >
> The slight problem with that (see my comments in the linked Mesa bug
> report), is that at least one common userspace driver - modesetting-ddx -
> treat a lack of an IN_FORMATS blob not as "don't use modifiers for
> drm_framebuffers", but as "everything goes" -- Use every modifier and
> tiling format that the graphics driver exposes also for scanout buffers.
> I'm arguing in that bug report that modesetting-ddx shouldn't use atomic or
> modifiers at all, given how broken that driver is atm. in that area, so i'm
> not sure if my argument here is valid. Just saying that doing the "every
> modifier is valid for every format" in absence of format_mod_supported()
> would probably be less harmful to some existing userspace. Ofc. then
> there's a reason why atomic gets rejected by the kernel for current
> modesetting-ddx...
>
> I'm not
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Monday, January 25th, 2021 at 5:08 PM, Mario Kleiner wrote: > In some way it would even be nice to have all that info exposed in > parsed form as a connector property or such, so all clients can use > the same parsed data instead of reinventing the wheel. So far the policy has more or less been: if the kernel doesn't need to understand it and user-space can grab it from the EDID, don't expose it as a property. Maybe a user-space library would be better to avoid reinventing the wheel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Mon, Jan 25, 2021 at 1:09 PM Ville Syrjälä wrote: > On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote: > > On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote: > > > > > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner < > > > mario.kleiner...@gmail.com> wrote: > > > > > > > But it still needs to be fixed if we want working HDR. I thought > > > > libdrm copies the definitions from the kernel periodically, so the > > > > fix should propagate? > > > > > > There will always be user-space that sends 1 instead of 0. This > > > shouldn't fail on more recent kernels or it will be a regression. > > > > > > > Yes, i know, regressing user-space is bad, but in this very specific > case a > > "good" one, if ever. At the moment, it wouldn't regress userspace simply > > because the kernel doesn't actually check for the correct value in its > HDR > > metadata handling. But the value itself is sent as HDMI HDR metadata to > the > > attached HDR display monitor, so if the monitors firmware checks, it will > > classify the wrong value of 1 as invalid and disable HDR mode on the > > display, which is certainly not what a HDR client application wants. And > > future HDR standards which will actually allocate the value 1 to a > > different mode of HDR operation will switch to the wrong mode / > > misinterpret the sent HDR metadata with hillarious results, which is also > > not in the interest of a HDR client application, or a HDR capable > > compositor. > > > > Iow. if clients continue to use the wrong value 1 then HDR display will > > break in various ways on correctly implemented HDR displays, but in a > > mystifying and hard to debug way. The kernel rejecting a wrong setting > > explicitly and forcing a bug fix in the client would be a blessing in > this > > case. > > > > I spent weeks last year, going in circles and hunting ghost bugs related > to > > HDR because much of the HDR stuff, both drivers and monitor firmware > seems > > to be in not a great shape. "Less wrong" would be a big step forward. > > Especially with the cheaper HDR monitors it is difficult to see when > things > > go wrong, because we don't have good expectations on how proper HDR > should > > look and the lower end HDR displays don't help. > > This is not an uapi defintion anyway so fixing should be fine. > I don't think we even check any of the client provided values, or do we? > EOTF I think we do check, but IMO that check should probably just be > nuked as well if we don't bother checking anything else. > > I think we check only EOTF atm. That check does make sense though, as userspace getting that wrong will definitely knock out even low-end HDR monitors. My tests with a - supposed to be pretty good according to tests - DisplayHDR-600 monitor suggest that that's pretty much the only thing the monitor actually uses, apart from CRC checking the data packet. > I was in fact going to suggest nuking this entire hdr_sink_metadata > parsing as unused, but looks like amdgpu has started to use it for > some backlight stuff of all things. > My gut feeling says we will need this info in the kernel in the future, independent of current users. Probably especially if one wants to do interesting things which combine HDR with VRR/DP-Adaptive sync, or future HDR standards (dynamic HDR metadata?), those infos in the kernel may become quite useful. In some way it would even be nice to have all that info exposed in parsed form as a connector property or such, so all clients can use the same parsed data instead of reinventing the wheel. So I'd vote against nuking it. Thanks, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
‐‐‐ Original Message ‐‐‐ On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner wrote: > On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote: > > > > This is not an uapi defintion anyway so fixing should be fine. > > > > Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah > > > > should be completely fine to fix it. > > Good! The beginning of the end of a sad story ;). So i guess i can > get your r-b's for it? Sorry, I haven't verified that this wouldn't break the world, so I'm not comfortable giving a R-b. > Will this fix propagate into igt and libdrm? Or are separate fixup patches > needed? No, since this is not part of UAPI. > Simon, could you let the Kodi devs know in case you have a line to > them? I didn't know that there is even one more real-world HDR client > for Linux, apart from AMD's amdvlk Vulkan driver, which does things > right and doesn't need fixing. Seems like Kodi hardcodes the bad version: https://github.com/xbmc/xbmc/blob/aa5c2e79c069ba7d0ab1d8ad930e4294bf554680/xbmc/cores/VideoPlayer/Buffers/VideoBufferDRMPRIME.h#L24 Maybe we should add the good version in UAPI header? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote: > > This is not an uapi defintion anyway so fixing should be fine. > > Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah > should be completely fine to fix it. > Good! The beginning of the end of a sad story ;). So i guess i can get your r-b's for it? Will this fix propagate into igt and libdrm? Or are separate fixup patches needed? Simon, could you let the Kodi devs know in case you have a line to them? I didn't know that there is even one more real-world HDR client for Linux, apart from AMD's amdvlk Vulkan driver, which does things right and doesn't need fixing. thanks mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/dp: add MSO related DPCD registers
Add DPCD register definitions for eDP 1.4 Multi-SST Operation. Cc: Nischal Varide Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index edffd1dcca3e..632ad7faa006 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1016,6 +1016,11 @@ struct drm_device; #define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ #define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */ +#define DP_EDP_MSO_LINK_CAPABILITIES0x7a4/* eDP 1.4 */ +# define DP_EDP_MSO_NUMBER_OF_LINKS_MASK(7 << 0) +# define DP_EDP_MSO_NUMBER_OF_LINKS_SHIFT 0 +# define DP_EDP_MSO_INDEPENDENT_LINK_BIT(1 << 3) + /* Sideband MSG Buffers */ #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: fix clang build warning
On Mon, Jan 25, 2021 at 7:24 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> clang warns about the -mhard-float command line arguments
> on architectures that do not support this:
>
> clang: error: argument unused during compilation: '-mhard-float'
> [-Werror,-Wunused-command-line-argument]
>
> Move this into the gcc-specific arguments.
>
> Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
> Signed-off-by: Arnd Bergmann
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 --
> drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
> drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> index c20331eb62e0..dfd77b3cc84d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
> @@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o
> dcn30_dpp.o dcn30_optc.o \
>
>
> ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
> -CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
> endif
>
> ifdef CONFIG_PPC64
> @@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
> ifeq ($(call cc-ifversion, -lt, 0701, y), y)
> IS_OLD_GCC = 1
> endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
> +CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
> endif
>
> ifdef CONFIG_X86
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> index 3ca7d911d25c..09264716d1dc 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
> @@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
> dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o
> dcn301_hubbub.o
>
> ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
> endif
>
> ifdef CONFIG_PPC64
> @@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
> ifeq ($(call cc-ifversion, -lt, 0701, y), y)
> IS_OLD_GCC = 1
> endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
> endif
>
> ifdef CONFIG_X86
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> index 8d4924b7dc22..101620a8867a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
> @@ -13,7 +13,7 @@
> DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
>
> ifdef CONFIG_X86
> -CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
> +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
> endif
>
> ifdef CONFIG_PPC64
> @@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
> ifeq ($(call cc-ifversion, -lt, 0701, y), y)
> IS_OLD_GCC = 1
> endif
> +CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
> endif
>
> ifdef CONFIG_X86
> --
> 2.29.2
>
> ___
> 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] drm/amd/display: change license of color_table.c
On Mon, Jan 25, 2021 at 7:07 AM Jonathan Gray wrote: > > This still needs to be corrected. Applied. Thanks! Alex > > On Thu, Nov 19, 2020 at 01:30:41PM +1100, Jonathan Gray wrote: > > Change the license of color_table.c to match color_table.h granting > > permission to modify and distribute. > > > > Signed-off-by: Jonathan Gray > > --- > > .../amd/display/modules/color/color_table.c | 26 +++ > > 1 file changed, 21 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/display/modules/color/color_table.c > > b/drivers/gpu/drm/amd/display/modules/color/color_table.c > > index 692e536e7d05..410f2a82b9a2 100644 > > --- a/drivers/gpu/drm/amd/display/modules/color/color_table.c > > +++ b/drivers/gpu/drm/amd/display/modules/color/color_table.c > > @@ -1,10 +1,26 @@ > > /* > > - * Copyright (c) 2019 Advanced Micro Devices, Inc. (unpublished) > > + * Copyright 2019 Advanced Micro Devices, Inc. > > + * > > + * Permission is hereby granted, free of charge, to any person obtaining a > > + * copy of this software and associated documentation files (the > > "Software"), > > + * to deal in the Software without restriction, including without > > limitation > > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > > + * and/or sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following conditions: > > + * > > + * The above copyright notice and this permission notice shall be included > > in > > + * all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > + * OTHER DEALINGS IN THE SOFTWARE. > > + * > > + * Authors: AMD > > * > > - * All rights reserved. This notice is intended as a precaution against > > - * inadvertent publication and does not imply publication or any waiver > > - * of confidentiality. The year included in the foregoing notice is the > > - * year of creation of the work. > > */ > > > > #include "color_table.h" > > -- > > 2.29.2 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings:drm/bridge:anx7625:add HDCP support flag and swing reg
On Mon, Jan 25, 2021 at 07:12:21PM +0800, Xin Ji wrote:
> Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> flag and DP tx lane0 and lane1 swing register array define.
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 57
> --
> 1 file changed, 54 insertions(+), 3 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index 60585a4..3b1cbe0 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -34,23 +34,69 @@ properties:
> description: used for reset chip control, RESET_N pin B7.
> maxItems: 1
>
> + analogix,lane0-swing:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description:
> + an array of swing register setting for DP tx lane0 PHY, please don't
> + add this property, or contact vendor.
> +
> + analogix,lane1-swing:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description:
> + an array of swing register setting for DP tx lane1 PHY, please don't
> + add this property, or contact vendor.
> +
> + analogix,hdcp-support:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: indicate the DP tx HDCP support or not.
Sounds like a boolean.
> +
>ports:
> type: object
> +additionalProperties: false
>
> properties:
>port@0:
> type: object
> description:
> - Video port for MIPI DSI input.
> + Video port for MIPI input.
You're going to need to rebase this one drm-misc-next which uses the
graph schema now.
> +
> +properties:
> + endpoint:
> +type: object
> +additionalProperties: false
> +
> +# Properties described in
> +# Documentation/devicetree/bindings/media/video-interfaces.txt
> +properties:
> + remote-endpoint: true
> + bus-type: true
> + data-lanes: true
> +
> +required:
> + - remote-endpoint
> +
> +required:
> + - endpoint
>
>port@1:
> type: object
> description:
>Video port for panel or connector.
>
> +properties:
> + endpoint:
> +type: object
> +additionalProperties: false
> +
> +required:
> + - remote-endpoint
> +
> +required:
> + - endpoint
> +
> required:
> -- port@0
> -- port@1
> + - port@0
> + - port@1
>
> required:
>- compatible
> @@ -73,6 +119,10 @@ examples:
> enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
>
> +analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
> +analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77 0x5b>;
> +analogix,hdcp-support = <0>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -81,6 +131,7 @@ examples:
> reg = <0>;
> anx7625_in: endpoint {
> remote-endpoint = <_dsi>;
> +bus-type = <5>;
> };
> };
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: fix unused variable warning
On 2021-01-25 7:48 a.m., Arnd Bergmann wrote:
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunused-variable]
Add another such #ifdef.
Fixes: 98ab5f3513f9 ("drm/amd/display: Fix deadlock during gpu reset v3")
Signed-off-by: Arnd Bergmann
Reviewed-by: Harry Wentland
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 a90dc4d31c32..37bf2dd87e1e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5377,7 +5377,9 @@ static inline int dm_set_vblank(struct drm_crtc *crtc,
bool enable)
struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = drm_to_adev(crtc->dev);
struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
struct amdgpu_display_manager *dm = >dm;
+#endif
int rc = 0;
if (enable) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: fbcon: remove soft scrollback code (missing Doc. patch)
Hi Phillip,
On Fri, Jan 22, 2021 at 8:26 PM Phillip Susi wrote:
> Geert Uytterhoeven writes:
> Judging from some of the comments in the code, it looks like you were
> one of the original authors of fbcon? I haven't been able to find any
Indeed, a long time ago... Before DRM existed.
> of these sczbot crash reports, and am not sure how fuzzing syscalls
> would really affect this code ( it's not really handling a buch of
> ioctls or otherwise taking arguments from user space ) , but I am a bit
AFAIU, most of these are triggered by VT ioctls.
There is an intimate relation between the VT and fbev subsystems: VT
changes impact fbdev, and vice versa.
Perhaps these should be decoupled, at the expense of worse user
experience (i.e. the user needing to change both screen resolution and
number of columns/rows of the text console)?
> confused as to why the softback was implemented the way that it was.
>
> vgacon simply copies the main buffer to vram in ->set_origin() and then
> changes the pointers to operate out of the much larger vram while that
> virtual terminal is active. If I understand it correctly, it looks like
> fbcon instead opts to operate out of the main buffer but rescue lines as
> they are scrolled off and relocate them to the softback buffer. This
> seems to be rather more convoluted.
>
> I'm thinking of re-implementing scrollback more like the way vgacon does
> it: allocate a big "vram" buffer and operate out of that. Obviously
> ->scroll() and ->scrolldelta() have to actually repaint the screen rather
> than simply change the pointer register, but that should be about the
> only difference.
I'm not that intimate familiar anymore with the current state of the
code, but it used to be like this:
- vgacon used a VRAM buffer for the current VC, and multiple shadow
buffers to implement virtual consoles,
- fbcon always used the shadow buffers, with each update triggering
an update of the frame buffer (see below).
As the text console buffer handling should be the same for vgacon and
fbcon, I expect most scrollback bugs (if any) to be present in both.
> I have also noticed that there was some code to use hardware panning of
> the video buffer rather than having to do a block bitblt to scroll the
> contents of the screen, but that it was disabled because virtually no
> video drivers actually implemented it? That seems like a shame, but if
> it is so, then there's no sense carrying the dead code so I think I'll
> clean that up now.
>
> Now that I look at it again, everything is simply always redrawn now
> instead of even doing a simple bitblt. Daniel, you mentioned that
> almost nobody supports hardware acceleration, but even without any
> specific hardware support, surely even if bitblt() is implemented just
> as a memcpy(), it has to be faster than redrawing all of the characters
> doesn't it? Getting rid of the panning if it isn't generally supported
> I can see, but I don't understand killing bitblt even if most devices
> don't accelerate it.
There are multiple ways to implement scrolling:
1. If the hardware supports a larger virtual screen and panning, and
the virtual screen is enabled, most scrolling can be implemented by
panning, with a casual copy when reaching the bottom (or top) of
the virtual screen.
This mode is (was) available on most graphics hardware with
dedicated graphics memory.
2. If a 2D acceleration engine is available, copying (and
clearing/filling) can be implemented by rectangle copy/fill
operations.
3. Rectangle copy/fill by the CPU is always available.
4. Redrawing characters by the CPU is always available.
Which option was used depended on the hardware: not all options are
available everywhere, and some perform better than others.
E.g. on PCI graphics cards, reading graphics memory by the CPU is
usually very slow, so option 3 is much slower than option 4 (given a
sufficiently fast CPU).
AFAIU, option 2 is not suitable for modern systems with 3D acceleration.
On the older (slower) systems (lacking VGA text mode) for which fbcon
was originally written, option 4 is usually the slowest.
Support for 1-3 were removed in commit 39aead8373b3c20b ("fbcon: Disable
accelerated scrolling"), which claimed only 3 (DRM) drivers made use of
this, ignoring the other 32 (fbdev) drivers making use of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Drop drm_simple_kms_format_mod_supported.
On Mon, Jan 25, 2021 at 1:13 PM Ville Syrjälä
wrote:
> On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> > The check was introduced to make sure that only the
> > DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
> >
> > However, if .format_mod_supported is not hooked up to
> > drm_simple_kms_format_mod_supported then the core will
> > simply validate modifiers against the format_modifiers
> > list passed into drm_simple_display_pipe_init() or
> > drm_universal_plane_init() and perform the same validation
> > as drm_simple_kms_format_mod_supported() would have done.
> >
> > Additionally, if a kms driver / plane does not support
> > modifiers, it will not reject fb updates with no modifiers/
> > DRM_FORMAT_MOD_INVALID. This is important, because some
> > simple drm drivers, e.g., pl111, pass NULL as format_modifiers
> > list, so modifier support is disabled for these drivers,
> > userspace would fall back to drmAddFB() without modifiers,
> > and ergo the current drm_simple_kms_format_mod_supported()
> > function would reject valid modifier-less fb's.
> >
> > So this should fix display on non-tinydrm drivers like
> > pl111, and probably also for non-atomic clients?
> >
> > The Mesa vc4 gallium driver mentions pl111 as one possible
> > display driver in render_only mode, so i assume this matters
> > for some SoC's?
> >
> > The background for the patch that introduced this was to
> > fix atomic modesetting in the X-Servers modesetting-ddx,
> > but with atomic modesetting and format modifiers disabled
> > in modesetting-ddx (and also current kernels when interacting
> > with modesetting-ddx), i assume this should fix some panels.
> >
> > Note that i don't have any of the hw required for testing
> > this, this is purely based on looking at the code, so this
> > patch is only compile-tested.
> >
> > For more reference, this fix was motivated by some discussions
> > around broken page-flipping on VideoCore6 / RaspberryPi 4
> > with current Raspbian OS, so the experts may want to weigh
> > in on that Mesa bug report as well, under the following link:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
> >
> > Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
> DRM_FORMAT_MOD_LINEAR.")
> > Signed-off-by: Mario Kleiner
> > Cc: Eric Anholt
> > Cc: Noralf Trønnes
> > Cc: Maxime Ripard
> > ---
> > drivers/gpu/drm/drm_simple_kms_helper.c | 8
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 743e57c1b44f..5f3e30553172 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -229,13 +229,6 @@ static void drm_simple_kms_plane_cleanup_fb(struct
> drm_plane *plane,
> > pipe->funcs->cleanup_fb(pipe, state);
> > }
> >
> > -static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
> > - uint32_t format,
> > - uint64_t modifier)
> > -{
> > - return modifier == DRM_FORMAT_MOD_LINEAR;
> > -}
> > -
> > static const struct drm_plane_helper_funcs
> drm_simple_kms_plane_helper_funcs = {
> > .prepare_fb = drm_simple_kms_plane_prepare_fb,
> > .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
> > @@ -250,7 +243,6 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> > .reset = drm_atomic_helper_plane_reset,
> > .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > - .format_mod_supported = drm_simple_kms_format_mod_supported,
>
> This will now cause also this driver to report a totally borked
> IN_FORMATS blob.
>
> Would need this
> https://patchwork.freedesktop.org/series/83018/
>
>
The slight problem with that (see my comments in the linked Mesa bug
report), is that at least one common userspace driver - modesetting-ddx -
treat a lack of an IN_FORMATS blob not as "don't use modifiers for
drm_framebuffers", but as "everything goes" -- Use every modifier and
tiling format that the graphics driver exposes also for scanout buffers.
I'm arguing in that bug report that modesetting-ddx shouldn't use atomic or
modifiers at all, given how broken that driver is atm. in that area, so i'm
not sure if my argument here is valid. Just saying that doing the "every
modifier is valid for every format" in absence of format_mod_supported()
would probably be less harmful to some existing userspace. Ofc. then
there's a reason why atomic gets rejected by the kernel for current
modesetting-ddx...
I'm not sure if I'm arguing pro or contra your patch here btw. Just
pointing out one possible victim if it were applied.
but IIRC the bikeshed around that kinda suggested we should just
> implement .format_mod_support() always. Can't quite recall the
> details anymore.
>
>
I see.
Re: [PATCH v4 01/14] drm/ttm: Remap all page faults to per process dummy page.
On 1/19/21 8:56 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand allocated dummy page
on the first fault for that BO.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 82 -
include/drm/ttm/ttm_bo_api.h| 2 +
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6dc96cf..ed89da3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -380,25 +382,103 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
}
EXPORT_SYMBOL(ttm_bo_vm_fault_reserved);
+static void ttm_bo_release_dummy_page(struct drm_device *dev, void *res)
+{
+ struct page *dummy_page = (struct page *)res;
+
+ __free_page(dummy_page);
+}
+
+vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct ttm_bo_device *bdev = bo->bdev;
+ struct drm_device *ddev = bo->base.dev;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
+ unsigned long address = vma->vm_start;
+ unsigned long num_prefault = (vma->vm_end - vma->vm_start) >>
PAGE_SHIFT;
+ unsigned long pfn;
+ struct page *page;
+ int i;
+
+ /*
+* Wait for buffer data in transit, due to a pipelined
+* move.
+*/
+ ret = ttm_bo_vm_fault_idle(bo, vmf);
+ if (unlikely(ret != 0))
+ return ret;
+
+ /* Allocate new dummy page to map all the VA range in this VMA to it*/
+ page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!page)
+ return VM_FAULT_OOM;
+
+ pfn = page_to_pfn(page);
+
+ /*
+* Prefault the entire VMA range right away to avoid further faults
+*/
+ for (i = 0; i < num_prefault; ++i) {
+
+ if (unlikely(address >= vma->vm_end))
+ break;
+
+ if (vma->vm_flags & VM_MIXEDMAP)
+ ret = vmf_insert_mixed_prot(vma, address,
+ __pfn_to_pfn_t(pfn,
PFN_DEV),
+ prot);
+ else
+ ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
+
+ /* Never error on prefaulted PTEs */
+ if (unlikely((ret & VM_FAULT_ERROR))) {
+ if (i == 0)
+ return VM_FAULT_NOPAGE;
+ else
+ break;
+ }
+
+ address += PAGE_SIZE;
+ }
+
+ /* Set the page to be freed using drmm release action */
+ if (drmm_add_action_or_reset(ddev, ttm_bo_release_dummy_page, page))
+ return VM_FAULT_OOM;
+
+ return ret;
+}
+EXPORT_SYMBOL(ttm_bo_vm_dummy_page);
I think we can lift this entire thing (once the ttm_bo_vm_fault_idle is
gone) to the drm level, since nothing ttm specific in here. Probably stuff
it into drm_gem.c (but really it's not even gem specific, it's fully
generic "replace this vma with dummy pages pls" function.
Once I started with this I noticed that drmm_add_action_or_reset depends
on struct drm_device *ddev = bo->base.dev and bo is the private data
we embed at the TTM level when setting up the mapping and so this forces
to move drmm_add_action_or_reset out of this function to every client who uses
this function, and then you separate the logic of page allocation from it's
release.
So I suggest we keep it as is.
Andrey
Aside from this nit I think the overall approach you have here is starting
to look good. Lots of work, but imo we're getting there and can
start landing stuff soon.
-Daniel
+
vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
pgprot_t prot;
struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct drm_device *ddev = bo->base.dev;
vm_fault_t ret;
+ int idx;
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
return ret;
prot = vma->vm_page_prot;
- ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+ if (drm_dev_enter(ddev, )) {
+ ret = ttm_bo_vm_fault_reserved(vmf, prot,
TTM_BO_VM_NUM_PREFAULT, 1);
+ drm_dev_exit(idx);
+ } else {
+ ret = ttm_bo_vm_dummy_page(vmf, prot);
+ }
if (ret == VM_FAULT_RETRY && !(vmf->flags &
Re: [PATCH][next] drm/amdgpu: Fix masking binary not operator on two mask operations
Applied. Thanks!
Alex
On Sun, Jan 24, 2021 at 11:36 PM Huang Rui wrote:
>
> On Fri, Jan 22, 2021 at 11:00:22PM +0800, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the ! operator is incorrectly being used to flip bits on
> > mask values. Fix this by using the bit-wise ~ operator instead.
> >
> > Addresses-Coverity: ("Logical vs. bitwise operator")
> > Fixes: 3c9a7b7d6e75 ("drm/amdgpu: update mmhub mgcg for mmhub_v2_3")
> > Signed-off-by: Colin Ian King
>
> Thanks.
>
> Reviewed-by: Huang Rui
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> > b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> > index 1961745e89c7..ab9be5ad5a5f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> > @@ -531,12 +531,12 @@ mmhub_v2_3_update_medium_grain_light_sleep(struct
> > amdgpu_device *adev,
> >
> > if (enable && (adev->cg_flags & AMD_CG_SUPPORT_MC_LS)) {
> > data &= ~MM_ATC_L2_CGTT_CLK_CTRL__MGLS_OVERRIDE_MASK;
> > - data1 &= !(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> > + data1 &= ~(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> > DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
> > DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
> > DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
> > DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_REGISTER_MASK);
> > - data2 &= !(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> > + data2 &= ~(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> > DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
> > DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
> > DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
> > --
> > 2.29.2
> >
> ___
> 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 v3 1/3] dt-bindings:drm/bridge:anx7625:add HDCP support flag and swing reg
On Mon, 25 Jan 2021 19:12:21 +0800, Xin Ji wrote:
> Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> flag and DP tx lane0 and lane1 swing register array define.
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 57
> --
> 1 file changed, 54 insertions(+), 3 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
encoder@58: ports: '#address-cells', '#size-cells' do not match any of the
regexes: 'pinctrl-[0-9]+'
From schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
encoder@58: ports:port@1:endpoint: Additional properties are not allowed
('remote-endpoint' was unexpected)
From schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
See https://patchwork.ozlabs.org/patch/1431199
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi Liu Ying, Just some minor comments below. On Thu, Jan 21, 2021 at 03:14:22PM +0800, Liu Ying wrote: > This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support. > > DPU is comprised of two main components that include a blit engine for > 2D graphics accelerations(with composition support) and a display controller > for display output processing, as well as a command sequencer. Outside of > DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and > Display Prefetch Resolve(DPR), can fetch data from memory prior to some DPU > fetchunits of blit engine and display controller. The prefetch engines > support reading linear formats and resolving Vivante GPU tile formats. > > This patch adds kernel modesetting support for the display controller part. > The driver supports two CRTCs per display controller, planes backed by > four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation > logic for the two CRTCs, prefetch engines(with tile resolving supported), > plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma > correction. The registers of the controller is accessed without command > sequencer involved, instead just by using CPU. > > Reference manual can be found at: > https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM > > Signed-off-by: Liu Ying > --- > v5->v6: > * Do not use macros where possible. (Laurentiu) > * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu) > * Address some minor comments from Laurentiu. > * Add dpu_crtc_err() helper marco to tell dmesg which CRTC generates error. > * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() as it is done > in dpu_drm_probe(). > * Some trivial tweaks. > > v4->v5: > * Rebase up onto the latest drm-misc-next branch and remove the hook to > drm_atomic_helper_legacy_gamma_set(), because it was dropped by the newly > landed commit 'drm: automatic legacy gamma support'. > * Remove a redundant blank line from dpu_plane_atomic_update(). > > v3->v4: > * No change. > > v2->v3: > * Fix build warnings Reported-by: kernel test robot . > * Drop build dependency on IMX_SCU, as dummy SCU functions have been added in > header files by the patch 'firmware: imx: add dummy functions' which has > landed in linux-next/master branch. > > v1->v2: > * Add compatible for i.MX8qm DPU, as this is tested with i.MX8qm LVDS > displays. > (Laurentiu) > * Fix PRG burst size and stride. (Laurentiu) > * Put 'ports' OF node to fix the bail-out logic in dpu_drm_probe(). > (Laurentiu) > > drivers/gpu/drm/imx/Kconfig |1 + > drivers/gpu/drm/imx/Makefile |1 + > drivers/gpu/drm/imx/dpu/Kconfig | 10 + > drivers/gpu/drm/imx/dpu/Makefile | 10 + > drivers/gpu/drm/imx/dpu/dpu-constframe.c | 171 + > drivers/gpu/drm/imx/dpu/dpu-core.c| 1094 > + > drivers/gpu/drm/imx/dpu/dpu-crtc.c| 967 + > drivers/gpu/drm/imx/dpu/dpu-crtc.h| 66 ++ > drivers/gpu/drm/imx/dpu/dpu-disengcfg.c | 117 +++ > drivers/gpu/drm/imx/dpu/dpu-dprc.c| 718 +++ > drivers/gpu/drm/imx/dpu/dpu-dprc.h| 40 ++ > drivers/gpu/drm/imx/dpu/dpu-drv.c | 292 > drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + > drivers/gpu/drm/imx/dpu/dpu-extdst.c | 299 > drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 294 > drivers/gpu/drm/imx/dpu/dpu-fetcheco.c| 224 ++ > drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c | 154 > drivers/gpu/drm/imx/dpu/dpu-fetchunit.c | 609 > drivers/gpu/drm/imx/dpu/dpu-fetchunit.h | 191 + > drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c | 250 +++ > drivers/gpu/drm/imx/dpu/dpu-framegen.c| 395 +++ > drivers/gpu/drm/imx/dpu/dpu-gammacor.c| 223 ++ > drivers/gpu/drm/imx/dpu/dpu-hscaler.c | 275 > drivers/gpu/drm/imx/dpu/dpu-kms.c | 540 ++ > drivers/gpu/drm/imx/dpu/dpu-kms.h | 23 + > drivers/gpu/drm/imx/dpu/dpu-layerblend.c | 348 + > drivers/gpu/drm/imx/dpu/dpu-plane.c | 799 + > drivers/gpu/drm/imx/dpu/dpu-plane.h | 56 ++ > drivers/gpu/drm/imx/dpu/dpu-prg.c | 433 > drivers/gpu/drm/imx/dpu/dpu-prg.h | 45 ++ > drivers/gpu/drm/imx/dpu/dpu-prv.h | 233 ++ > drivers/gpu/drm/imx/dpu/dpu-tcon.c| 250 +++ > drivers/gpu/drm/imx/dpu/dpu-vscaler.c | 308 > drivers/gpu/drm/imx/dpu/dpu.h | 385 ++ > 34 files changed, 9849 insertions(+) > create mode 100644 drivers/gpu/drm/imx/dpu/Kconfig > create mode 100644 drivers/gpu/drm/imx/dpu/Makefile > create mode 100644 drivers/gpu/drm/imx/dpu/dpu-constframe.c > create mode 100644 drivers/gpu/drm/imx/dpu/dpu-core.c > create mode 100644 drivers/gpu/drm/imx/dpu/dpu-crtc.c > create mode 100644
[PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 16 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 8 ++---
drivers/gpu/drm/drm_gem_vram_helper.c | 6 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ++--
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_object.c | 4 +--
drivers/gpu/drm/radeon/radeon_object.c| 8 ++---
drivers/gpu/drm/ttm/Makefile | 7 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 33 +--
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c | 24 +++---
drivers/gpu/drm/ttm/ttm_pool.c| 13 +---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c | 19 ---
.../gpu/drm/vmwgfx}/ttm_memory.h | 5 +--
drivers/gpu/drm/vmwgfx/ttm_object.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 22 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 28 +++-
include/drm/ttm/ttm_bo_api.h | 13 ++--
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_tt.h | 1 +
22 files changed, 112 insertions(+), 115 deletions(-)
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c (97%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_memory.h (97%)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 0849b68e784f..3e62923a7e63 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -118,6 +118,16 @@ void amdgpu_amdkfd_gpuvm_init_mem_limits(void)
*/
#define ESTIMATE_PT_SIZE(mem_size) ((mem_size) >> 14)
+static size_t amdgpu_amdkfd_acc_size(uint64_t size)
+{
+ size >>= PAGE_SHIFT;
+ size *= sizeof(dma_addr_t) + sizeof(void *);
+
+ return __roundup_pow_of_two(sizeof(struct amdgpu_bo)) +
+ __rountup_pow_of_two(sizeof(struct ttm_tt)) +
+ PAGE_ALIGN(size);
+}
+
static int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 domain, bool sg)
{
@@ -126,8 +136,7 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
size_t acc_size, system_mem_needed, ttm_mem_needed, vram_needed;
int ret = 0;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
vram_needed = 0;
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
@@ -174,8 +183,7 @@ static void unreserve_mem_limit(struct amdgpu_device *adev,
{
size_t acc_size;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
spin_lock(_mem_limit.mem_limit_lock);
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 6cc9919b12cc..599c9a132eb6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -523,7 +523,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
- size_t acc_size;
int r;
/* Note that GDS/GWS/OA allocates 1 page per byte/resource. */
@@ -546,9 +545,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
*bo_ptr = NULL;
- acc_size = ttm_bo_dma_acc_size(>mman.bdev, size,
- sizeof(struct amdgpu_bo));
-
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
@@ -577,8 +573,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.priority = 1;
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp->type,
->placement, page_align, , acc_size,
-NULL, bp->resv, _bo_destroy);
+>placement, page_align, , NULL,
+bp->resv, _bo_destroy);
if (unlikely(r != 0))
return r;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 0b13c8507688..a0992f0b8afd 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -189,7 +189,6 @@
[PATCH 3/3] drm/ttm: drop sysfs directory
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_module.c | 50
drivers/gpu/drm/ttm/ttm_module.h | 2 --
2 files changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index f6566603a60f..56b0efdba1a9 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -37,66 +37,16 @@
#include "ttm_module.h"
-static DECLARE_WAIT_QUEUE_HEAD(exit_q);
-static atomic_t device_released;
struct dentry *ttm_debugfs_root;
-static struct device_type ttm_drm_class_type = {
- .name = "ttm",
- /**
-* Add pm ops here.
-*/
-};
-
-static void ttm_drm_class_device_release(struct device *dev)
-{
- atomic_set(_released, 1);
- wake_up_all(_q);
-}
-
-static struct device ttm_drm_class_device = {
- .type = _drm_class_type,
- .release = _drm_class_device_release
-};
-
-struct kobject *ttm_get_kobj(void)
-{
- struct kobject *kobj = _drm_class_device.kobj;
- BUG_ON(kobj == NULL);
- return kobj;
-}
-
static int __init ttm_init(void)
{
- int ret;
-
- ret = dev_set_name(_drm_class_device, "ttm");
- if (unlikely(ret != 0))
- return ret;
-
- atomic_set(_released, 0);
- ret = drm_class_device_register(_drm_class_device);
- if (unlikely(ret != 0))
- goto out_no_dev_reg;
-
ttm_debugfs_root = debugfs_create_dir("ttm", NULL);
return 0;
-out_no_dev_reg:
- atomic_set(_released, 1);
- wake_up_all(_q);
- return ret;
}
static void __exit ttm_exit(void)
{
- drm_class_device_unregister(_drm_class_device);
-
- /**
-* Refuse to unload until the TTM device is released.
-* Not sure this is 100% needed.
-*/
-
- wait_event(exit_q, atomic_read(_released) == 1);
debugfs_remove(ttm_debugfs_root);
}
diff --git a/drivers/gpu/drm/ttm/ttm_module.h b/drivers/gpu/drm/ttm/ttm_module.h
index 2f03c2fcf570..d7cac5d4b835 100644
--- a/drivers/gpu/drm/ttm/ttm_module.h
+++ b/drivers/gpu/drm/ttm/ttm_module.h
@@ -33,10 +33,8 @@
#define TTM_PFX "[TTM] "
-struct kobject;
struct dentry;
-extern struct kobject *ttm_get_kobj(void);
extern struct dentry *ttm_debugfs_root;
#endif /* _TTM_MODULE_H_ */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ttm: rework ttm_tt page limit v3
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during swapout while trying to handle the memory shortage.
This is only partially a good idea. First of all it is perfectly
valid for an application to use all of system memory, limiting it to
50% is not really acceptable.
What we need to take care of is that the application is held
accountable for the memory it allocated. This is what control
mechanisms like memcg and the normal Linux page accounting already do.
Making sure that we don't run into an OOM situation while trying to
cope with a memory shortage is still a good idea, but this is also
not very well implemented since it means another opportunity of
recursion from the driver back into TTM.
So start to rework all of this by implementing a shrinker callback which
allows for TT object to be swapped out if necessary.
v2: Switch from limit to shrinker callback.
v3: fix gfp mask handling, use atomic for swapable_pages, add debugfs
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 4 +-
drivers/gpu/drm/ttm/ttm_memory.c| 7 +-
drivers/gpu/drm/ttm/ttm_tt.c| 111 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/ttm/ttm_bo_api.h| 2 +-
include/drm/ttm/ttm_tt.h| 6 +-
6 files changed, 117 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 20256797f3a6..643befc1a6f2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1219,7 +1219,7 @@ EXPORT_SYMBOL(ttm_bo_wait);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
+int ttm_bo_swapout(struct ttm_operation_ctx *ctx, gfp_t gfp_flags)
{
struct ttm_global *glob = _glob;
struct ttm_buffer_object *bo;
@@ -1302,7 +1302,7 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->bdev->funcs->swap_notify)
bo->bdev->funcs->swap_notify(bo);
- ret = ttm_tt_swapout(bo->bdev, bo->ttm);
+ ret = ttm_tt_swapout(bo->bdev, bo->ttm, gfp_flags);
out:
/**
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index a3bfbd9cea68..634a85c2dc4c 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "ttm_module.h"
@@ -276,9 +277,9 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(>lock);
- ret = ttm_bo_swapout(ctx);
+ ret = ttm_bo_swapout(ctx, GFP_KERNEL);
spin_lock(>lock);
- if (unlikely(ret != 0))
+ if (unlikely(ret < 0))
break;
}
@@ -453,6 +454,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
zone->name, (unsigned long long)zone->max_mem >> 10);
}
ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
+ ttm_tt_mgr_init();
return 0;
out_no_zone:
ttm_mem_global_release(glob);
@@ -466,6 +468,7 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
/* let the page allocator first stop the shrink work. */
ttm_pool_mgr_fini();
+ ttm_tt_mgr_fini();
flush_workqueue(glob->swap_queue);
destroy_workqueue(glob->swap_queue);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 7782d5393c7c..b67795de228d 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,11 @@
#include
#include
+#include "ttm_module.h"
+
+static struct shrinker mm_shrinker;
+static atomic_long_t swapable_pages;
+
/*
* Allocates a ttm structure for the given BO.
*/
@@ -223,32 +228,41 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
return ret;
}
-int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm)
+/**
+ * ttm_tt_swapout - swap out tt object
+ *
+ * @bdev: TTM device structure.
+ * @ttm: The struct ttm_tt.
+ * @gfp_flags: Flags to use for memory allocation.
+ *
+ * Swapout a TT object to a shmem_file, return number of pages swapped out or
+ * negative error code.
+ */
+int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm,
+ gfp_t gfp_flags)
{
+ loff_t size = (loff_t)ttm->num_pages << PAGE_SHIFT;
struct address_space *swap_space;
struct file *swap_storage;
struct page *from_page;
struct page *to_page;
- gfp_t gfp_mask;
int i, ret;
- swap_storage = shmem_file_setup("ttm
Re: [PATCH] drm/amd/display: use div_s64() for 64-bit division
On Mon, Jan 25, 2021 at 1:51 PM Chen, Guchun wrote: > > [AMD Public Use] > > Hi Arnd Bergmann, > > Thanks for your patch. This link error during compile has been fixed by below > commit and been submitted to drm-next branch already. > > 5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS Ok, thanks. I assume this will make it into linux-next in the coming days then. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Fix DRM_I915_WERROR dependencies
On Mon, Jan 25, 2021 at 1:33 PM Chris Wilson wrote: > > Quoting Arnd Bergmann (2021-01-25 12:26:44) > > From: Arnd Bergmann > > > > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails > > to honor its dependencies: > > > > WARNING: unmet direct dependencies detected for DRM_I915_WERROR > > Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && > > !COMPILE_TEST [=y] > > Selected by [m]: > > - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] > > DRM_I915_DEBUG now depends on !COMPILE_TEST and EXPERT. Works for me, thanks! Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amd/display: use div_s64() for 64-bit division
[AMD Public Use]
Hi Arnd Bergmann,
Thanks for your patch. This link error during compile has been fixed by below
commit and been submitted to drm-next branch already.
5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Arnd Bergmann
Sent: Monday, January 25, 2021 7:40 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; David Airlie ; Daniel
Vetter ; Aberback, Joshua ; Lakha,
Bhawanpreet ; Kazlauskas, Nicholas
Cc: Arnd Bergmann ; Chalmers, Wesley ;
Zhuo, Qingqing ; Siqueira, Rodrigo
; linux-ker...@vger.kernel.org;
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Jacky Liao
; Leung, Martin
Subject: [PATCH] drm/amd/display: use div_s64() for 64-bit division
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. One of them was an unsigned
division originally, but it looks like signed division was intended, so use
that to consistently allow a negative delay.
Fixes: ea7154d8d9fb ("drm/amd/display: Update
dcn30_apply_idle_power_optimizations() code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index dff83c6a142a..a133e399e76d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -772,8 +772,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
cursor_cache_enable ?
_attr : NULL)) {
unsigned int v_total =
stream->adjust.v_total_max ?
stream->adjust.v_total_max :
stream->timing.v_total;
- unsigned int refresh_hz = (unsigned long long)
stream->timing.pix_clk_100hz *
- 100LL / (v_total *
stream->timing.h_total);
+ unsigned int refresh_hz = div_s64((unsigned
long long) stream->timing.pix_clk_100hz *
+ 100LL, v_total *
stream->timing.h_total);
/*
* one frame time in microsec:
@@ -800,8 +800,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
unsigned int denom = refresh_hz * 6528;
unsigned int stutter_period =
dc->current_state->perf_params.stutter_period_us;
- tmr_delay = (((100LL + 2 * stutter_period *
refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
/* scale should be increased until it fits into
6 bits */ @@ -815,8 +815,8 @@ bool dcn30_apply_idle_power_optimizations(struct
dc *dc, bool enable)
}
denom *= 2;
- tmr_delay = (((100LL + 2 *
stutter_period * refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
}
--
2.29.2
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Cguchun.chen%40amd.com%7C4bb97aae9edc4153392c08d8c1260048%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637471716255231899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kLdkVHfkYx%2Bd249%2BmtG5GJTq295Pxzw7mgTe0FD8QvY%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: fix unused variable warning
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunused-variable]
Add another such #ifdef.
Fixes: 98ab5f3513f9 ("drm/amd/display: Fix deadlock during gpu reset v3")
Signed-off-by: Arnd Bergmann
---
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 a90dc4d31c32..37bf2dd87e1e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5377,7 +5377,9 @@ static inline int dm_set_vblank(struct drm_crtc *crtc,
bool enable)
struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = drm_to_adev(crtc->dev);
struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
struct amdgpu_display_manager *dm = >dm;
+#endif
int rc = 0;
if (enable) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gem: fix non-SMP build failure
Quoting Arnd Bergmann (2021-01-25 12:25:34) > From: Arnd Bergmann > > The x86-specific wbinvd_on_all_cpus() function is exported > through asm/smp.h, causing a build failure in the i915 driver > when SMP is disabled: > > drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of > function 'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function-declaration] I thought the code was already in i915_gem_pm.c (which included smp.h); it is now. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Fix DRM_I915_WERROR dependencies
Quoting Arnd Bergmann (2021-01-25 12:26:44) > From: Arnd Bergmann > > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails > to honor its dependencies: > > WARNING: unmet direct dependencies detected for DRM_I915_WERROR > Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && > !COMPILE_TEST [=y] > Selected by [m]: > - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] DRM_I915_DEBUG now depends on !COMPILE_TEST and EXPERT. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: Fix DRM_I915_WERROR dependencies
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
Change the 'select' to a conditional one that doesn't trigger -Werror
warnings for allmodconfig builds and other compile tests.
Fixes: 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index be76054c01d8..97793b28d007 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -31,9 +31,9 @@ config DRM_I915_DEBUG
select DRM_DEBUG_SELFTEST
select DMABUF_SELFTESTS
select SW_SYNC # signaling validation framework (igt/syncobj*)
- select DRM_I915_WERROR
- select DRM_I915_DEBUG_GEM
- select DRM_I915_DEBUG_GEM_ONCE
+ select DRM_I915_WERROR if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM_ONCE if !COMPILE_TEST
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gem: fix non-SMP build failure
From: Arnd Bergmann
The x86-specific wbinvd_on_all_cpus() function is exported
through asm/smp.h, causing a build failure in the i915 driver
when SMP is disabled:
drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of function
'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function-declaration]
Include that header file explicitly.
Fixes: 30d2bfd09383 ("drm/i915/gem: Almagamate clflushes on freeze")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9b04dff5eb32..2a1643514577 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "display/intel_display.h"
#include "display/intel_frontbuffer.h"
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu: fix clang build warning
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 --
drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
index c20331eb62e0..dfd77b3cc84d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
@@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o dcn30_dpp.o
dcn30_optc.o \
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
endif
ifdef CONFIG_PPC64
@@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
index 3ca7d911d25c..09264716d1dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
@@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o
dcn301_hubbub.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
index 8d4924b7dc22..101620a8867a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
@@ -13,7 +13,7 @@
DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
endif
ifdef CONFIG_X86
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp_mst: Align mst link rate with soure rate
On Wed, Jan 13, 2021 at 01:51:00PM +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Koba Ko wrote:
> > After read the link rate from MST hub, align with
> > maximum source rate.
> >
> > Signed-off-by: Koba Ko
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8
> > drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
> > include/drm/drm_dp_helper.h | 8
> > include/drm/drm_dp_mst_helper.h | 4
> > 4 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 6982ecbf30b5..e7ceae97be85 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3672,6 +3672,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > {
> > int ret = 0;
> > struct drm_dp_mst_branch *mstb = NULL;
> > + unsigned int max_link_rate_tbl[MAX_DRM_DP_MAX_RATE + 1] = {
> > + DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4,
> > + DP_LINK_BW_8_1, DP_LINK_RATE_TABLE
> > + };
>
> Please no. Read on for why.
>
> >
> > mutex_lock(>payload_lock);
> > mutex_lock(>lock);
> > @@ -3693,6 +3697,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > goto out_unlock;
> > }
> >
> > + if (mgr->max_source_rate < MAX_DRM_DP_MAX_RATE)
> > + mgr->dpcd[1] = max_link_rate_tbl[mgr->max_source_rate];
>
> Make ->max_source_rate the actual physical rate in kHz, and use
> drm_dp_link_rate_to_bw_code() here.
>
> > +
> > mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
> > mgr->dpcd[2] &
> > DP_MAX_LANE_COUNT_MASK);
> > if (mgr->pbn_div == 0) {
> > @@ -5422,6 +5429,7 @@ int drm_dp_mst_topology_mgr_init(struct
> > drm_dp_mst_topology_mgr *mgr,
> > mgr->aux = aux;
> > mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
> > mgr->max_payloads = max_payloads;
> > + mgr->max_source_rate = MAX_DRM_DP_MAX_RATE;
> > mgr->conn_base_id = conn_base_id;
> > if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
> > max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 469e765a1b7b..a89b4c823123 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5392,6 +5392,13 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> > intel_dp->is_mst = sink_can_mst &&
> > i915->params.enable_dp_mst;
> >
> > + if (intel_dp_source_supports_hbr3(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR3;
> > + else if (intel_dp_source_supports_hbr2(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR2;
> > + else
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR;
>
> Whenever this file references a "rate", it's the rate in kHz. This is
> confusing. Use the rate in kHz.
>
> Also, please look at how intel_dp_source_supports_hbr* are implemented;
> we already have all the supported source rates cached in intel_dp.
>
> The max source rate is:
>
> intel_dp->source_rates[intel_dp->num_source_rates - 1].
>
> No need to do the if ladder here at all. If you like, you can add a
> helper:
>
> int intel_dp_max_source_rate(struct intel_dp *intel_dp)
> {
> return intel_dp->source_rates[intel_dp->num_source_rates - 1];
> }
Using the max source rate isn't super great either. A bit better
than the current mess though.
The correct fix would be to let the driver provide the actually
used link_rate+lane_count to the MST code during atomic_check(),
instead of trying to guess what the driver is going to use.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/qxl: unpin release objects
> > Just calling ttm_bo_unpin() here makes lockdep unhappy.
>
> How does that one splat? But yeah if that's a problem should be
> explained in the comment. I'd then also only do a pin_count--; to make
> sure you can still catch other pin leaks if you have them. Setting it
> to 0 kinda defeats the warning.
Figured the unpin is at the completely wrong place while trying to
reproduce the lockdep splat ...
take care,
Gerd
>From 43befab4a935114e8620af62781666fa81288255 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Mon, 25 Jan 2021 13:10:50 +0100
Subject: [PATCH] drm/qxl: unpin release objects
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index c52412724c26..28013fd1f8ea 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -347,6 +347,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
unsigned long size,
mutex_lock(>release_mutex);
if (qdev->current_release_bo_offset[cur_idx] + 1 >=
releases_per_bo[cur_idx]) {
+ qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
qxl_bo_unref(>current_release_bo[cur_idx]);
qdev->current_release_bo_offset[cur_idx] = 0;
qdev->current_release_bo[cur_idx] = NULL;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
> This is not an uapi defintion anyway so fixing should be fine. Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah should be completely fine to fix it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Drop drm_simple_kms_format_mod_supported.
On Sun, Jan 24, 2021 at 09:47:48PM +0100, Mario Kleiner wrote:
> The check was introduced to make sure that only the
> DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
>
> However, if .format_mod_supported is not hooked up to
> drm_simple_kms_format_mod_supported then the core will
> simply validate modifiers against the format_modifiers
> list passed into drm_simple_display_pipe_init() or
> drm_universal_plane_init() and perform the same validation
> as drm_simple_kms_format_mod_supported() would have done.
>
> Additionally, if a kms driver / plane does not support
> modifiers, it will not reject fb updates with no modifiers/
> DRM_FORMAT_MOD_INVALID. This is important, because some
> simple drm drivers, e.g., pl111, pass NULL as format_modifiers
> list, so modifier support is disabled for these drivers,
> userspace would fall back to drmAddFB() without modifiers,
> and ergo the current drm_simple_kms_format_mod_supported()
> function would reject valid modifier-less fb's.
>
> So this should fix display on non-tinydrm drivers like
> pl111, and probably also for non-atomic clients?
>
> The Mesa vc4 gallium driver mentions pl111 as one possible
> display driver in render_only mode, so i assume this matters
> for some SoC's?
>
> The background for the patch that introduced this was to
> fix atomic modesetting in the X-Servers modesetting-ddx,
> but with atomic modesetting and format modifiers disabled
> in modesetting-ddx (and also current kernels when interacting
> with modesetting-ddx), i assume this should fix some panels.
>
> Note that i don't have any of the hw required for testing
> this, this is purely based on looking at the code, so this
> patch is only compile-tested.
>
> For more reference, this fix was motivated by some discussions
> around broken page-flipping on VideoCore6 / RaspberryPi 4
> with current Raspbian OS, so the experts may want to weigh
> in on that Mesa bug report as well, under the following link:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
>
> Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
> DRM_FORMAT_MOD_LINEAR.")
> Signed-off-by: Mario Kleiner
> Cc: Eric Anholt
> Cc: Noralf Trønnes
> Cc: Maxime Ripard
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 743e57c1b44f..5f3e30553172 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -229,13 +229,6 @@ static void drm_simple_kms_plane_cleanup_fb(struct
> drm_plane *plane,
> pipe->funcs->cleanup_fb(pipe, state);
> }
>
> -static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
> - uint32_t format,
> - uint64_t modifier)
> -{
> - return modifier == DRM_FORMAT_MOD_LINEAR;
> -}
> -
> static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs
> = {
> .prepare_fb = drm_simple_kms_plane_prepare_fb,
> .cleanup_fb = drm_simple_kms_plane_cleanup_fb,
> @@ -250,7 +243,6 @@ static const struct drm_plane_funcs
> drm_simple_kms_plane_funcs = {
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> - .format_mod_supported = drm_simple_kms_format_mod_supported,
This will now cause also this driver to report a totally borked
IN_FORMATS blob.
Would need this
https://patchwork.freedesktop.org/series/83018/
but IIRC the bikeshed around that kinda suggested we should just
implement .format_mod_support() always. Can't quite recall the
details anymore.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote: > On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote: > > > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner < > > mario.kleiner...@gmail.com> wrote: > > > > > But it still needs to be fixed if we want working HDR. I thought > > > libdrm copies the definitions from the kernel periodically, so the > > > fix should propagate? > > > > There will always be user-space that sends 1 instead of 0. This > > shouldn't fail on more recent kernels or it will be a regression. > > > > Yes, i know, regressing user-space is bad, but in this very specific case a > "good" one, if ever. At the moment, it wouldn't regress userspace simply > because the kernel doesn't actually check for the correct value in its HDR > metadata handling. But the value itself is sent as HDMI HDR metadata to the > attached HDR display monitor, so if the monitors firmware checks, it will > classify the wrong value of 1 as invalid and disable HDR mode on the > display, which is certainly not what a HDR client application wants. And > future HDR standards which will actually allocate the value 1 to a > different mode of HDR operation will switch to the wrong mode / > misinterpret the sent HDR metadata with hillarious results, which is also > not in the interest of a HDR client application, or a HDR capable > compositor. > > Iow. if clients continue to use the wrong value 1 then HDR display will > break in various ways on correctly implemented HDR displays, but in a > mystifying and hard to debug way. The kernel rejecting a wrong setting > explicitly and forcing a bug fix in the client would be a blessing in this > case. > > I spent weeks last year, going in circles and hunting ghost bugs related to > HDR because much of the HDR stuff, both drivers and monitor firmware seems > to be in not a great shape. "Less wrong" would be a big step forward. > Especially with the cheaper HDR monitors it is difficult to see when things > go wrong, because we don't have good expectations on how proper HDR should > look and the lower end HDR displays don't help. This is not an uapi defintion anyway so fixing should be fine. I don't think we even check any of the client provided values, or do we? EOTF I think we do check, but IMO that check should probably just be nuked as well if we don't bother checking anything else. I was in fact going to suggest nuking this entire hdr_sink_metadata parsing as unused, but looks like amdgpu has started to use it for some backlight stuff of all things. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: change license of color_table.c
This still needs to be corrected. On Thu, Nov 19, 2020 at 01:30:41PM +1100, Jonathan Gray wrote: > Change the license of color_table.c to match color_table.h granting > permission to modify and distribute. > > Signed-off-by: Jonathan Gray > --- > .../amd/display/modules/color/color_table.c | 26 +++ > 1 file changed, 21 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/modules/color/color_table.c > b/drivers/gpu/drm/amd/display/modules/color/color_table.c > index 692e536e7d05..410f2a82b9a2 100644 > --- a/drivers/gpu/drm/amd/display/modules/color/color_table.c > +++ b/drivers/gpu/drm/amd/display/modules/color/color_table.c > @@ -1,10 +1,26 @@ > /* > - * Copyright (c) 2019 Advanced Micro Devices, Inc. (unpublished) > + * Copyright 2019 Advanced Micro Devices, Inc. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + * > + * Authors: AMD > * > - * All rights reserved. This notice is intended as a precaution against > - * inadvertent publication and does not imply publication or any waiver > - * of confidentiality. The year included in the foregoing notice is the > - * year of creation of the work. > */ > > #include "color_table.h" > -- > 2.29.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/11] drm: Rename plane->state variables in atomic update and disable
On Mon, Jan 25, 2021 at 11:52:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Fri, Jan 22, 2021 at 02:15:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> > > Some drivers are storing the plane->state pointer in atomic_update and
> > > atomic_disable in a variable simply called state, while the state passed
> > > as an argument is called old_state.
> > >
> > > In order to ease subsequent reworks and to avoid confusing or
> > > inconsistent names, let's rename those variables to new_state.
> > >
> > > This was done using the following coccinelle script, plus some manual
> > > changes for mtk and tegra.
> > >
> > > @ plane_atomic_func @
> > > identifier helpers;
> > > identifier func;
> > > @@
> > >
> > > (
> > > static const struct drm_plane_helper_funcs helpers = {
> > > ...,
> > > .atomic_disable = func,
> > > ...,
> > > };
> > > |
> > > static const struct drm_plane_helper_funcs helpers = {
> > > ...,
> > > .atomic_update = func,
> > > ...,
> > > };
> > > )
> > >
> > > @ moves_new_state_old_state @
> > > identifier plane_atomic_func.func;
> > > identifier plane;
> > > symbol old_state;
> > > symbol state;
> > > @@
> > >
> > > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > > {
> > > ...
> > > - struct drm_plane_state *state = plane->state;
> > > + struct drm_plane_state *new_state = plane->state;
> > > ...
> > > }
> > >
> > > @ depends on moves_new_state_old_state @
> > > identifier plane_atomic_func.func;
> > > identifier plane;
> > > identifier old_state;
> > > symbol state;
> > > @@
> > >
> > > func(struct drm_plane *plane, struct drm_plane_state *old_state)
> > > {
> > > <...
> > > - state
> > > + new_state
> > > ...>
> >
> > Was going to say that this migh eat something else, but I guess
> > the dependency prevents that?
>
> Yeah, the dependency takes care of this
>
> > Another way to avoid that I suppose would be to declare 'state'
> > as
> > symbol moves_new_state_old_state.state;
> >
> > That would probably make the intent a bit more obvious, even with
> > the dependency. Or does a dependency somehow automagically imply
> > that?
>
> I'm not sure if it does, but it's a symbol here not an identifier or an
> expression, so here moves_new_state_old_state.state would always resolve
> to state (and only state) anyway
Hm. Right. OK, cocci bits look good to me. Variable naming
bikeshed I'll leave to others :)
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: use div_s64() for 64-bit division
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. One of them was an
unsigned division originally, but it looks like signed division was
intended, so use that to consistently allow a negative delay.
Fixes: ea7154d8d9fb ("drm/amd/display: Update
dcn30_apply_idle_power_optimizations() code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index dff83c6a142a..a133e399e76d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -772,8 +772,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
cursor_cache_enable ?
_attr : NULL)) {
unsigned int v_total =
stream->adjust.v_total_max ?
stream->adjust.v_total_max :
stream->timing.v_total;
- unsigned int refresh_hz = (unsigned long long)
stream->timing.pix_clk_100hz *
- 100LL / (v_total *
stream->timing.h_total);
+ unsigned int refresh_hz = div_s64((unsigned
long long) stream->timing.pix_clk_100hz *
+ 100LL, v_total *
stream->timing.h_total);
/*
* one frame time in microsec:
@@ -800,8 +800,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
unsigned int denom = refresh_hz * 6528;
unsigned int stutter_period =
dc->current_state->perf_params.stutter_period_us;
- tmr_delay = (((100LL + 2 * stutter_period *
refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
/* scale should be increased until it fits into
6 bits */
@@ -815,8 +815,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
}
denom *= 2;
- tmr_delay = (((100LL + 2 *
stutter_period * refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized variable ret
It is already merged to drm-intel-next
https://cgit.freedesktop.org/drm/drm-intel/commit/?h=drm-intel-next=40a6cead28f841ac350bd38dd7260ecacd5eab03
> -Original Message-
> From: Jani Nikula
> Sent: Friday, January 22, 2021 8:51 PM
> To: Colin King ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; C,
> Ramalingam
> ; Gupta, Anshuman ;
> Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized
> variable ret
>
> On Fri, 22 Jan 2021, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently when there are other connectors on the port using HDCP the
> > function _intel_hdcp_disable returns a garbage uninitialized value in
> > variable ret. I believe the intention is to return 0, so return this
> > literal value instead of the value in ret.
> >
> > Addresses-Coverity: ("Uninitialized scalar return")
> > Fixes: 899c8762f981 ("drm/i915/hdcp: Configure HDCP2.2 MST steram
> > encryption status")
> > Signed-off-by: Colin Ian King
>
> Thanks, but there's already a fix in progress:
>
> http://lore.kernel.org/r/20210119064655.1605-3-anshuman.gu...@intel.com
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index db8dff2eeb0a..a0e7b0bf892b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -883,7 +883,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> > * until it disabled HDCP encryption for all connectors in MST topology.
> > */
> > if (dig_port->num_hdcp_streams > 0)
> > - return ret;
> > + return 0;
> >
> > hdcp->hdcp_encrypted = false;
> > intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port),
> > 0);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()
Quoting Dan Carpenter (2021-01-25 08:48:30)
> Smatch found an uninitialized variable bug in this code:
>
> drivers/gpu/drm/i915/gvt/cmd_parser.c:3191
> intel_gvt_update_reg_whitelist()
> error: uninitialized symbol 'ret'.
>
> The first thing that Smatch complains about is that "ret" isn't set if
> we don't enter the "for_each_engine(engine, _priv->gt, id) {" loop.
> Presumably we always have at least one engine so that's a false
> positive.
>
> But it's definitely a bug to not set "ret" if i915_gem_object_pin_map()
> fails.
True.
> Let's fix the bug and silence the false positive.
>
> Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd
> accessible reg whitelist")
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbtft: add tearing signal detect
On Mon, Jan 25, 2021 at 04:44:12PM +0800, Carlis wrote: > From: "carlis.zhang_cp" I need a "real" name here, and in the signed-off-by: area as I do not think you sign documents with a "." and "_", right? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()
Smatch found an uninitialized variable bug in this code:
drivers/gpu/drm/i915/gvt/cmd_parser.c:3191 intel_gvt_update_reg_whitelist()
error: uninitialized symbol 'ret'.
The first thing that Smatch complains about is that "ret" isn't set if
we don't enter the "for_each_engine(engine, _priv->gt, id) {" loop.
Presumably we always have at least one engine so that's a false
positive.
But it's definitely a bug to not set "ret" if i915_gem_object_pin_map()
fails.
Let's fix the bug and silence the false positive.
Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd accessible
reg whitelist")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 7fb91de06557..d54ea0e4681d 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3103,7 +3103,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
struct intel_vgpu_submission *s = >submission;
struct i915_request *requests[I915_NUM_ENGINES] = {};
bool is_ctx_pinned[I915_NUM_ENGINES] = {};
- int ret;
+ int ret = 0;
if (gvt->is_reg_whitelist_updated)
return;
@@ -3157,6 +3157,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
if (IS_ERR(vaddr)) {
gvt_err("failed to pin init ctx obj, ring=%d,
err=%lx\n",
id, PTR_ERR(vaddr));
+ ret = PTR_ERR(vaddr);
goto out;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx/vmwgfx_drv: Fix an error path in vmw_setup_pci_resources()
The devm_memremap() function never returns NULL, it returns error
pointers so the test needs to be fixed. Also we need to call
pci_release_regions() to avoid a memory leak.
Fixes: be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index eb997f4678de..3f603a6b5f90 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -668,9 +668,10 @@ static int vmw_setup_pci_resources(struct vmw_private *dev,
fifo_size,
MEMREMAP_WB);
- if (unlikely(dev->fifo_mem == NULL)) {
+ if (IS_ERR(dev->fifo_mem)) {
DRM_ERROR("Failed mapping FIFO memory.\n");
- return -ENOMEM;
+ pci_release_regions(pdev);
+ return PTR_ERR(dev->fifo_mem);
}
/*
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
Hello, this patch set adds the support of the Lontium lt8912 MIPI to HDMI bridge in the kernel. It's only support the video part, not the audio part yet since I don't have the datasheet of this component. I get the current i2c configuration from Digi and Boundary drivers. Developed using the DB_DSIHD board from BoundaryDevices. Thanks, Adrien Grassein Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912 drm/bridge: Introduce LT8912 DSI to HDMI bridge .../display/bridge/lontium,lt8912.yaml| 92 +++ MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig| 14 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt8912.c | 749 ++ 5 files changed, 862 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
On 12/24/20 7:18 AM, Marek Vasut wrote: The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to select input pixel data sampling edge. Add DT property "pixelclk-active", same as the one used by display timings, and configure bus flags based on this DT property. Bump ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp_mst: Align mst link rate with soure rate
On Wed, Jan 13, 2021 at 7:51 PM Jani Nikula
wrote:
>
> On Wed, 13 Jan 2021, Koba Ko wrote:
> > After read the link rate from MST hub, align with
> > maximum source rate.
> >
> > Signed-off-by: Koba Ko
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8
> > drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
> > include/drm/drm_dp_helper.h | 8
> > include/drm/drm_dp_mst_helper.h | 4
> > 4 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 6982ecbf30b5..e7ceae97be85 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3672,6 +3672,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
> > {
> > int ret = 0;
> > struct drm_dp_mst_branch *mstb = NULL;
> > + unsigned int max_link_rate_tbl[MAX_DRM_DP_MAX_RATE + 1] = {
> > + DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4,
> > + DP_LINK_BW_8_1, DP_LINK_RATE_TABLE
> > + };
>
> Please no. Read on for why.
>
> >
> > mutex_lock(>payload_lock);
> > mutex_lock(>lock);
> > @@ -3693,6 +3697,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
> > goto out_unlock;
> > }
> >
> > + if (mgr->max_source_rate < MAX_DRM_DP_MAX_RATE)
> > + mgr->dpcd[1] =
max_link_rate_tbl[mgr->max_source_rate];
>
> Make ->max_source_rate the actual physical rate in kHz, and use
> drm_dp_link_rate_to_bw_code() here.
>
> > +
> > mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
> > mgr->dpcd[2] &
DP_MAX_LANE_COUNT_MASK);
> > if (mgr->pbn_div == 0) {
> > @@ -5422,6 +5429,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
> > mgr->aux = aux;
> > mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
> > mgr->max_payloads = max_payloads;
> > + mgr->max_source_rate = MAX_DRM_DP_MAX_RATE;
> > mgr->conn_base_id = conn_base_id;
> > if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
> > max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 469e765a1b7b..a89b4c823123 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5392,6 +5392,13 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> > intel_dp->is_mst = sink_can_mst &&
> > i915->params.enable_dp_mst;
> >
> > + if (intel_dp_source_supports_hbr3(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR3;
> > + else if (intel_dp_source_supports_hbr2(intel_dp))
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR2;
> > + else
> > + intel_dp->mst_mgr.max_source_rate = DRM_DP_MAX_RATE_HBR;
>
> Whenever this file references a "rate", it's the rate in kHz. This is
> confusing. Use the rate in kHz.
>
> Also, please look at how intel_dp_source_supports_hbr* are implemented;
> we already have all the supported source rates cached in intel_dp.
>
> The max source rate is:
>
> intel_dp->source_rates[intel_dp->num_source_rates - 1].
>
> No need to do the if ladder here at all. If you like, you can add a
> helper:
>
> int intel_dp_max_source_rate(struct intel_dp *intel_dp)
> {
> return intel_dp->source_rates[intel_dp->num_source_rates - 1];
> }
>
> and reuse that in the supports_hbr* functions:
>
> bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
> {
> return intel_dp_max_source_rate(intel_dp) >= 54;
> }
>
> > +
> > drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> > intel_dp->is_mst);
> > }
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 6236f212da61..ef2b328469cd 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -183,6 +183,14 @@ struct drm_device;
> > #define DP_SUPPORTED_LINK_RATES 0x010 /* eDP 1.4 */
> > # define DP_MAX_SUPPORTED_RATES 8 /* 16-bit
little-endian */
> >
> > +enum drm_dp_max_link_rate {
> > + DRM_DP_MAX_RATE_RBR = 0,
> > + DRM_DP_MAX_RATE_HBR,
> > + DRM_DP_MAX_RATE_HBR2,
> > + DRM_DP_MAX_RATE_HBR3,
> > + MAX_DRM_DP_MAX_RATE
> > +};
>
> We already have 1) actual physical rates, in kHz, and 2) the DPCD rate
> codes, such as DP_LINK_BW_1_62.
>
> Do *not* add a third representation. Prefer kHz throughout, and convert
> to/from the DPCD codes near where they are needed.
>
> > +
> > /* Multiple stream transport */
> > #define DP_FAUX_CAP 0x020 /* 1.2 */
> > # define DP_FAUX_CAP_1 (1
[PATCH 1/2] dt-bindings: display: bridge: Add documentation for LT8912
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
.../display/bridge/lontium,lt8912.yaml| 92 +++
MAINTAINERS | 5 +
2 files changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
new file mode 100644
index ..ed1a6ddaab2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT8912 MIPI to HDMI Bridge
+
+maintainers:
+ - Adrien Grassein
+
+description: |
+ The LT8912 is a bridge device which convert DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt8912
+
+ reg:
+maxItems: 1
+
+ ddc-i2c-bus:
+maxItems: 1
+description: i2c bus used to read EDID of the connected display.
+
+ dsi-lanes:
+maxItems: 1
+description: dsi lanes count interconnected with lt8912.
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Primary MIPI port-1 for MIPI input
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - ddc-i2c-bus
+ - dsi-lanes
+ - reg
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@48 {
+compatible = "lontium,lt8912";
+reg = <0x48>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+dsi-lanes = <4>;
+ddc-i2c-bus = <_i2c_bus>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+
+hdmi_out_in: endpoint {
+ remote-endpoint = <_dsi_out>;
+};
+ };
+};
+ };
+};
+
+ddc_i2c_bus: i2c5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 5aa18cbfb883..01e7e356bfac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10472,6 +10472,11 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c
+LONTIUM LT8912 MIPI TO HDMI BRIDGE
+M: Adrien Grassein
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
M: Sreekanth Reddy
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting
On Sat, Jan 23, 2021 at 12:16:02AM +0800, Rob Herring wrote: > On Tue, Jan 12, 2021 at 2:57 AM Xin Ji wrote: > > > > Hi Rob Herring, thanks for the comments. > > > > On Mon, Jan 11, 2021 at 04:14:35PM -0600, Rob Herring wrote: > > > On Thu, Dec 31, 2020 at 10:21:12AM +0800, Xin Ji wrote: > > > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add > > > > swing setting for adjusting DP tx PHY swing > > > > > > > > Signed-off-by: Xin Ji > > > > --- > > > > .../bindings/display/bridge/analogix,anx7625.yaml | 25 > > > > -- > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > > > > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > > index 60585a4..4eb0ea3 100644 > > > > --- > > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > > +++ > > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > > > > @@ -34,6 +34,16 @@ properties: > > > > description: used for reset chip control, RESET_N pin B7. > > > > maxItems: 1 > > > > > > > > + analogix,swing-setting: > > > > +type: uint8-array > > > > > > Humm, this should have be rejected by the meta-schema. > > We needs define an array to adjust DP tx PHY swing, the developer hopes > > these > > settings are changeable, so I moved the register data to DT. Can you > > give me some suggestion if it is rejected by the meta-schema? > > > > > > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > > > > > This is how types are defined other than boolean or nodes (object). > > > > > > > +description: an array of swing register setting for DP tx PHY > > > > + > > > > + analogix,mipi-dpi-in: > > > > +type: int > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: indicate the MIPI rx signal type is DPI or DSI > > > > > > Why does this need to be in DT, you should be able to determine this > > > based on what you are connected to. > > As the anx7625 can receive MIPI DSI and DPI data (depends on hardware > > implement, we have a project which have two anx7625, one is DSI input, > > the other is DPI input), we needs to let driver know what kind of MIPI > > rx signal input. And there is no other way to tell driver the MIPI rx > > signal type, we needs define this flag. > > That's only true if what's driving the output is a single h/w block > that can drive either. But typically you have 2 blocks: an LCD > controller driving parallel signals and a DSI controller in front of > it doing parallel to DSI conversion. The anx7625 would be connected to > the LCD controller or DSI controller via the graph binding depending > on the h/w connection. > > However, if you do need this, then let's extend video-interfaces.yaml > 'bus-type' to include DSI (it already has parallel). > > Rob Hi Rob, thanks, I'll add 'bus-type' in the next version. Thanks, Xin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Generic USB Display driver
On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DSI/DPI display adapter. > > The reason for calling it 'Generic' is so anyone can make a USB > display/adapter against this driver, all that's needed is to add a USB > vid:pid. > > Unfortunately I've had some compounding health problems that have > severally limited the time I can spend in front of a computer. For this > reason I've decided to keep the gadget driver out-of-tree and focus on > getting the host driver merged first. > > See the wiki[1] for more information and images for the Raspberry Pi > Zero/4. > > One big change this time is that I've followed Peter Stuge's advice to > not let DRM stuff leak into the USB protocol. This has made the protocol > easier to understand just from reading the header file. > > Noralf. > > [1] https://github.com/notro/gud/wiki The patch set: Tested-by: Lubomir Rintel Works like a charm with this board [1], though it didn't impress the girls as much as I hoped. Code here [2], picture here [3]. [1] https://www.banggood.com/LILYGO-TTGO-T-Display-GD32-RISC-V-32-bit-Core-Minimal-Development-Board-1_14-IPS-p-1652870.html?rmmds=search_warehouse=CN [2] https://github.com/hackerspace/libopencm3-gf32v-examples/commit/7ef51b31b9 [3] https://people.freedesktop.org/~lkundrak/lilygo.jpeg Had to apply a fix for the drm_connector_enum_list[] ommission I mentioned elsewhere, and that I've now noticed you've noted previously. Take care Lubo > > > Noralf Trønnes (3): > drm/uapi: Add USB connector type > drm/probe-helper: Check epoch counter in output_poll_execute() > drm: Add Generic USB Display driver > > MAINTAINERS | 8 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/drm_probe_helper.c | 7 +- > drivers/gpu/drm/gud/Kconfig | 14 + > drivers/gpu/drm/gud/Makefile| 4 + > drivers/gpu/drm/gud/gud_connector.c | 722 > drivers/gpu/drm/gud/gud_drv.c | 620 > drivers/gpu/drm/gud/gud_internal.h | 148 ++ > drivers/gpu/drm/gud/gud_pipe.c | 472 ++ > include/drm/gud.h | 356 ++ > include/uapi/drm/drm_mode.h | 1 + > 12 files changed, 2354 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/gud/Kconfig > create mode 100644 drivers/gpu/drm/gud/Makefile > create mode 100644 drivers/gpu/drm/gud/gud_connector.c > create mode 100644 drivers/gpu/drm/gud/gud_drv.c > create mode 100644 drivers/gpu/drm/gud/gud_internal.h > create mode 100644 drivers/gpu/drm/gud/gud_pipe.c > create mode 100644 include/drm/gud.h > > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge
Lontium Lt8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912.c | 749
4 files changed, 765 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 01e7e356bfac..65fb19382e40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10476,6 +10476,7 @@ LONTIUM LT8912 MIPI TO HDMI BRIDGE
M: Adrien Grassein
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
+F: drivers/gpu/drm/bridge/lontium-lt8912.c
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..5b36d4b86e3c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,20 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT8912
+ tristate "Lontium LT8912 DSI/HDMI bridge"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT8912 DSI to HDMI bridge
+ chip driver.
+ Please say Y if you have such hardware.
+
+ Say M here if you want to support this hardware as a module.
+ The module will be named "lontium-lt8912".
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..5a1b201cea1f 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT8912) += lontium-lt8912.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912.c
b/drivers/gpu/drm/bridge/lontium-lt8912.c
new file mode 100644
index ..dd2ac92a5730
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt8912.c
@@ -0,0 +1,749 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define I2C_MAIN 0
+#define I2C_ADDR_MAIN 0x48
+
+#define I2C_CEC_DSI 1
+#define I2C_ADDR_CEC_DSI 0x49
+
+#define I2C_MAX_IDX 2
+
+#define HPD_WORK_DELAY_MS 1000
+
+struct lt8912 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_adapter *ddc;
+ struct i2c_client *i2c_client[I2C_MAX_IDX];
+ struct regmap *regmap[I2C_MAX_IDX];
+
+ struct device_node *host_node;
+ struct mipi_dsi_device *dsi;
+
+ struct gpio_desc *gp_reset;
+
+ struct videomode mode;
+
+ u8 dsi_lanes;
+ bool is_power_on;
+ bool is_attached;
+ bool cable_is_attached;
+
+ struct workqueue_struct *workq;
+ struct delayed_work lt8912_check_hpd_work_id;
+};
+
+static int lt8912_write_init_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ /* Digital clock en*/
+ {0x08, 0xff},
+ {0x09, 0xff},
+ {0x0a, 0xff},
+ {0x0b, 0x7c},
+ {0x0c, 0xff},
+ {0x42, 0x04},
+
+ /*Tx Analog*/
+ {0x31, 0xb1},
+ {0x32, 0xb1},
+ {0x33, 0x0e},
+ {0x37, 0x00},
+ {0x38, 0x22},
+ {0x60, 0x82},
+
+ /*Cbus Analog*/
+ {0x39, 0x45},
+ {0x3a, 0x00},
+ {0x3b, 0x00},
+
+ /*HDMI Pll Analog*/
+ {0x44, 0x31},
+ {0x55, 0x44},
+ {0x57, 0x01},
+ {0x5a, 0x02},
+
+ /*MIPI Analog*/
+ {0x3e, 0xd6},
+ {0x3f, 0xd4},
+ {0x41, 0x3c},
+ {0xB2, 0x00},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
ARRAY_SIZE(seq));
+}
+
+static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ {0x12, 0x04},
+ {0x14, 0x00},
+ {0x15, 0x00},
+ {0x1a, 0x03},
+ {0x1b, 0x03},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_CEC_DSI], seq,
ARRAY_SIZE(seq));
+};
[PATCH] drm/etnaviv: fix NULL check before some freeing functions is not needed
fixed the below warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index b390dd4..d741b1d 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(_obj->base, etnaviv_obj->sgt); } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbtft: add tearing signal detect
From: "carlis.zhang_cp"
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: carlis.zhang_cp
---
drivers/staging/fbtft/fb_st7789v.c | 133 -
drivers/staging/fbtft/fbtft.h | 1 +
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c
b/drivers/staging/fbtft/fb_st7789v.c
index 3a280cc..c687b58 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -9,9 +9,12 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
-
+#include
#include "fbtft.h"
#define DRVNAME "fb_st7789v"
@@ -66,6 +69,38 @@ enum st7789v_command {
#define MADCTL_MX BIT(6) /* bitmask for column address order */
#define MADCTL_MY BIT(7) /* bitmask for page address order */
+#define SPI_PANEL_TE_TIMEOUT 400
+static struct mutex te_mutex;/*mutex for tearing line*/
+static struct completion spi_panel_te;
+
+static irqreturn_t spi_panel_te_handler(int irq, void *data)
+{
+ complete(_panel_te);
+ return IRQ_HANDLED;
+}
+
+static void enable_spi_panel_te_irq(struct fbtft_par *par, bool enable)
+{
+ static int te_irq_count;
+
+ if (!par->gpio.te) {
+ pr_err("%s:%d,SPI panel TE GPIO not configured\n",
+ __func__, __LINE__);
+ return;
+ }
+
+ mutex_lock(_mutex);
+
+ if (enable) {
+ if (++te_irq_count == 1)
+ enable_irq(gpiod_to_irq(par->gpio.te));
+ } else {
+ if (--te_irq_count == 0)
+ disable_irq(gpiod_to_irq(par->gpio.te));
+ }
+ mutex_unlock(_mutex);
+}
+
/**
* init_display() - initialize the display controller
*
@@ -82,6 +117,28 @@ enum st7789v_command {
*/
static int init_display(struct fbtft_par *par)
{
+ int rc;
+ struct device *dev = par->info->device;
+
+ par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
+ if (par->gpio.te) {
+ init_completion(_panel_te);
+ mutex_init(_mutex);
+ rc = devm_request_irq(dev,
+ gpiod_to_irq(par->gpio.te),
+spi_panel_te_handler, IRQF_TRIGGER_RISING,
+"TE_GPIO", par);
+ if (rc) {
+ pr_err("TE request_irq failed.\n");
+ par->gpio.te = NULL;
+ } else {
+ disable_irq_nosync(gpiod_to_irq(par->gpio.te));
+ pr_err("TE request_irq completion.\n");
+ }
+ } else {
+ pr_err("%s:%d, TE gpio not specified\n",
+ __func__, __LINE__);
+ }
/* turn off sleep mode */
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
mdelay(120);
@@ -137,6 +194,9 @@ static int init_display(struct fbtft_par *par)
*/
write_reg(par, PWCTRL1, 0xA4, 0xA1);
+/*Tearing Effect Line On*/
+ if (par->gpio.te)
+ write_reg(par, 0x35, 0x00);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
if (HSD20_IPS)
@@ -145,6 +205,76 @@ static int init_display(struct fbtft_par *par)
return 0;
}
+/*
+ *
+ * int (*write_vmem)(struct fbtft_par *par);
+ *
+ */
+
+/* 16 bit pixel over 8-bit databus */
+int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
+{
+ u16 *vmem16;
+ __be16 *txbuf16 = par->txbuf.buf;
+ size_t remain;
+ size_t to_copy;
+ size_t tx_array_size;
+ int i;
+ int rc, ret = 0;
+ size_t startbyte_size = 0;
+
+ fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
len=%zu)\n",
+ __func__, offset, len);
+
+ remain = len / 2;
+ vmem16 = (u16 *)(par->info->screen_buffer + offset);
+
+ if (par->gpio.dc)
+ gpiod_set_value(par->gpio.dc, 1);
+
+ /* non buffered write */
+ if (!par->txbuf.buf)
+ return par->fbtftops.write(par, vmem16, len);
+
+ /* buffered write */
+ tx_array_size = par->txbuf.len / 2;
+
+ if (par->startbyte) {
+ txbuf16 = par->txbuf.buf + 1;
+ tx_array_size -= 2;
+ *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
+ startbyte_size = 1;
+ }
+
+ while (remain) {
+ to_copy = min(tx_array_size, remain);
+ dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
+ to_copy, remain - to_copy);
+
+ for (i = 0; i < to_copy; i++)
+ txbuf16[i] = cpu_to_be16(vmem16[i]);
+
+ vmem16 = vmem16 + to_copy;
+ if (par->gpio.te) {
+
[PATCH v2] fbtft: add tearing signal detect
From: "carlis.zhang_cp"
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: carlis.zhang_cp
---
v2:add release te gpio after irq request fail
---
drivers/staging/fbtft/fb_st7789v.c | 134 -
drivers/staging/fbtft/fbtft.h | 1 +
2 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c
b/drivers/staging/fbtft/fb_st7789v.c
index 3a280cc..5426276 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -9,9 +9,12 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
-
+#include
#include "fbtft.h"
#define DRVNAME "fb_st7789v"
@@ -66,6 +69,38 @@ enum st7789v_command {
#define MADCTL_MX BIT(6) /* bitmask for column address order */
#define MADCTL_MY BIT(7) /* bitmask for page address order */
+#define SPI_PANEL_TE_TIMEOUT 400
+static struct mutex te_mutex;/*mutex for tearing line*/
+static struct completion spi_panel_te;
+
+static irqreturn_t spi_panel_te_handler(int irq, void *data)
+{
+ complete(_panel_te);
+ return IRQ_HANDLED;
+}
+
+static void enable_spi_panel_te_irq(struct fbtft_par *par, bool enable)
+{
+ static int te_irq_count;
+
+ if (!par->gpio.te) {
+ pr_err("%s:%d,SPI panel TE GPIO not configured\n",
+ __func__, __LINE__);
+ return;
+ }
+
+ mutex_lock(_mutex);
+
+ if (enable) {
+ if (++te_irq_count == 1)
+ enable_irq(gpiod_to_irq(par->gpio.te));
+ } else {
+ if (--te_irq_count == 0)
+ disable_irq(gpiod_to_irq(par->gpio.te));
+ }
+ mutex_unlock(_mutex);
+}
+
/**
* init_display() - initialize the display controller
*
@@ -82,6 +117,29 @@ enum st7789v_command {
*/
static int init_display(struct fbtft_par *par)
{
+ int rc;
+ struct device *dev = par->info->device;
+
+ par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
+ if (par->gpio.te) {
+ init_completion(_panel_te);
+ mutex_init(_mutex);
+ rc = devm_request_irq(dev,
+ gpiod_to_irq(par->gpio.te),
+spi_panel_te_handler, IRQF_TRIGGER_RISING,
+"TE_GPIO", par);
+ if (rc) {
+ pr_err("TE request_irq failed.\n");
+ devm_gpiod_put(dev, par->gpio.te);
+ par->gpio.te = NULL;
+ } else {
+ disable_irq_nosync(gpiod_to_irq(par->gpio.te));
+ pr_info("TE request_irq completion.\n");
+ }
+ } else {
+ pr_err("%s:%d, TE gpio not specified\n",
+ __func__, __LINE__);
+ }
/* turn off sleep mode */
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
mdelay(120);
@@ -137,6 +195,9 @@ static int init_display(struct fbtft_par *par)
*/
write_reg(par, PWCTRL1, 0xA4, 0xA1);
+/*Tearing Effect Line On*/
+ if (par->gpio.te)
+ write_reg(par, 0x35, 0x00);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
if (HSD20_IPS)
@@ -145,6 +206,76 @@ static int init_display(struct fbtft_par *par)
return 0;
}
+/*
+ *
+ * int (*write_vmem)(struct fbtft_par *par);
+ *
+ */
+
+/* 16 bit pixel over 8-bit databus */
+int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
+{
+ u16 *vmem16;
+ __be16 *txbuf16 = par->txbuf.buf;
+ size_t remain;
+ size_t to_copy;
+ size_t tx_array_size;
+ int i;
+ int rc, ret = 0;
+ size_t startbyte_size = 0;
+
+ fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
len=%zu)\n",
+ __func__, offset, len);
+
+ remain = len / 2;
+ vmem16 = (u16 *)(par->info->screen_buffer + offset);
+
+ if (par->gpio.dc)
+ gpiod_set_value(par->gpio.dc, 1);
+
+ /* non buffered write */
+ if (!par->txbuf.buf)
+ return par->fbtftops.write(par, vmem16, len);
+
+ /* buffered write */
+ tx_array_size = par->txbuf.len / 2;
+
+ if (par->startbyte) {
+ txbuf16 = par->txbuf.buf + 1;
+ tx_array_size -= 2;
+ *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
+ startbyte_size = 1;
+ }
+
+ while (remain) {
+ to_copy = min(tx_array_size, remain);
+ dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
+ to_copy, remain - to_copy);
+
+ for (i = 0; i < to_copy; i++)
+ txbuf16[i] =
[PATCH 1/2] dt-bindings: display: bridge: Add documentation for LT8912
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
.../display/bridge/lontium,lt8912.yaml| 92 +++
MAINTAINERS | 5 +
2 files changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
new file mode 100644
index ..ed1a6ddaab2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT8912 MIPI to HDMI Bridge
+
+maintainers:
+ - Adrien Grassein
+
+description: |
+ The LT8912 is a bridge device which convert DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt8912
+
+ reg:
+maxItems: 1
+
+ ddc-i2c-bus:
+maxItems: 1
+description: i2c bus used to read EDID of the connected display.
+
+ dsi-lanes:
+maxItems: 1
+description: dsi lanes count interconnected with lt8912.
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Primary MIPI port-1 for MIPI input
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - ddc-i2c-bus
+ - dsi-lanes
+ - reg
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@48 {
+compatible = "lontium,lt8912";
+reg = <0x48>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+dsi-lanes = <4>;
+ddc-i2c-bus = <_i2c_bus>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+
+hdmi_out_in: endpoint {
+ remote-endpoint = <_dsi_out>;
+};
+ };
+};
+ };
+};
+
+ddc_i2c_bus: i2c5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 5aa18cbfb883..01e7e356bfac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10472,6 +10472,11 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c
+LONTIUM LT8912 MIPI TO HDMI BRIDGE
+M: Adrien Grassein
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
M: Sreekanth Reddy
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
