[Bug 110214] amdgpu: xterm scrollback buffer disappears while paging up/down
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #10 from Diego Viola --- My issue looks quite similar to this one: https://bugs.openbsd.narkive.com/N7A1v1Cw/colored-text-disappears-in-xterm -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/selftests: Fix an IS_ERR() vs NULL check
The live_context() function returns error pointers. It never returns
NULL.
Fixes: 9c1477e83e62 ("drm/i915/selftests: Exercise adding requests to a full
GGTT")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 9a9451846b33..89766688e420 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -455,7 +455,7 @@ static int igt_evict_contexts(void *arg)
struct i915_gem_context *ctx;
ctx = live_context(i915, file);
- if (!ctx)
+ if (IS_ERR(ctx))
break;
/* We will need some GGTT space for the rq's context */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] amdgpu: xterm scrollback buffer disappears while paging up/down
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #9 from Diego Viola --- I also get the same issue if I run xterm from sway/weston (via xwayland). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] amdgpu: xterm scrollback buffer disappears while paging up/down
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #8 from Diego Viola --- I've compiled mesa from git and the issue is still there, I also tried older releases like 18.3, 18.2 and the issue remains. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapdrm: hdmi4_cec: Fix CEC clock handling for PM
Hi Tony,
Thank you for the patch.
On Mon, Mar 25, 2019 at 04:47:43PM -0700, Tony Lindgren wrote:
> If CONFIG_OMAP4_DSS_HDMI_CEC is enabled in .config, deeper SoC idle
> states are blocked because the CEC clock gets always enabled on init.
>
> Let's fix the issue by moving the CEC clock handling to happen later in
> hdmi_cec_adap_enable() as suggested by Hans Verkuil .
> This way the CEC clock gets only enabled when needed. This can be tested
> by doing cec-ctl --playback to enable the CEC, and doing cec-ctl --clear
> to disable it.
>
> Let's also fix the typo for "divider" in the comments while at it.
>
> Fixes: 8d7f934df8d8 ("omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support")
> Suggested-by: Hans Verkuil
> Cc: Hans Verkuil
> Cc: Jyri Sarha
> Cc: Laurent Pinchart
> Signed-off-by: Tony Lindgren
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> @@ -169,12 +169,19 @@ static int hdmi_cec_adap_enable(struct cec_adapter
> *adap, bool enable)
> struct hdmi_core_data *core = cec_get_drvdata(adap);
> int temp, err;
>
> - if (!enable) {
> + if (enable) {
> + /*
> + * Initialize CEC clock divider: CEC needs 2MHz clock hence
> + * set the divider to 24 to get 48/24=2MHz clock
> + */
> + REG_FLD_MOD(core->wp->base, HDMI_WP_CLK, 0x18, 5, 0);
> + } else {
> hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_0, 0);
> hdmi_write_reg(core->base, HDMI_CEC_INT_ENABLE_1, 0);
> REG_FLD_MOD(core->base, HDMI_CORE_SYS_INTR_UNMASK4, 0, 3, 3);
> hdmi_wp_clear_irqenable(core->wp, HDMI_IRQ_CORE);
> hdmi_wp_set_irqstatus(core->wp, HDMI_IRQ_CORE);
> + REG_FLD_MOD(core->wp->base, HDMI_WP_CLK, 0, 5, 0);
> hdmi4_core_disable(core);
> return 0;
> }
> @@ -333,11 +340,8 @@ int hdmi4_cec_init(struct platform_device *pdev, struct
> hdmi_core_data *core,
> return ret;
> core->wp = wp;
>
> - /*
> - * Initialize CEC clock divider: CEC needs 2MHz clock hence
> - * set the devider to 24 to get 48/24=2MHz clock
> - */
> - REG_FLD_MOD(core->wp->base, HDMI_WP_CLK, 0x18, 5, 0);
> + /* Disable clock initially, hdmi_cec_adap_enable() manages it */
> + REG_FLD_MOD(core->wp->base, HDMI_WP_CLK, 0, 5, 0);
>
> ret = cec_register_adapter(core->adap, >dev);
> if (ret < 0) {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/nouveau/fb/ram/gk104: move assignment out of condition
"hiding" unconditional assignments in the if() parentesis makes for
hard to read code and has no advantage over placing these assignments
in proper formated lines before the if() statement. Simply move those
lines out.
Before sending out roughly 20 patches to fix the roughly 50 cases - all
in the nouveau driver. I would like to know if this will be accepted at
all.
Signed-off-by: Nicholas Mc Guire
---
Problem located by and experiemental coccinelle script.
Note that the last hunk retained the if (i == 0) rather than switching
to a more consistent if (!i) - but then again the code is not really
consistent on that - so not sure if that should be done or not.
Cocciscript to generate the appropriate patches - note though that it
will *not* remove excess parentesis where these are present in the
current code:
/// Check for unconditional code "hiding" in an if condition
/// effectively that code is unconditionally executed before
/// reaching the actual branch statement - which just makes it
/// hard to read and thus is always wrong.
/// Some of the cases found also look buggy
/// In other cases some excess () are left in place in the
/// generated patches - so some postprocessing may be needed.
///
/// As of 5.0-rc8 all 50 cases look like they are found and fixed
/// correctly - correctly only in the sense that the patched
/// code is equivalent to the original code. but as this is in
/// the nouveau driver only it might well be that this only
/// fits that specific pattern and others might have wilder ways
/// to achieve the same level of confusing code- so confidence
/// Low for now (though the the nouveau cases all are patched
/// correctly)
///
// Copyright: (C) 2019 Nicholas Mc Guire. GPL-V2.
// Confidence: Low
// Comments:
// Options: --no-includes --include-headers
virtual patch
virtual report
@badif@
position p;
statement S;
expression E1,E2;
@@
if@p (E1,E2) S
@script:python depends on report@
p << badif.p;
@@
msg = "unconditional code hiding in if condition"
coccilib.report.print_report(p[0],msg)
@fixbadif depends on badif && patch@
position p=badif.p;
statement S;
expression E1=badif.E1,E2=badif.E2;
@@
+ E1;
if@p (
- E1,
E2)
S
@script:python depends on patch@
p << fixbadif.p;
@@
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 42 +++
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 8bcb7e7..885c24d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
@@ -1168,7 +1168,8 @@ gk104_ram_prog_0(struct gk104_ram *ram, u32 freq)
if (>head == >cfg)
return;
- if (mask = 0, data = 0, ram->diff.rammap_11_0a_03fe) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0a_03fe) {
data |= cfg->bios.rammap_11_0a_03fe << 12;
mask |= 0x001ff000;
}
@@ -1178,31 +1179,36 @@ gk104_ram_prog_0(struct gk104_ram *ram, u32 freq)
}
nvkm_mask(device, 0x10f468, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0a_0400) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0a_0400) {
data |= cfg->bios.rammap_11_0a_0400;
mask |= 0x0001;
}
nvkm_mask(device, 0x10f420, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0a_0800) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0a_0800) {
data |= cfg->bios.rammap_11_0a_0800;
mask |= 0x0001;
}
nvkm_mask(device, 0x10f430, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0b_01f0) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0b_01f0) {
data |= cfg->bios.rammap_11_0b_01f0;
mask |= 0x001f;
}
nvkm_mask(device, 0x10f400, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0b_0200) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0b_0200) {
data |= cfg->bios.rammap_11_0b_0200 << 9;
mask |= 0x0200;
}
nvkm_mask(device, 0x10f410, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0d) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0d) {
data |= cfg->bios.rammap_11_0d << 16;
mask |= 0x00ff;
}
@@ -1212,7 +1218,8 @@ gk104_ram_prog_0(struct gk104_ram *ram, u32 freq)
}
nvkm_mask(device, 0x10f440, mask, data);
- if (mask = 0, data = 0, ram->diff.rammap_11_0e) {
+ mask = 0, data = 0;
+ if (ram->diff.rammap_11_0e) {
data |= cfg->bios.rammap_11_0e << 8;
mask |= 0xff00;
}
@@ -1453,17 +1460,21 @@ gk104_ram_ctor_data(struct gk104_ram *ram, u8 ramcfg,
int i)
/* memory config data for a range of target
[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #4 from Laurent --- Heu no, not a list, but a counter, sorry. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 08/17] kunit: test: add support for test abort
On Fri, Mar 22, 2019 at 12:11 AM Knut Omang wrote: > > On Thu, 2019-03-21 at 18:41 -0700, Brendan Higgins wrote: > > On Thu, Mar 21, 2019 at 6:10 PM Frank Rowand wrote: > > > On 2/27/19 11:42 PM, Brendan Higgins wrote: > > > > On Tue, Feb 19, 2019 at 10:44 PM Frank Rowand > > > > wrote: > > > > > On 2/19/19 7:39 PM, Brendan Higgins wrote: > > > > > > On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand > > > > > > > > > > > > wrote: > > > > > > > On 2/14/19 1:37 PM, Brendan Higgins wrote: < snip > > > > > > > > kunit_abort() is what will be call as the result of an assert > > > > > > > failure. > > > > > > > > > > > > Yep. Does that need clarified somewhere. > > > > > > > BUG(), which is a panic, which is crashing the system is not > > > > > > > acceptable > > > > > > > in the Linux kernel. You will just annoy Linus if you submit > > > > > > > this. > > > > > > > > > > > > Sorry, I thought this was an acceptable use case since, a) this > > > > > > should > > > > > > never be compiled in a production kernel, b) we are in a pretty bad, > > > > > > unpredictable state if we get here and keep going. I think you might > > > > > > have said elsewhere that you think "a" is not valid? In any case, I > > > > > > can replace this with a WARN, would that be acceptable? > > > > > > > > > > A WARN may or may not make sense, depending on the context. It may > > > > > be sufficient to simply report a test failure (as in the old version > > > > > of case (2) below. > > > > > > > > > > Answers to "a)" and "b)": > > > > > > > > > > a) it might be in a production kernel > > > > > > > > Sorry for a possibly stupid question, how might it be so? Why would > > > > someone intentionally build unit tests into a production kernel? > > > > > > People do things. Just expect it. > > > > Huh, alright. I will take your word for it then. > > I have a better explanation: Production kernels have bugs, unfortunately. > And sometimes those need to be investigated on systems than cannot be > brought down or affected more than absolutely necessary, maybe via a third > party > doing the execution. A light weight, precise test (well tested ahead :) ) > might > be a way of proving or disproving assumptions that can lead to the development > and application of a fix. Sorry, you are not suggesting testing in production are you? To be clear, I am not concerned about someone using testing, KUnit, or whatever in a *production-like* environment: that's not what we are talking about here. My assumption is that no one will deploy tests into actual production. > > IMHO you're confusing "building into" with temporary applying, then removing > again - like the difference between running a local user space program vs > installing it under /usr and have it in everyone's PATH. I don't really see the point of distinguishing between "building into" and "temporary applying" in this case; that's part of my point. Maybe it makes sense in whitebox end-to-end testing, but in the case of unit testing, I don't think so. > > > > > > a') it is not acceptable in my development kernel either > > I think one of the fundamental properties of a good test framework is that it > should not require changes to the code under test by itself. > Sure, but that has nothing to do with the environment the code/tests are running in. < snip > Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 14/20] drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages
On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> amdgpu_ttm_tt_get_user_pages() uses provided user pointers for vma
> lookups, which can only by done with untagged pointers.
>
> Untag user pointers in this function.
>
> Signed-off-by: Andrey Konovalov
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 73e71e61dc99..891b027fa33b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -751,10 +751,11 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm,
> struct page **pages)
>* check that we only use anonymous memory to prevent problems
>* with writeback
>*/
> - unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
> + unsigned long userptr = untagged_addr(gtt->userptr);
> + unsigned long end = userptr + ttm->num_pages * PAGE_SIZE;
> struct vm_area_struct *vma;
>
> - vma = find_vma(mm, gtt->userptr);
> + vma = find_vma(mm, userptr);
> if (!vma || vma->vm_file || vma->vm_end < end) {
> up_read(>mmap_sem);
> return -EPERM;
We'll need to be careful that we don't break your change when the
following commit gets applied through drm-next for Linux 5.2:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=915d3eecfa23693bac9e54cdacf84fb4efdcc5c4
Would it make sense to apply the untagging in amdgpu_ttm_tt_set_userptr
instead? That would avoid this conflict and I think it would clearly put
the untagging into the user mode code path where the tagged pointer
originates.
In amdgpu_gem_userptr_ioctl and amdgpu_amdkfd_gpuvm.c (init_user_pages)
we also set up an MMU notifier with the (tagged) pointer from user mode.
That should probably also use the untagged address so that MMU notifiers
for the untagged address get correctly matched up with the right BO. I'd
move the untagging further up the call stack to cover that. For the GEM
case I think amdgpu_gem_userptr_ioctl would be the right place. For the
KFD case, I'd do this in amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu.
Regards,
Felix
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest
On Thu, Mar 21, 2019 at 6:34 PM Frank Rowand wrote: > > On 3/21/19 5:22 PM, Frank Rowand wrote: > > On 2/27/19 7:52 PM, Brendan Higgins wrote: > > < snip > > > >> Now I know that, hermeticity especially, but other features as well > >> (test suite summary, error on unused test case function, etc) are not > >> actually in KUnit as it is under consideration here. Maybe it would be > >> best to save these last two patches (18/19, and 19/19) until I have > >> these other features checked in and reconsider them then? > > > > Thanks for leaving 18/19 and 19/19 off in v4. > > Oops, they got into v4 but as 16/17 and 17/17, I think. But it sounds > like you are planning to leave them out of v5. Oh, I thought you meant v5 when you were thanking me. In any case, to confirm, I will be leaving off 16/17, and 17/17 in the next version. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest
On Thu, Mar 21, 2019 at 6:47 PM Frank Rowand wrote: > > On 3/21/19 6:30 PM, Brendan Higgins wrote: > > On Thu, Mar 21, 2019 at 5:22 PM Frank Rowand wrote: > >> > >> On 2/27/19 7:52 PM, Brendan Higgins wrote: > > < snip > but thanks for the comments in the snipped section. > > > >> > >> Thanks for leaving 18/19 and 19/19 off in v4. > > > > Sure, no problem. It was pretty clear that it was a waste of both of > > our times to continue discussing those at this juncture. :-) > > > > Do you still want me to try to convert the DT not-exactly-unittest to > > KUnit? I would kind of prefer (I don't feel *super* strongly about the > > matter) we don't call it that since I was intending for it to be the > > flagship initial example, but I certainly don't mind trying to clean > > this patch up to get it up to snuff. It's really just a question of > > whether it is worth it to you. > > In the long term, if KUnit is adopted by the kernel, then I think it > probably makes sense for devicetree unittest to convert from using > our own unittest() function to report an individual test pass/fail > to instead use something like KUNIT_EXPECT_*() to provide more > consistent test messages to test frameworks. That is assuming > KUNIT_EXPECT_*() provides comparable functionality. I still have > not looked into that question since the converted tests (patch 15/17 > in v4) still does not execute without throwing internal errors. Sounds good. > > If that conversion occurred, I would also avoid the ASSERTs. Noted. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, Mar 21, 2019 at 6:12 PM Frank Rowand wrote: > > On 3/21/19 4:33 PM, Brendan Higgins wrote: > > On Thu, Mar 21, 2019 at 3:27 PM Logan Gunthorpe wrote: > >> > >> > >> > >> On 2019-03-21 4:07 p.m., Brendan Higgins wrote: > >>> A couple of points, as for needing CONFIG_PCI; my plan to deal with > >>> that type of thing has been that we would add support for a KUnit/UML > >>> version that is just for KUnit. It would mock out the necessary bits > >>> to provide a fake hardware implementation for anything that might > >>> depend on it. I wrote a prototype for mocking/faking MMIO that I > >>> presented to the list here[1]; it is not part of the current patchset > >>> because we decided it would be best to focus on getting an MVP in, but > >>> I plan on bringing it back up at some point. Anyway, what do you > >>> generally think of this approach? > >> > >> Yes, I was wondering if that might be possible. I think that's a great > >> approach but it will unfortunately take a lot of work before larger > >> swaths of the kernel are testable in Kunit with UML. Having more common > >> mocked infrastructure will be great by-product of it though. > > > > Yeah, it's unfortunate that the best way to do something often takes > > so much longer. > > > >> > >>> Awesome, I looked at the code you posted and it doesn't look like you > >>> have had too many troubles. One thing that stood out to me, why did > >>> you need to put it in the kunit/ dir? > >> > >> Yeah, writing the code was super easy. Only after, did I realized I > >> couldn't get it to easily build. > > > > Yeah, we really need to fix that; unfortunately, broadly addressing > > that problem is really hard and will most likely take a long time. > > > >> > >> Putting it in the kunit directory was necessary because nothing in the > >> NTB tree builds unless CONFIG_NTB is set (see drivers/Makefile) and > >> CONFIG_NTB depends on CONFIG_PCI. I didn't experiment to see how hard it > >> would be to set CONFIG_NTB without CONFIG_PCI; I assumed it would be > >> tricky. > >> > >>> I am looking forward to see what you think! > >> > >> Generally, I'm impressed and want to see this work in upstream as soon > >> as possible so I can start to make use of it! > > > > Great to hear! I was trying to get the next revision out this week, > > but addressing some of the comments is taking a little longer than > > expected. I should have something together fairly soon though > > (hopefully next week). Good news is that next revision will be > > non-RFC; most of the feedback has settled down and I think we are > > ready to start figuring out how to merge it. Fingers crossed :-) > > > > Cheers > > I'll be out of the office next week and will not be able to review. > Please hold off on any devicetree related files until after I review. Will do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, Mar 21, 2019 at 6:23 PM Frank Rowand wrote: > > On 3/4/19 3:01 PM, Brendan Higgins wrote: > > On Thu, Feb 14, 2019 at 1:38 PM Brendan Higgins < snip > > > Someone suggested I should send the next revision out as "PATCH" > > instead of "RFC" since there seems to be general consensus about > > everything at a high level, with a couple exceptions. > > > > At this time I am planning on sending the next revision out as "[PATCH > > v1 00/NN] kunit: introduce KUnit, the Linux kernel unit testing > > framework". Initially I wasn't sure if the next revision should be > > "[PATCH v1 ...]" or "[PATCH v5 ...]". Please let me know if you have a > > strong objection to the former. > > > > In the next revision, I will be dropping the last two of three patches > > for the DT unit tests as there doesn't seem to be enough features > > currently available to justify the heavy refactoring I did; however, I > > Thank you. > > > > will still include the patch that just converts everything over to > > KUnit without restructuring the test cases: > > https://lkml.org/lkml/2019/2/14/1133 > > The link doesn't work for me (don't worry about that), so I'm assuming > this is: > >[RFC v4 15/17] of: unittest: migrate tests to run on KUnit That's correct. > > The conversation on that patch ended after: > >>> After adding patch 15, there are a lot of "unittest internal error" > messages. >> >> Yeah, I meant to ask you about that. I thought it was due to a change >> you made, but after further examination, just now, I found it was my >> fault. Sorry for not mentioning that anywhere. I will fix it in v5. > > It is not worth my time to look at patch 15 when it is that broken. So I > have not done any review of it. Right, I didn't expect you to, we were still discussing things on RFC v3 at the time. I think I got you comments on v3 in a very short time frame around sending out v4; hence why your comments were not addressed. > > So no, I think you are still in the RFC stage unless you drop patch 15. Noted. I might split that out into a separate RFC then. > > > > > I should have the next revision out in a week or so. > > > Cheers! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, Mar 21, 2019 at 5:28 PM Frank Rowand wrote: > > On 12/5/18 3:10 PM, Brendan Higgins wrote: > > On Tue, Dec 4, 2018 at 5:49 AM Rob Herring wrote: > >> > >> On Tue, Dec 4, 2018 at 5:40 AM Frank Rowand wrote: > >>> > >>> Hi Brendan, Rob, > >>> > >>> Pulling a comment from way back in the v1 patch thread: > >>> > >>> On 10/17/18 3:22 PM, Brendan Higgins wrote: > On Wed, Oct 17, 2018 at 10:49 AM wrote: > >>> > >>> < snip > > >>> > The test and the code under test are linked together in the same > binary and are compiled under Kbuild. Right now I am linking > everything into a UML kernel, but I would ultimately like to make > tests compile into completely independent test binaries. So each test > file would get compiled into its own test binary and would link > against only the code needed to run the test, but we are a bit of a > ways off from that. > >>> > >>> I have never used UML, so you should expect naive questions from me, > >>> exhibiting my lack of understanding. > >>> > >>> Does this mean that I have to build a UML architecture kernel to run > >>> the KUnit tests? > >> > >> In this version of the patch series, yes. > >> > >>> *** Rob, if the answer is yes, then it seems like for my workflow, > >>> which is to build for real ARM hardware, my work is doubled (or > >>> worse), because for every patch/commit that I apply, I not only have > >>> to build the ARM kernel and boot on the real hardware to test, I also > >>> have to build the UML kernel and boot in UML. If that is correct > >>> then I see this as a major problem for me. > >> > >> I've already raised this issue elsewhere in the series. Restricting > >> the DT tests to UML is a non-starter. > > > > > I have already stated my position elsewhere on the matter, but in > > summary: Ensuring most tests can run without external dependencies > > (hardware, VM, etc) has a lot of benefits and should be supported in > > nearly all cases, but such tests should also work when compiled to run > > on real hardware/VM; the tooling might not be as good in the latter > > case, but I understand that there are good reasons to support it > > nonetheless. > > And my needs are the exact opposite. My tests must run on real hardware, > in the context of the real operating system subsystems and drivers > potentially causing issues. Right, Rob pointed this out, and I fixed this in v4. To be clear, as of RFC v4 you can run KUnit tests on non-UML architectures, we tested it on x86 and ARM. > > It is useful if the tests can also run without that dependency. This, of course, is still the main intended use case, but there is nothing to stop you from using it on real hardware. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/3] dma-buf: give each buffer a full-fledged inode
In the original userspace implementation Greg wrote, he was iterating the directory entries in proc//map_files, doing readlink() on each to find out whether the entry was a dmabuf. This turned out to be very slow so we reworked it to parse proc//maps instead. On Mon, Mar 25, 2019 at 12:35 PM Chenbo Feng wrote: > > On Sun, Mar 24, 2019 at 1:45 PM Joel Fernandes wrote: > > > > Hi Sandeep, > > > > On Sun, Mar 24, 2019 at 10:56:33AM -0700, Sandeep Patil wrote: > > > On Fri, Mar 22, 2019 at 11:02:55AM -0400, Joel Fernandes wrote: > > > > On Thu, Mar 21, 2019 at 07:51:33PM -0700, Chenbo Feng wrote: > > > > > From: Greg Hackmann > > > > > > > > > > By traversing /proc/*/fd and /proc/*/map_files, processes with > > > > > CAP_ADMIN > > > > > can get a lot of fine-grained data about how shmem buffers are shared > > > > > among processes. stat(2) on each entry gives the caller a unique > > > > > ID (st_ino), the buffer's size (st_size), and even the number of pages > > > > > currently charged to the buffer (st_blocks / 512). > > > > > > > > > > In contrast, all dma-bufs share the same anonymous inode. So while we > > > > > can count how many dma-buf fds or mappings a process has, we can't get > > > > > the size of the backing buffers or tell if two entries point to the > > > > > same > > > > > dma-buf. On systems with debugfs, we can get a per-buffer breakdown > > > > > of > > > > > size and reference count, but can't tell which processes are actually > > > > > holding the references to each buffer. > > > > > > > > > > Replace the singleton inode with full-fledged inodes allocated by > > > > > alloc_anon_inode(). This involves creating and mounting a > > > > > mini-pseudo-filesystem for dma-buf, following the example in fs/aio.c. > > > > > > > > > > Signed-off-by: Greg Hackmann > > > > > > > > I believe Greg's address needs to be updated on this patch otherwise the > > > > emails would just bounce, no? I removed it from the CC list. You can > > > > still > > > > keep the SOB I guess but remove it from the CC list when sending. > > > > > > > > Also about the minifs, just playing devil's advocate for why this is > > > > needed. > > > > > > > > Since you are already adding the size information to > > > > /proc/pid/fdinfo/ , > > > > can just that not be used to get the size of the buffer? What is the > > > > benefit > > > > of getting this from stat? The other way to get the size would be > > > > through > > > > another IOCTL and that can be used to return other unique-ness related > > > > metadata > > > > as well. Neither of these need creation of a dedicated inode per > > > > dmabuf. > > > > > > Can you give an example of "unique-ness related data" here? The inode > > > seems > > > like the best fit cause its already unique, no? > > > > I was thinking dma_buf file pointer, but I agree we need the per-inode now > > (see below). > > > > > > Also what is the benefit of having st_blocks from stat? AFAIK, that is > > > > the > > > > same as the buffer's size which does not change for the lifetime of the > > > > buffer. In your patch you're doing this when 'struct file' is created > > > > which > > > > AIUI is what reflects in the st_blocks: > > > > + inode_set_bytes(inode, dmabuf->size); > > > > > > Can some of the use cases / data be trimmed down? I think so. For > > > example, I > > > never understood what we do with map_files here (or why). It is perfectly > > > fine to just get the data from /proc//fd and /proc//maps. I > > > guess > > > the map_files bit is for consistency? > > > > It just occured to me that since /proc/ > one of the fields, so indeed an inode per buf is a very good idea for the > > user to distinguish buffers just by reading /proc/ alone.. > > > > I also, similar to you, don't think map_files is useful for this usecase. > > map_files are just symlinks named as memory ranges and pointing to a file. > > In > > this case the symlink will point to default name "dmabuf" that doesn't > > exist. > > If one does stat(2) on a map_file link, then it just returns the inode > > number > > of the symlink, not what the map_file is pointing to, which seems kind of > > useless. > > > I might be wrong but I don't think we did anything special for the > map_files in this patch. I think the confusion might be from commit > message where Greg mentioned the map_files to describe the behavior of > shmem buffer when comparing it with dma-buf. The file system > implementation and the file allocation action in this patch are just > some minimal effort to associate each dma_buf object with an inode and > properly populate the size information in the file object. And we > didn't use proc/pid/map_files at all in the android implementation > indeed. > > > > Which makes me think both maps and map_files can be made more useful if we > > can > > also make DMA_BUF_SET_NAME in the patch change the underlying dentry's name > > from the default "dmabuf" to "dmabuf:" ? > > > > That would be useful
Re: [PATCH 1/2] dt-bindings: display: Add ETM0430G0DH6 bindings
On Tue, 19 Feb 2019 15:04:37 +0100, Marek Vasut wrote: > Document the Emerging Display Technology Corp. (EDT) ETM0430G0DH6 > display, which is a 480x272 4.3" TFT display. > > Signed-off-by: Marek Vasut > Cc: Rob Herring > Cc: Jan Tuerk > Cc: Thierry Reding > Cc: devicet...@vger.kernel.org > --- > .../devicetree/bindings/display/panel/edt,et-series.txt | 8 > 1 file changed, 8 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #3 from Laurent --- I've more information about the bug and I've an idea of how to fix it. It seems that the window content is updated each time one x,y pixel is drawn but several pixels can be drawn at a same window position at the same time. The solution is to make a list of each pixels to drawn, withdraw the pixel of the list once it's drawn and update the window content once the list is empty. The picture here show the problem, only the first color of my per-pixel linked list is drawn (red). Or the color os the second sprite is green and the color of the third srite is blue.Si it should blend red pixels with green pixels and then green pixels with blue pixels or it only blend the first pixel color of the linked list : (Even with a call to the memory barrier function which have to wait, until all subsequent writes have finished) https://image.noelshack.com/fichiers/2019/13/1/1553549295-capture-d-ecran-de-2019-03-25-01-44-31.png Now I've to check where I have to put this code onto source code files but it's not easy because there are a lot of files, and the recompile the driver. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/2] dt-bindings: drm/panel: simple: Add binding for TFC S9700RTWV43TR-01B
On Fri, 22 Mar 2019 10:33:35 +0200, Jyri Sarha wrote: > Add bindign for TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD > panel with resistive touch. > > The panel is found on TI AM335x-evm. > > Signed-off-by: Jyri Sarha > --- > .../display/panel/tfc,s9700rtwv43tr-01b.txt | 15 +++ > .../devicetree/bindings/vendor-prefixes.txt | 1 + > 2 files changed, 16 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #20 from Utku Helvacı (tuxutku) --- (In reply to tme from comment #15) > I've been attempting to perform a bisect on an off for a while now with no > success. The main problem I'm running into is this error when trying to > compile. > > RELOCS arch/x86/boot/compressed/vmlinux.relocs > Unsupported relocation type: R_X86_64_PLT32 (4) > make[4]: *** [arch/x86/boot/compressed/Makefile:123: > arch/x86/boot/compressed/vmlinux.relocs] Error 1 > make[3]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] > Error 2 > make[2]: *** [arch/x86/Makefile:299: bzImage] Error 2 > make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2 > make: *** [Makefile:1386: bindeb-pkg] Error 2 > > I've tried searching for solutions for this problem, but I haven't found > anything. It occurs when I run "make -j4 deb-pkg" and "make bzImage". If > anyone can help me solve this, I'd be happy to start bisecting again. Hey i am bisecting the same commits for another problem and i am getting the same error: https://bugzilla.kernel.org/show_bug.cgi?id=201077#c26 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver
On Tue, Mar 19, 2019 at 02:53:55PM -0700, sonal.san...@xilinx.com wrote: > From: Sonal Santan > > Hello, > > This patch series adds drivers for Xilinx Alveo PCIe accelerator cards. > These drivers are part of Xilinx Runtime (XRT) open source stack and > have been deployed by leading FaaS vendors and many enterprise customers. Cool, first fpga driver submitted to drm! And from a high level I think this makes a lot of sense. > PLATFORM ARCHITECTURE > > Alveo PCIe platforms have a static shell and a reconfigurable (dynamic) > region. The shell is automatically loaded from PROM when host is booted > and PCIe is enumerated by BIOS. Shell cannot be changed till next cold > reboot. The shell exposes two physical functions: management physical > function and user physical function. > > Users compile their high level design in C/C++/OpenCL or RTL into FPGA > image using SDx compiler. The FPGA image packaged as xclbin file can be > loaded onto reconfigurable region. The image may contain one or more > compute unit. Users can dynamically swap the full image running on the > reconfigurable region in order to switch between different workloads. > > XRT DRIVERS > > XRT Linux kernel driver xmgmt binds to mgmt pf. The driver is modular and > organized into several platform drivers which primarily handle the > following functionality: > 1. ICAP programming (FPGA bitstream download with FPGA Mgr integration) > 2. Clock scaling > 3. Loading firmware container also called dsabin (embedded Microblaze > firmware for ERT and XMC, optional clearing bitstream) > 4. In-band sensors: temp, voltage, power, etc. > 5. AXI Firewall management > 6. Device reset and rescan > 7. Hardware mailbox for communication between two physical functions > > XRT Linux kernel driver xocl binds to user pf. Like its peer, this driver > is also modular and organized into several platform drivers which handle > the following functionality: > 1. Device memory topology discovery and memory management > 2. Buffer object abstraction and management for client process > 3. XDMA MM PCIe DMA engine programming > 4. Multi-process aware context management > 5. Compute unit execution management (optionally with help of ERT) for > client processes > 6. Hardware mailbox for communication between two physical functions > > The drivers export ioctls and sysfs nodes for various services. xocl > driver makes heavy use of DRM GEM features for device memory management, > reference counting, mmap support and export/import. xocl also includes a > simple scheduler called KDS which schedules compute units and interacts > with hardware scheduler running ERT firmware. The scheduler understands > custom opcodes packaged into command objects and provides an asynchronous > command done notification via POSIX poll. > > More details on architecture, software APIs, ioctl definitions, execution > model, etc. is available as Sphinx documentation-- > > https://xilinx.github.io/XRT/2018.3/html/index.html > > The complete runtime software stack (XRT) which includes out of tree > kernel drivers, user space libraries, board utilities and firmware for > the hardware scheduler is open source and available at > https://github.com/Xilinx/XRT Before digging into the implementation side more I looked into the userspace here. I admit I got lost a bit, since there's lots of indirections and abstractions going on, but it seems like this is just a fancy ioctl wrapper/driver backend abstractions. Not really something applications would use. From the pretty picture on github it looks like there's some opencl/ml/other fancy stuff sitting on top that applications would use. Is that also available? Thanks, Daniel > > Thanks, > -Sonal > > Sonal Santan (6): > Add skeleton code: ioctl definitions and build hooks > Global data structures shared between xocl and xmgmt drivers > Add platform drivers for various IPs and frameworks > Add core of XDMA driver > Add management driver > Add user physical function driver > > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/xocl/Kconfig | 22 + > drivers/gpu/drm/xocl/Makefile |3 + > drivers/gpu/drm/xocl/devices.h | 954 + > drivers/gpu/drm/xocl/ert.h | 385 ++ > drivers/gpu/drm/xocl/lib/Makefile.in | 16 + > drivers/gpu/drm/xocl/lib/cdev_sgdma.h | 63 + > drivers/gpu/drm/xocl/lib/libxdma.c | 4368 > drivers/gpu/drm/xocl/lib/libxdma.h | 596 +++ > drivers/gpu/drm/xocl/lib/libxdma_api.h | 127 + > drivers/gpu/drm/xocl/mgmtpf/Makefile | 29 + > drivers/gpu/drm/xocl/mgmtpf/mgmt-core.c| 960 + > drivers/gpu/drm/xocl/mgmtpf/mgmt-core.h| 147 + > drivers/gpu/drm/xocl/mgmtpf/mgmt-cw.c | 30 + > drivers/gpu/drm/xocl/mgmtpf/mgmt-ioctl.c | 148 + > drivers/gpu/drm/xocl/mgmtpf/mgmt-reg.h |
Re: [PATCHv15 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
On Fri, 15 Mar 2019 22:54:33 +0800, Hean-Loong Ong wrote: > From: "Ong, Hean Loong" > > Device tree binding for Intel FPGA Video and Image Processing Suite. > The bindings would set the max width, max height, > bits per pixel and memory port width. > The device tree binding only supports the Intel > Arria10 devkit and its variants. Vendor name retained as altr. > > V12: > Wrap comments and fix commit message > > V11: > No change > > V10: > No change > > V9: > Remove Display port node > > V8: > *Add port to Display port decoder > > V7: > *Fix OF graph for better description > *Add description for encoder > > V6: > *Description have not describe DT device in general > > V5: > *remove bindings for bits per symbol as it has only one value which is 8 > > V4: > *fix properties that does not describe the values > > V3: > *OF graph not in accordance to graph.txt > > V2: > *Remove Linux driver description > > V1: > *Missing vendor prefix > > Signed-off-by: Ong, Hean Loong > --- > .../bindings/display/altr,vip-fb2.txt | 63 +++ > 1 file changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/6] dt-bindings: display: sii902x: Remove trailing white space
On Fri, 22 Mar 2019 10:06:13 +0200, Jyri Sarha wrote: > Remove trailing white space from sii902x display bridge binding. > > Signed-off-by: Jyri Sarha > Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/6] dt-bindings: display: sii902x: Add HDMI audio bindings
On Thu, Mar 14, 2019 at 01:27:51PM +0200, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x.txt | 33 +++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index c4c1855ca654..1a37bbe7c597 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -9,6 +9,33 @@ Optional properties:
> about hotplug events.
> - reset-gpios: OF device-tree gpio specification for RST_N pin.
>
> + HDMI audio properties:
> + - i2s-data-lanes: Array of up to 4 integers with values of 0-3
> +Each integer indicates which i2s pin is connected to which
> +audio fifo. The first integer selects i2s audio pin for the
> +first audio fifo#0 (HDMI channels 1&2), second for fifo#1
> +(HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
> +pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
> +but there can be no gaps. E.g. an i2s pin must be mapped to
> +fifo#0 and fifo#1 before mapping a channel to fifo#2.
> +I2S HDMI audio is configured only if this property is found.
Seems like a default should be allowed and you should enable audio based
on #sound-dai-cells which you didn't document.
> + - clocks: phandle and clock specifier for each clock listed in
> + the clock-names property
> + - clock-names: "mclk"
> + Describes SII902x MCLK input. MCLK is used to produce
> + HDMI audio CTS values. This property is required if
> + "i2s-data-lanes"-property is present. This property follows
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + consumer binding.
> +
> + If HDMI audio is configured the sii902x device becomes an ASoC
> + codec component, that can be used in configuring full audio
> + devices with ASoC simple-card or audio-graph-card. See their
With the graph-card, don't you need to define which port is audio?
> + binding documents on how to describe how the sii902x device is
> + connected to the rest of the audio system:
> + Documentation/devicetree/bindings/sound/simple-card.txt
> + Documentation/devicetree/bindings/sound/audio-graph-card.txt
> +
> Optional subnodes:
> - video input: this subnode can contain a video input port node
> to connect the bridge to a display controller output (See this
> @@ -21,6 +48,12 @@ Example:
> compatible = "sil,sii9022";
> reg = <0x39>;
> reset-gpios = < 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-data-lanes = < 0 1 2 >;
> + clocks = <>;
> + clock-names = "mclk";
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] dt-bindings: display: armada: Improve the LCDC documentation
On Wed, Mar 20, 2019 at 09:20:55AM +0100, Lubomir Rintel wrote: > The port is a child, not a property. And should be accompanied by an > example. Plus a pair of cosmetic changes that don't seem to deserve a > separate commit. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v2: > - Collected the Reviewed-by tag Really, where? > Changes since v1: > - Minor adjustments to the commit message wording. > > .../bindings/display/marvell,armada-lcdc.txt | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110225] Kernel panic while “ modprobe amdkfd ; modprobe -r amdkfd " ; 4.14.35 kernel .
https://bugs.freedesktop.org/show_bug.cgi?id=110225 john.p.donne...@oracle.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from john.p.donne...@oracle.com --- Note - SyzKaller will also report this error: [ 3718.925349] AMD IOMMUv2 driver by Joerg Roedel [ 3718.926551] AMD IOMMUv2 functionality not available on this system [ 3719.045519] CRAT table not found [ 3719.046153] Finished initializing topology ret=0 [ 3719.046921] kfd kfd: Initialized module [ 3720.058664] == [ 3720.060042] BUG: KASAN: use-after-free in __dev_printk+0x222/0x26a [ 3720.061030] Read of size 8 at addr 88004be04950 by task modprobe/15273 [ 3720.062110] [ 3720.062384] CPU: 0 PID: 15273 Comm: modprobe Not tainted 4.14.35-1911.0.20190312_.syzkaller #12 [ 3720.063815] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 [ 3720.065559] Call Trace: [ 3720.066096] dump_stack+0x83/0xaf [ 3720.066627] ? __dev_printk+0x222/0x26a [ 3720.067171] print_address_description+0x6a/0x22d [ 3720.068215] ? __dev_printk+0x222/0x26a [ 3720.069693] kasan_report.cold.6+0x11a/0x2d3 [ 3720.070511] __asan_report_load8_noabort+0x19/0x1b [ 3720.071524] __dev_printk+0x222/0x26a [ 3720.072345] _dev_info+0xdd/0x112 [ 3720.072981] ? dev_notice+0x120/0x112 [ 3720.073694] ? kasan_slab_free+0x88/0xb9 [ 3720.074613] ? kfd_pasid_exit+0x1a/0x20 [amdkfd] [ 3720.075631] kfd_module_exit+0x5c/0x6d [amdkfd] [ 3720.076573] SyS_delete_module+0x346/0x4ad [ 3720.077131] ? free_module+0x6d0/0x6c5 [ 3720.077627] ? entry_SYSCALL_64_after_hwframe+0xfe/0x0 [ 3720.078261] ? entry_SYSCALL_64_after_hwframe+0xf0/0x0 [ 3720.078894] ? entry_SYSCALL_64_after_hwframe+0xe9/0x0 [ 3720.079491] ? entry_SYSCALL_64_after_hwframe+0xe2/0x0 [ 3720.080441] ? entry_SYSCALL_64_after_hwframe+0xdb/0x0 [ 3720.081511] ? entry_SYSCALL_64_after_hwframe+0xd4/0x0 [ 3720.082778] ? entry_SYSCALL_64_after_hwframe+0xc6/0x0 [ 3720.083809] ? entry_SYSCALL_64_after_hwframe+0xbf/0x0 [ 3720.084929] ? entry_SYSCALL_64_after_hwframe+0xb8/0x0 [ 3720.086024] ? free_module+0x6d0/0x6c5 [ 3720.086790] do_syscall_64+0x1bc/0x53f [ 3720.087502] ? entry_SYSCALL_64_after_hwframe+0x79/0x0 [ 3720.088402] ? entry_SYSCALL_64_after_hwframe+0x72/0x0 [ 3720.089251] ? entry_SYSCALL_64_after_hwframe+0x6b/0x0 [ 3720.090105] ? entry_SYSCALL_64_after_hwframe+0x64/0x0 [ 3720.091079] ? entry_SYSCALL_64_after_hwframe+0x5d/0x0 [ 3720.091978] entry_SYSCALL_64_after_hwframe+0x151/0x0 [ 3720.092759] RIP: 0033:0x7f29dad1d457 [ 3720.093414] RSP: 002b:7ffcf29f40c8 EFLAGS: 0202 ORIG_RAX: 00b0 [ 3720.094599] RAX: ffda RBX: 00794550 RCX: 7f29dad1d457 [ 3720.095927] RDX: RSI: 0800 RDI: 007945b8 [ 3720.097450] RBP: R08: 7f29dafe6060 R09: 7f29dad91be0 [ 3720.098515] R10: 7ffcf29f3c90 R11: 0202 R12: [ 3720.100023] R13: 0001 R14: 007945b8 R15: [ 3720.101374] [ 3720.101643] Allocated by task 15263: [ 3720.102241] save_stack+0x43/0xc4 [ 3720.102853] kasan_kmalloc+0xc4/0xd8 [ 3720.103506] kmem_cache_alloc_trace+0xed/0x1f7 [ 3720.104238] device_create_groups_vargs+0x9d/0x246 [ 3720.105026] device_create+0xe0/0x10c [ 3720.105530] kfd_chardev_init+0xc0/0xf0 [amdkfd] [ 3720.106194] 0xc0440077 [ 3720.106668] do_one_initcall+0xaf/0x1ba [ 3720.107279] do_init_module+0x1fa/0x67f [ 3720.108040] load_module+0x385c/0x511e [ 3720.108790] SYSC_finit_module+0x141/0x1cd [ 3720.109502] SyS_finit_module+0xe/0x10 [ 3720.110129] do_syscall_64+0x1bc/0x53f [ 3720.110765] entry_SYSCALL_64_after_hwframe+0x151/0x0 [ 3720.111730] [ 3720.111992] Freed by task 15273: [ 3720.112546] save_stack+0x43/0xc4 [ 3720.113103] kasan_slab_free+0x72/0xb9 [ 3720.113738] kfree+0x94/0x190 [ 3720.114340] device_create_release+0x2b/0xb1 [ 3720.115069] device_release+0x83/0x1aa [ 3720.115599] kobject_release+0x165/0x41f [ 3720.116399] kobject_put+0x76/0x87 [ 3720.117129] device_unregister+0x3e/0xc9 [ 3720.117909] device_destroy+0x98/0xcc [ 3720.118659] kfd_chardev_exit+0x23/0x50 [amdkfd] [ 3720.119640] kfd_module_exit+0x22/0x6d [amdkfd] [ 3720.120662] SyS_delete_module+0x346/0x4ad [ 3720.121445] do_syscall_64+0x1bc/0x53f [ 3720.122083] entry_SYSCALL_64_after_hwframe+0x151/0x0 [ 3720.122850] [ 3720.123084] The buggy address belongs to the object at 88004be04900 [ 3720.123084] which belongs to the cache kmalloc-1024 of size 1024 [ 3720.125280] The buggy address is located 80 bytes inside of [ 3720.125280] 1024-byte region [88004be04900, 88004be04d00) [ 3720.127200] The buggy address belongs to the page: [ 3720.128005]
[Bug 110225] Kernel panic while “ modprobe amdkfd ; modprobe -r amdkfd " ; 4.14.35 kernel .
https://bugs.freedesktop.org/show_bug.cgi?id=110225
--- Comment #1 from john.p.donne...@oracle.com ---
This was been fixed in 4.20.x upstream:
commit c393e9b2d51540b74e18e555df14706098dbf2cc
Author: Randy Dunlap
Date: Mon Nov 13 18:08:48 2017 +0200
drm/amdkfd: fix amdkfd use-after-free GP fault
Fix GP fault caused by dev_info() reference to a struct device*
after the device has been freed (use after free).
kfd_chardev_exit() frees the device so 'kfd_device' should not
be used after calling kfd_chardev_exit().
Signed-off-by: Randy Dunlap
Signed-off-by: Oded Gabbay
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 6c5a9ca..f744cae 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "kfd_priv.h"
#define KFD_DRIVER_AUTHOR "AMD Inc. and others"
@@ -132,7 +133,7 @@ static void __exit kfd_module_exit(void)
kfd_process_destroy_wq();
kfd_topology_shutdown();
kfd_chardev_exit();
- dev_info(kfd_device, "Removed module\n");
+ pr_info("amdkfd: Removed module\n");
}
[root@jpd-vmbase02 ~]# modprobe amdkfd
[ 132.453287] AMD IOMMUv2 driver by Joerg Roedel
[ 132.454004] AMD IOMMUv2 functionality not available on this system
[ 132.507733] CRAT table not found
[ 132.508139] Finished initializing topology ret=0
[ 132.508802] kfd kfd: Initialized module
[root@jpd-vmbase02 ~]# modprobe -r amdkfd
[ 137.447829] amdkfd: Removed module
[root@jpd-vmbase02 ~]#
[root@jpd-vmbase02 ~]#
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #38 from quirin.blae...@freenet.de --- Bug is still alive. v5.0.4 -- 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
[PATCH] arm/komeda: Compile komeda_debugfs_init() only if CONFIG_DEBUG_FS is enabled
We don't call this function if CONFIG_DEBUG_FS is not defined, but we
should not be compiling it either, as the declaration of the debugfs
core functions is not included.
Reported by the kbuild test robot.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index b420c6205d6bf..24548b87e1827 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -44,6 +44,7 @@ static const struct file_operations komeda_register_fops = {
.release= single_release,
};
+#ifdef CONFIG_DEBUG_FS
static void komeda_debugfs_init(struct komeda_dev *mdev)
{
if (!debugfs_initialized())
@@ -56,6 +57,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
debugfs_create_file("register", 0444, mdev->debugfs_root,
mdev, _register_fops);
}
+#endif
static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node
*np)
{
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth'
Thanks for doing this. Reviewed-by: Deepak Rawat On Sat, 2019-03-23 at 02:46 +, YueHaibing wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: In function 'vmw_fb_init': > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:29: warning: > variable 'fb_offset' set but not used [-Wunused-but-set-variable] > > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:19: warning: > variable 'fb_depth' set but not used [-Wunused-but-set-variable] > > They're not used any more, so can be removed. > > Signed-off-by: YueHaibing > --- > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c > index 2a9112515f46..86efb91f5034 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c > @@ -642,12 +642,11 @@ int vmw_fb_init(struct vmw_private *vmw_priv) > struct vmw_fb_par *par; > struct fb_info *info; > unsigned fb_width, fb_height; > - unsigned fb_bpp, fb_depth, fb_offset, fb_pitch, fb_size; > + unsigned fb_bpp, fb_pitch, fb_size; > struct drm_display_mode *init_mode; > int ret; > > fb_bpp = 32; > - fb_depth = 24; > > /* XXX As shouldn't these be as well. */ > fb_width = min(vmw_priv->fb_max_width, (unsigned)2048); > @@ -655,7 +654,6 @@ int vmw_fb_init(struct vmw_private *vmw_priv) > > fb_pitch = fb_width * fb_bpp / 8; > fb_size = fb_pitch * fb_height; > - fb_offset = vmw_read(vmw_priv, SVGA_REG_FB_OFFSET); > > info = framebuffer_alloc(sizeof(*par), device); > if (!info) > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED
On Fri, 2019-03-22 at 19:42 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything. > Its counterpart in f86EdidModes.c is properly hooked up but somehow > that functionality was lost when it was copied into the kernel. > > The concensus seems to be that this quirk is a bit misguided > anyway so let's nuke the leftovers. Reviewed-by: Adam Jackson - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm: Add a helper function for printing a debugfs_regset32.
Daniel Vetter writes: > On Wed, Feb 20, 2019 at 01:03:37PM -0800, Eric Anholt wrote: >> The debugfs_regset32 is nice to use for reducing boilerplate in >> dumping a bunch of regs in debugfs, but we also want to be able to >> print to dmesg them at runtime for driver debugging. drm_printer lets >> us format debugfs and the printk the same way. >> >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/drm_print.c | 16 >> include/drm/drm_print.h | 2 ++ >> 2 files changed, 18 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c >> index 0e7fc3e7dfb4..5ecc0f04cd0c 100644 >> --- a/drivers/gpu/drm/drm_print.c >> +++ b/drivers/gpu/drm/drm_print.c >> @@ -253,3 +253,19 @@ void drm_err(const char *format, ...) >> va_end(args); >> } >> EXPORT_SYMBOL(drm_err); >> + > > A bit of kerneldoc would be nice. With that: > > Reviewed-by: Daniel Vetter +/** + * drm_print_regset32 - print the contents of registers to a + * _printer stream. + * + * @p: the printer + * @regset: the list of registers to print. + * + * Often in driver debug, it's useful to be able to either capture the + * contents of registers in the steady state using debugfs or at + * specific points during operation. This lets the driver have a + * single list of registers for both. + */ signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CEC blocks idle on omap4
On 3/25/19 5:21 PM, Tony Lindgren wrote: > * Hans Verkuil [190325 16:12]: >> On 3/25/19 4:55 PM, Laurent Pinchart wrote: The reality is that HDMI CEC and HDMI video are really independent of one another. So I wonder if it isn't better to explain the downsides of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC description. And perhaps disable it by default? >>> >>> This should be controllable by userspace. From a product point of view, >>> it should be possible to put the system in a deep sleep state where CEC >>> isn't available, or in a low sleep state where CEC works as expected. >>> >> >> Userspace can always disable CEC. The hdmi_cec_adap_enable() callback in >> hdmi4_cec.c is called whenever the CEC adapter is enabled or disabled. > > OK > >> I'm not actually sure why hdmi4_cec_init() would block anything since it >> just registers the CEC device. It does not enable it until userspace >> explicitly enables it with e.g. 'cec-ctl --playback'. >> >> hdmi4_cec_init() does configure a CEC clock, but that can be moved to >> hdmi_cec_adap_enable() if necessary. > > Hey I'm pretty sure that's the right fix then :) > >> Note that I am not sure what is meant with 'SoC core retention idle', >> so perhaps I just misunderstand the problem. > > If certain SoC clocks are busy, the SoC will not enter deeper > idle states. The hardware has autoidle type features on omaps. Can you make a patch? It is very easy to test: To configure the CEC adapter: cec-ctl --playback To unconfigure the CEC adapter: cec-ctl --clear As long as the CEC adapter is unconfigured you should be able to enter the deeper idle states. But not if it is configured. And if you are moving code anyway, can you fix the typo in the comment? devider -> divider That hurts my eyes... Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CEC blocks idle on omap4
On 3/25/19 4:55 PM, Laurent Pinchart wrote: > Hi Hans, > > On Mon, Mar 25, 2019 at 04:51:57PM +0100, Hans Verkuil wrote: >> On 3/25/19 4:32 PM, Tony Lindgren wrote: >>> Hi Hans, >>> >>> Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention >>> idle on omap4 if selected. >>> >>> Should we maybe move hdmi4_cec_init() to hdmi_display_enable() >>> and hdmi4_cec_uninit() to hdmi_display_disable()? >>> >>> Or add some enable/disable calls in addtion to the init and >>> uninit calls that can be called from hdmi_display_enable() >>> and hdmi_display_disable()? >> >> For proper HDMI CEC behavior the CEC adapter has to remain active >> even if the HPD of the display is low. Some displays pull down the >> HPD when in standby, but CEC can still be used to wake them up. >> >> And we see this more often as regulations for the maximum power >> consumption of displays are getting more and more strict. >> >> So disabling CEC when the display is disabled is not an option. >> >> Disabling CEC if the source is no longer transmitting isn't a good >> idea either since the display will typically still send periodic >> CEC commands to the source that it expects to reply to. > > What's the periodicity of those commands ? Can the system be put to > sleep and get woken up when there's CEC activity ? You don't control that. The sink can transmit a CEC message at any time and the omap4 CEC adapter has to be active to correctly react. > >> The reality is that HDMI CEC and HDMI video are really independent of >> one another. So I wonder if it isn't better to explain the downsides >> of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC >> description. And perhaps disable it by default? > > This should be controllable by userspace. From a product point of view, > it should be possible to put the system in a deep sleep state where CEC > isn't available, or in a low sleep state where CEC works as expected. > Userspace can always disable CEC. The hdmi_cec_adap_enable() callback in hdmi4_cec.c is called whenever the CEC adapter is enabled or disabled. I'm not actually sure why hdmi4_cec_init() would block anything since it just registers the CEC device. It does not enable it until userspace explicitly enables it with e.g. 'cec-ctl --playback'. hdmi4_cec_init() does configure a CEC clock, but that can be moved to hdmi_cec_adap_enable() if necessary. Note that I am not sure what is meant with 'SoC core retention idle', so perhaps I just misunderstand the problem. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] dt-bindings: Add Rocktech jh057n00900 panel bindings
Hi,
On Mon, Mar 25, 2019 at 11:10:47AM -0300, Fabio Estevam wrote:
> On Mon, Mar 25, 2019 at 11:06 AM Guido Günther wrote:
>
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> > @@ -0,0 +1,18 @@
> > +Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "rocktech,jh057n00900"
> > +- reg: DSI virtual channel of the peripheral
> > +- reset-gpios: panel reset gpio
> > +- backlight: phandle of the backlight device attached to the panel
> > +
> > +Example:
> > +
> > + _dsi {
> > + panel {
> > + compatible = "rocktech,jh057n00900";
> > + reg = <0>;
>
> Passing the reg property without its corresponding @0 would cause a
> dtc warning when building with W=1.
Thanks, I've put that in for v5 and sent a patch to correct
the other drivers in display/panel:
https://patchwork.kernel.org/patch/10869563/
Cheers,
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display/panel: Add missing unit names
Some examples were missing the unit names triggering
Warning (unit_address_vs_reg): .../panel: node has a reg or ranges property,
but no unit name
warnings when used verbatim in DTs and running dtc with W=1.
Signed-off-by: Guido Günther
---
.../devicetree/bindings/display/panel/innolux,p079zca.txt | 2 +-
.../devicetree/bindings/display/panel/innolux,p097pfg.txt | 2 +-
.../devicetree/bindings/display/panel/kingdisplay,kd097d04.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
index d0f55161579a..3ab8c7412cf6 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -12,7 +12,7 @@ Optional properties:
Example:
_dsi {
- panel {
+ panel@0 {
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
index 595d9dfeffd3..d1cab3a8f0fb 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
@@ -13,7 +13,7 @@ Optional properties:
Example:
_dsi {
- panel {
+ panel@0 {
compatible = "innolux,p079zca";
reg = <0>;
avdd-supply = <...>;
diff --git
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
index 164a5fa236da..cfefff688614 100644
--- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
+++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
@@ -12,7 +12,7 @@ Optional properties:
Example:
_dsi {
- panel {
+ panel@0 {
compatible = "kingdisplay,kd097d04";
reg = <0>;
power-supply = <...>;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CEC blocks idle on omap4
Hi Tony, On 3/25/19 4:32 PM, Tony Lindgren wrote: > Hi Hans, > > Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention > idle on omap4 if selected. > > Should we maybe move hdmi4_cec_init() to hdmi_display_enable() > and hdmi4_cec_uninit() to hdmi_display_disable()? > > Or add some enable/disable calls in addtion to the init and > uninit calls that can be called from hdmi_display_enable() > and hdmi_display_disable()? For proper HDMI CEC behavior the CEC adapter has to remain active even if the HPD of the display is low. Some displays pull down the HPD when in standby, but CEC can still be used to wake them up. And we see this more often as regulations for the maximum power consumption of displays are getting more and more strict. So disabling CEC when the display is disabled is not an option. Disabling CEC if the source is no longer transmitting isn't a good idea either since the display will typically still send periodic CEC commands to the source that it expects to reply to. The reality is that HDMI CEC and HDMI video are really independent of one another. So I wonder if it isn't better to explain the downsides of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC description. And perhaps disable it by default? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CEC blocks idle on omap4
Hi Hans, On Mon, Mar 25, 2019 at 04:51:57PM +0100, Hans Verkuil wrote: > On 3/25/19 4:32 PM, Tony Lindgren wrote: > > Hi Hans, > > > > Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention > > idle on omap4 if selected. > > > > Should we maybe move hdmi4_cec_init() to hdmi_display_enable() > > and hdmi4_cec_uninit() to hdmi_display_disable()? > > > > Or add some enable/disable calls in addtion to the init and > > uninit calls that can be called from hdmi_display_enable() > > and hdmi_display_disable()? > > For proper HDMI CEC behavior the CEC adapter has to remain active > even if the HPD of the display is low. Some displays pull down the > HPD when in standby, but CEC can still be used to wake them up. > > And we see this more often as regulations for the maximum power > consumption of displays are getting more and more strict. > > So disabling CEC when the display is disabled is not an option. > > Disabling CEC if the source is no longer transmitting isn't a good > idea either since the display will typically still send periodic > CEC commands to the source that it expects to reply to. What's the periodicity of those commands ? Can the system be put to sleep and get woken up when there's CEC activity ? > The reality is that HDMI CEC and HDMI video are really independent of > one another. So I wonder if it isn't better to explain the downsides > of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC > description. And perhaps disable it by default? This should be controllable by userspace. From a product point of view, it should be possible to put the system in a deep sleep state where CEC isn't available, or in a low sleep state where CEC works as expected. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #4 from Alex Deucher --- Hardly anything in the radeon driver has changed in the last few years. You'd really need to bisect. Also, can you attach a full dmesg (full logs not just filtered for radeon or drm) output from the failed and working cases? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] drm/meson: Add G12A Support
The Amlogic G12A SoC offers very close Video Display functionnalities with it's older GXBB, GXL & GXM predecessors. The main differences are : - G12A Support now 3 "real" OSD planes with a new Blender module - Instead of having a single Scaler for OSD1, G12A has two scaler that can be applied to 2 out of the 3 OSD planes or on the outputs of the blender module. - The HDMI PHY now support RX-SENSE, Dynamic HDR and it's registers are now memory mapped instead of using an internal bus. - The VPU now support a DSI interface to connect a display, using the Synopsys DSI controller and a custom PHY The complex Blender routing, HDMI RX-SENSE, Dynamic HDR and DSI support are not handled in this patchset. This patchset implements on-par support with the currently support GXBB, GXL and GXM SoCs. There is no support delta with this patchset. patch 10 & 11 implements the bindings found at [1]. [1] https://lkml.kernel.org/r/20190313141030.5958-1-narmstr...@baylibre.com Neil Armstrong (11): drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock drm/meson: Add registers for G12A SoC drm/meson: Add G12A Support for VPP setup drm/meson: Add G12A Support for VIU setup drm/meson: Add G12A support for OSD1 Plane drm/meson: Add G12A Support for the Overlay video plane drm/meson: Add G12A support for plane handling in CRTC driver drm/meson: Add G12A support for CVBS Encoer drm/meson: Add G12A Video Clock setup drm/meson: Add G12A compatible drm/meson: Add G12A support for the DW-HDMI Glue drivers/gpu/drm/meson/meson_crtc.c | 269 +++- drivers/gpu/drm/meson/meson_drv.c | 1 + drivers/gpu/drm/meson/meson_drv.h | 4 + drivers/gpu/drm/meson/meson_dw_hdmi.c | 163 +++--- drivers/gpu/drm/meson/meson_dw_hdmi.h | 32 ++- drivers/gpu/drm/meson/meson_overlay.c | 10 +- drivers/gpu/drm/meson/meson_plane.c | 15 +- drivers/gpu/drm/meson/meson_registers.h | 247 ++ drivers/gpu/drm/meson/meson_vclk.c | 123 +-- drivers/gpu/drm/meson/meson_venc.c | 11 +- drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++- drivers/gpu/drm/meson/meson_viu.c | 72 ++- drivers/gpu/drm/meson/meson_vpp.c | 51 +++-- 13 files changed, 880 insertions(+), 143 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator
https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #13 from glencoesm...@hotmail.com --- (In reply to e88z4 from comment #12) > I usually build mesa master weekly since November 2018. This bug can be > reproduced with latest Mesa from git master branch. > > Do you want me to try to build 18.3.5 and reproduce it? No, I was just curious if the bug showed up in 18.3.5. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/meson: Add G12A support for plane handling in CRTC driver
This patch adds support for the new OSD+VD Plane blending module
in the CRTC code by adding the G12A code to manage the blending
module and setting the right OSD1 & VD1 plane registers.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 269 +++--
drivers/gpu/drm/meson/meson_drv.h | 4 +
2 files changed, 221 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 6d9311e254ef..5579f8ac3e3f 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -39,12 +39,17 @@
#include "meson_viu.h"
#include "meson_registers.h"
+#define MESON_G12A_VIU_OFFSET 0x5ec0
+
/* CRTC definition */
struct meson_crtc {
struct drm_crtc base;
struct drm_pending_vblank_event *event;
struct meson_drm *priv;
+ void (*enable_osd1)(struct meson_drm *priv);
+ void (*enable_vd1)(struct meson_drm *priv);
+ unsigned int viu_offset;
};
#define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
@@ -80,6 +85,44 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
};
+static void meson_g12a_crtc_atomic_enable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
+ struct drm_crtc_state *crtc_state = crtc->state;
+ struct meson_drm *priv = meson_crtc->priv;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ if (!crtc_state) {
+ DRM_ERROR("Invalid crtc_state\n");
+ return;
+ }
+
+ /* VD1 Preblend vertical start/end */
+ writel(FIELD_PREP(GENMASK(11, 0), 2303),
+ priv->io_base + _REG(VPP_PREBLEND_VD1_V_START_END));
+
+ /* Setup Blender */
+ writel(crtc_state->mode.hdisplay |
+ crtc_state->mode.vdisplay << 16,
+ priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
+
+ writel_relaxed(0 << 16 |
+ (crtc_state->mode.hdisplay - 1),
+ priv->io_base + _REG(VPP_OSD1_BLD_H_SCOPE));
+ writel_relaxed(0 << 16 |
+ (crtc_state->mode.vdisplay - 1),
+ priv->io_base + _REG(VPP_OSD1_BLD_V_SCOPE));
+ writel_relaxed(crtc_state->mode.hdisplay << 16 |
+ crtc_state->mode.vdisplay,
+ priv->io_base + _REG(VPP_OUT_H_V_SIZE));
+
+ drm_crtc_vblank_on(crtc);
+
+ priv->viu.osd1_enabled = true;
+}
+
static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -110,6 +153,31 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
priv->viu.osd1_enabled = true;
}
+static void meson_g12a_crtc_atomic_disable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
+ struct meson_drm *priv = meson_crtc->priv;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ drm_crtc_vblank_off(crtc);
+
+ priv->viu.osd1_enabled = false;
+ priv->viu.osd1_commit = false;
+
+ priv->viu.vd1_enabled = false;
+ priv->viu.vd1_commit = false;
+
+ if (crtc->state->event && !crtc->state->active) {
+ spin_lock_irq(>dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ spin_unlock_irq(>dev->event_lock);
+
+ crtc->state->event = NULL;
+ }
+}
+
static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -173,6 +241,53 @@ static const struct drm_crtc_helper_funcs
meson_crtc_helper_funcs = {
.atomic_disable = meson_crtc_atomic_disable,
};
+static const struct drm_crtc_helper_funcs meson_g12a_crtc_helper_funcs = {
+ .atomic_begin = meson_crtc_atomic_begin,
+ .atomic_flush = meson_crtc_atomic_flush,
+ .atomic_enable = meson_g12a_crtc_atomic_enable,
+ .atomic_disable = meson_g12a_crtc_atomic_disable,
+};
+
+static void meson_crtc_enable_osd1(struct meson_drm *priv)
+{
+ writel_bits_relaxed(VPP_OSD1_POSTBLEND, VPP_OSD1_POSTBLEND,
+ priv->io_base + _REG(VPP_MISC));
+}
+
+static void meson_g12a_crtc_enable_osd1(struct meson_drm *priv)
+{
+ writel_relaxed(priv->viu.osd_blend_din0_scope_h,
+ priv->io_base +
+ _REG(VIU_OSD_BLEND_DIN0_SCOPE_H));
+ writel_relaxed(priv->viu.osd_blend_din0_scope_v,
+ priv->io_base +
+ _REG(VIU_OSD_BLEND_DIN0_SCOPE_V));
+ writel_relaxed(priv->viu.osb_blend0_size,
+ priv->io_base +
+ _REG(VIU_OSD_BLEND_BLEND0_SIZE));
+ writel_relaxed(priv->viu.osb_blend1_size,
+ priv->io_base +
+
[PATCH 04/11] drm/meson: Add G12A Support for VIU setup
Amlogic G12A SoC needs a different VIU setup code,
handle it.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_viu.c | 72 ---
1 file changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_viu.c
b/drivers/gpu/drm/meson/meson_viu.c
index ac0f3687e09a..0169c98b01c9 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -90,6 +90,34 @@ static int eotf_bypass_coeff[EOTF_COEFF_SIZE] = {
EOTF_COEFF_RIGHTSHIFT /* right shift */
};
+void meson_viu_set_g12a_osd1_matrix(struct meson_drm *priv, int *m,
+ bool csc_on)
+{
+ /* VPP WRAP OSD1 matrix */
+ writel(((m[0] & 0xfff) << 16) | (m[1] & 0xfff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET0_1));
+ writel(m[2] & 0xfff,
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET2));
+ writel(((m[3] & 0x1fff) << 16) | (m[4] & 0x1fff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF00_01));
+ writel(((m[5] & 0x1fff) << 16) | (m[6] & 0x1fff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF02_10));
+ writel(((m[7] & 0x1fff) << 16) | (m[8] & 0x1fff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF11_12));
+ writel(((m[9] & 0x1fff) << 16) | (m[10] & 0x1fff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF20_21));
+ writel((m[11] & 0x1fff) << 16,
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF22));
+
+ writel(((m[18] & 0xfff) << 16) | (m[19] & 0xfff),
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET0_1));
+ writel(m[20] & 0xfff,
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET2));
+
+ writel_bits_relaxed(BIT(0), csc_on ? BIT(0) : 0,
+ priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_EN_CTRL));
+}
+
void meson_viu_set_osd_matrix(struct meson_drm *priv,
enum viu_matrix_sel_e m_select,
int *m, bool csc_on)
@@ -336,14 +364,24 @@ void meson_viu_init(struct meson_drm *priv)
if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
meson_viu_load_matrix(priv);
+ else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ meson_viu_set_g12a_osd1_matrix(priv, RGB709_to_YUV709l_coeff,
+ true);
/* Initialize OSD1 fifo control register */
reg = BIT(0) | /* Urgent DDR request priority */
- (4 << 5) | /* hold_fifo_lines */
- (3 << 10) | /* burst length 64 */
- (32 << 12) | /* fifo_depth_val: 32*8=256 */
- (2 << 22) | /* 4 words in 1 burst */
- (2 << 24);
+ (4 << 5); /* hold_fifo_lines */
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ reg |= (1 << 10) | /* burst length 32 */
+ (32 << 12) | /* fifo_depth_val: 32*8=256 */
+ (2 << 22) | /* 4 words in 1 burst */
+ (2 << 24) |
+ (1 << 31);
+ else
+ reg |= (3 << 10) | /* burst length 64 */
+ (32 << 12) | /* fifo_depth_val: 32*8=256 */
+ (2 << 22) | /* 4 words in 1 burst */
+ (2 << 24);
writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
@@ -369,6 +407,30 @@ void meson_viu_init(struct meson_drm *priv)
writel_relaxed(0x00FF00C0,
priv->io_base + _REG(VD2_IF0_LUMA_FIFO_SIZE));
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ writel_relaxed(4 << 29 |
+ 1 << 27 |
+ 1 << 26 | /* blend_din0 input to blend0 */
+ 1 << 25 | /* blend1_dout to blend2 */
+ 1 << 24 | /* blend1_din3 input to blend1 */
+ 1 << 20 |
+ 0 << 16 |
+ 1,
+ priv->io_base + _REG(VIU_OSD_BLEND_CTRL));
+ writel_relaxed(3 << 8 |
+ 1 << 20,
+ priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
+ writel_relaxed(1 << 20,
+ priv->io_base + _REG(OSD2_BLEND_SRC_CTRL));
+ writel_relaxed(0, priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+ writel_relaxed(0, priv->io_base + _REG(VD2_BLEND_SRC_CTRL));
+ writel_relaxed(0,
+ priv->io_base +
_REG(VIU_OSD_BLEND_DUMMY_DATA0));
+ writel_relaxed(0,
+
[PATCH 06/11] drm/meson: Add G12A Support for the Overlay video plane
Amlogic G12A SoC supports the same set of Video Planes, but now
are handled by the new OSD plane blender module.
This patch uses the same VD1 plane for G12A, using the exact same scaler
and VD11 setup registers, except using the new blender register to
disable the plane.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index b54a22e483b9..bdbf925ff3e8 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -516,8 +516,14 @@ static void meson_overlay_atomic_disable(struct drm_plane
*plane,
priv->viu.vd1_enabled = false;
/* Disable VD1 */
- writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
- priv->io_base + _REG(VPP_MISC));
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ writel_relaxed(0, priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+ writel_relaxed(0, priv->io_base + _REG(VD2_BLEND_SRC_CTRL));
+ writel_relaxed(0, priv->io_base + _REG(VD1_IF0_GEN_REG +
0x17b0));
+ writel_relaxed(0, priv->io_base + _REG(VD2_IF0_GEN_REG +
0x17b0));
+ } else
+ writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
+ priv->io_base + _REG(VPP_MISC));
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock
On Amlogic G12A SoC, the 2,97GHz PLL frequency is not stable enough
to provide a correct 297MHz pixel clock, so switch the PLL base
frequency with a /2 OD when the 297MHz pixel clock is requested.
This solves the issue on G12A and also works fine on GXBB, GXL & GXM.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_vclk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c
b/drivers/gpu/drm/meson/meson_vclk.c
index f6ba35a405f8..c15a5a5df633 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -396,8 +396,8 @@ struct meson_vclk_params {
},
[MESON_VCLK_HDMI_297000] = {
.pixel_freq = 297000,
- .pll_base_freq = 297,
- .pll_od1 = 1,
+ .pll_base_freq = 594,
+ .pll_od1 = 2,
.pll_od2 = 1,
.pll_od3 = 1,
.vid_pll_div = VID_PLL_DIV_5,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] drm/meson: Add registers for G12A SoC
This patch adds the new VPU registers added since the Amlogic GXM SoCs. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_registers.h | 247 1 file changed, 247 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h index 5c7e02c703bc..cfaf90501bb1 100644 --- a/drivers/gpu/drm/meson/meson_registers.h +++ b/drivers/gpu/drm/meson/meson_registers.h @@ -216,6 +216,29 @@ #define VIU_OSD2_FIFO_CTRL_STAT 0x1a4b #define VIU_OSD2_TEST_RDDATA 0x1a4c #define VIU_OSD2_PROT_CTRL 0x1a4e +#define VIU_OSD2_MALI_UNPACK_CTRL 0x1abd +#define VIU_OSD2_DIMM_CTRL 0x1acf + +#define VIU_OSD3_CTRL_STAT 0x3d80 +#define VIU_OSD3_CTRL_STAT2 0x3d81 +#define VIU_OSD3_COLOR_ADDR 0x3d82 +#define VIU_OSD3_COLOR 0x3d83 +#define VIU_OSD3_TCOLOR_AG0 0x3d84 +#define VIU_OSD3_TCOLOR_AG1 0x3d85 +#define VIU_OSD3_TCOLOR_AG2 0x3d86 +#define VIU_OSD3_TCOLOR_AG3 0x3d87 +#define VIU_OSD3_BLK0_CFG_W0 0x3d88 +#define VIU_OSD3_BLK0_CFG_W1 0x3d8c +#define VIU_OSD3_BLK0_CFG_W2 0x3d90 +#define VIU_OSD3_BLK0_CFG_W3 0x3d94 +#define VIU_OSD3_BLK0_CFG_W4 0x3d98 +#define VIU_OSD3_BLK1_CFG_W4 0x3d99 +#define VIU_OSD3_BLK2_CFG_W4 0x3d9a +#define VIU_OSD3_FIFO_CTRL_STAT 0x3d9c +#define VIU_OSD3_TEST_RDDATA 0x3d9d +#define VIU_OSD3_PROT_CTRL 0x3d9e +#define VIU_OSD3_MALI_UNPACK_CTRL 0x3d9f +#define VIU_OSD3_DIMM_CTRL 0x3da0 #define VD1_IF0_GEN_REG 0x1a50 #define VD1_IF0_CANVAS0 0x1a51 @@ -287,6 +310,27 @@ #define VIU_OSD1_MATRIX_COEF31_32 0x1a9e #define VIU_OSD1_MATRIX_COEF40_41 0x1a9f #define VD1_IF0_GEN_REG3 0x1aa7 + +#define VIU_OSD_BLENDO_H_START_END 0x1aa9 +#define VIU_OSD_BLENDO_V_START_END 0x1aaa +#define VIU_OSD_BLEND_GEN_CTRL0 0x1aab +#define VIU_OSD_BLEND_GEN_CTRL1 0x1aac +#define VIU_OSD_BLEND_DUMMY_DATA 0x1aad +#define VIU_OSD_BLEND_CURRENT_XY 0x1aae + +#define VIU_OSD2_MATRIX_CTRL 0x1ab0 +#define VIU_OSD2_MATRIX_COEF00_01 0x1ab1 +#define VIU_OSD2_MATRIX_COEF02_10 0x1ab2 +#define VIU_OSD2_MATRIX_COEF11_12 0x1ab3 +#define VIU_OSD2_MATRIX_COEF20_21 0x1ab4 +#define VIU_OSD2_MATRIX_COEF22 0x1ab5 +#define VIU_OSD2_MATRIX_OFFSET0_1 0x1ab6 +#define VIU_OSD2_MATRIX_OFFSET2 0x1ab7 +#define VIU_OSD2_MATRIX_PRE_OFFSET0_1 0x1ab8 +#define VIU_OSD2_MATRIX_PRE_OFFSET2 0x1ab9 +#define VIU_OSD2_MATRIX_PROBE_COLOR 0x1aba +#define VIU_OSD2_MATRIX_HL_COLOR 0x1abb +#define VIU_OSD2_MATRIX_PROBE_POS 0x1abc #define VIU_OSD1_EOTF_CTL 0x1ad4 #define VIU_OSD1_EOTF_COEF00_01 0x1ad5 #define VIU_OSD1_EOTF_COEF02_10 0x1ad6 @@ -481,6 +525,82 @@ #define VPP_OSD_SCALE_COEF 0x1dcd #define VPP_INT_LINE_NUM 0x1dce +#define VPP_WRAP_OSD1_MATRIX_COEF00_01 0x3d60 +#define VPP_WRAP_OSD1_MATRIX_COEF02_10 0x3d61 +#define VPP_WRAP_OSD1_MATRIX_COEF11_12 0x3d62 +#define VPP_WRAP_OSD1_MATRIX_COEF20_21 0x3d63 +#define VPP_WRAP_OSD1_MATRIX_COEF22 0x3d64 +#define VPP_WRAP_OSD1_MATRIX_COEF13_14 0x3d65 +#define VPP_WRAP_OSD1_MATRIX_COEF23_24 0x3d66 +#define VPP_WRAP_OSD1_MATRIX_COEF15_25 0x3d67 +#define VPP_WRAP_OSD1_MATRIX_CLIP 0x3d68 +#define VPP_WRAP_OSD1_MATRIX_OFFSET0_1 0x3d69 +#define VPP_WRAP_OSD1_MATRIX_OFFSET2 0x3d6a +#define VPP_WRAP_OSD1_MATRIX_PRE_OFFSET0_1 0x3d6b +#define VPP_WRAP_OSD1_MATRIX_PRE_OFFSET2 0x3d6c +#define VPP_WRAP_OSD1_MATRIX_EN_CTRL 0x3d6d + +#define VPP_WRAP_OSD2_MATRIX_COEF00_01 0x3d70 +#define VPP_WRAP_OSD2_MATRIX_COEF02_10 0x3d71 +#define VPP_WRAP_OSD2_MATRIX_COEF11_12 0x3d72 +#define VPP_WRAP_OSD2_MATRIX_COEF20_21 0x3d73 +#define VPP_WRAP_OSD2_MATRIX_COEF22 0x3d74 +#define VPP_WRAP_OSD2_MATRIX_COEF13_14 0x3d75 +#define VPP_WRAP_OSD2_MATRIX_COEF23_24 0x3d76 +#define VPP_WRAP_OSD2_MATRIX_COEF15_25 0x3d77 +#define VPP_WRAP_OSD2_MATRIX_CLIP 0x3d78 +#define VPP_WRAP_OSD2_MATRIX_OFFSET0_1 0x3d79 +#define VPP_WRAP_OSD2_MATRIX_OFFSET2 0x3d7a +#define VPP_WRAP_OSD2_MATRIX_PRE_OFFSET0_1 0x3d7b +#define VPP_WRAP_OSD2_MATRIX_PRE_OFFSET2 0x3d7c +#define VPP_WRAP_OSD2_MATRIX_EN_CTRL 0x3d7d + +#define VPP_WRAP_OSD3_MATRIX_COEF00_01 0x3db0 +#define VPP_WRAP_OSD3_MATRIX_COEF02_10 0x3db1 +#define VPP_WRAP_OSD3_MATRIX_COEF11_12 0x3db2 +#define VPP_WRAP_OSD3_MATRIX_COEF20_21 0x3db3 +#define VPP_WRAP_OSD3_MATRIX_COEF22 0x3db4 +#define VPP_WRAP_OSD3_MATRIX_COEF13_14 0x3db5 +#define VPP_WRAP_OSD3_MATRIX_COEF23_24 0x3db6 +#define VPP_WRAP_OSD3_MATRIX_COEF15_25 0x3db7 +#define VPP_WRAP_OSD3_MATRIX_CLIP 0x3db8 +#define VPP_WRAP_OSD3_MATRIX_OFFSET0_1 0x3db9 +#define VPP_WRAP_OSD3_MATRIX_OFFSET2 0x3dba +#define VPP_WRAP_OSD3_MATRIX_PRE_OFFSET0_1 0x3dbb +#define VPP_WRAP_OSD3_MATRIX_PRE_OFFSET2 0x3dbc +#define VPP_WRAP_OSD3_MATRIX_EN_CTRL 0x3dbd + +/* osd2 scaler */ +#define OSD2_VSC_PHASE_STEP 0x3d00 +#define OSD2_VSC_INI_PHASE 0x3d01 +#define OSD2_VSC_CTRL0 0x3d02 +#define OSD2_HSC_PHASE_STEP 0x3d03 +#define OSD2_HSC_INI_PHASE 0x3d04 +#define OSD2_HSC_CTRL0 0x3d05 +#define OSD2_HSC_INI_PAT_CTRL 0x3d06 +#define OSD2_SC_DUMMY_DATA 0x3d07 +#define OSD2_SC_CTRL0 0x3d08 +#define OSD2_SCI_WH_M1 0x3d09 +#define OSD2_SCO_H_START_END 0x3d0a +#define OSD2_SCO_V_START_END 0x3d0b +#define
[PATCH v7 1/3] dt-bindings: Add vendor prefix for Mixel Inc
Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI PHY driver. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 413c6f30ce88..97370889039f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -249,6 +249,7 @@ mikroe MikroElektronika d.o.o. minix MINIX Technology Ltd. miramems MiraMEMS Sensing Technology Co., Ltd. mitsubishi Mitsubishi Electric Corporation +mixel Mixel, Inc. mosaixtech Mosaix Technologies, Inc. motorola Motorola, Inc. moxa Moxa Inc. -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203033] New: nouveau hung task
https://bugzilla.kernel.org/show_bug.cgi?id=203033 Bug ID: 203033 Summary: nouveau hung task Product: Drivers Version: 2.5 Kernel Version: 5.0.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mcr...@redhat.com Regression: No The GUI freezes randomly with nouveau with this error in the syslog: INFO: task kworker/u16:4:14755 blocked for more than 120 seconds. Not tainted 5.0.0-matteo #28 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:4 D0 14755 2 0x8000 Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau] Call Trace: ? __schedule+0x1a6/0x6c0 schedule+0x2c/0x70 schedule_timeout+0x268/0x380 ? nvif_notify_get+0x94/0xa0 [nouveau] dma_fence_default_wait+0x204/0x270 ? dma_fence_release+0x90/0x90 dma_fence_wait_timeout+0xdd/0x100 drm_atomic_helper_wait_for_fences+0x3a/0xc0 [drm_kms_helper] nv50_disp_atomic_commit_tail+0x7c/0x850 [nouveau] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x40/0x70 process_one_work+0x1fa/0x400 worker_thread+0x2d/0x3d0 ? process_one_work+0x400/0x400 kthread+0x113/0x130 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x35/0x40 -- 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
2019 X.Org Foundation Election Opening in 35 hours
To all X.Org Foundation Members: We've had some problems with the previous ballot (i.e. I didn't create it properly) that opened last Thursday. Apologies to the two people that already voted. We've re-created the ballot (v2). It will open on March 27 at 2am UTC and close on April 11 at 2am UTC. Updated Schedule: Nomination period Start: Jan 31 00:00 UTC Nomination period End: Feb 28 23:59 UTC Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC Publication of Candidates & start of Candidate QA: Mar 11 Election Start: Mar 21 00:00 UTC - Delayed to March 21, again delayed to March 27 at 02:00 UTC Election End: Apr 4 23:59 UTC - Extended to April 11, 02:00 UTC I will send a reminder the day the polls open. I apologize for the many delays. Please take some time to familiarize yourself with the proposed bylaw changes and the candidates. Details are at https://www.x.org/wiki/BoardOfDirectors/Elections/2019/ Harry, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] dt-bindings: Add Rocktech jh057n00900 panel bindings
The Rocktec jh057n00900 is a 5.5" MIPI DSI video mode panel with a
720x1440 resolution and a built in backlight.
Signed-off-by: Guido Günther
---
.../display/panel/rocktech,jh057n00900.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
new file mode 100644
index ..32f4001d2d6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
@@ -0,0 +1,18 @@
+Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
+
+Required properties:
+- compatible: should be "rocktech,jh057n00900"
+- reg: DSI virtual channel of the peripheral
+- reset-gpios: panel reset gpio
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ _dsi {
+ panel {
+ compatible = "rocktech,jh057n00900";
+ reg = <0>;
+ backlight = <>;
+ reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] drm/panel: Support Rocktech jh057n00900 DSI panel
It's a 5.5" 720x1440 TFT LCD MIPI DSI panel with built in touchscreen and backlight as found in the Librem 5 devkit. These patches are against linux next as of 2019-03-22. v3 got acked by Sam Ravnborg: https://lists.freedesktop.org/archives/dri-devel/2019-March/209326.html Changes from v3 * Forward to next-20190322 * Add MAINTAINERS entry Changes from v2 * As per review comments from Sam Ravnborg * Lowercase sentinel * Drop '_panel' postfix * DRM_DEV_ logging instead of plain DRM_ * Add Reviewed-by: * Add "panel-rocktech-" to the driver name following the pattern from other drm panel drivers. Changes from v1 * As per review comments from Sam Ravnborg * Make SPDX-License-Identifier match MODULE_LICENSE * Sort include files alphabetically * Drop drmP.h and use individual includes * Drop superfuous 'x' in mode printout on error path * Allpixelson_set: Add proper space around '*' * Drop superfluous put_device(>backlight->dev); * Add /* Sentinel */ in jh057n_of_match * Drop jh057n->enabled * Drop drm_display_info_set_bus_formats * Kconfig: Depend on BACKLIGHT_CLASS_DEVICE which somehow got lost * Move jh057n_enable close to jh057n_disable Guido Günther (3): dt-bindings: Add vendor prefix for ROCKTECH DISPLAYS LIMITED dt-bindings: Add Rocktech jh057n00900 panel bindings drm/panel: Add Rocktech jh057n00900 panel driver .../display/panel/rocktech,jh057n00900.txt| 18 + .../devicetree/bindings/vendor-prefixes.txt | 1 + MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig | 13 + drivers/gpu/drm/panel/Makefile| 1 + .../drm/panel/panel-rocktech-jh057n00900.c| 386 ++ 6 files changed, 425 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt create mode 100644 drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] drm/meson: Add G12A Video Clock setup
While switching to the Common Clock Framework is still Work In Progress,
this patch adds the corresponding G12A HDMI PLL setup to be on-par
with the other SoCs support.
The G12A has only a single tweak about the high frequency setup,
where the HDMI PLL needs a specific setup to handle correctly the
5.94GHz DCO frequency.
Apart that, it handle correctly all the other HDMI frequencies
and can achieve even better DMT clock frequency precision with
the larger fractional dividier width.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_vclk.c | 119 ++---
1 file changed, 108 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c
b/drivers/gpu/drm/meson/meson_vclk.c
index c15a5a5df633..b39034745444 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -113,9 +113,12 @@
#define HHI_HDMI_PLL_CNTL4 0x32C /* 0xcb offset in data sheet */
#define HHI_HDMI_PLL_CNTL5 0x330 /* 0xcc offset in data sheet */
#define HHI_HDMI_PLL_CNTL6 0x334 /* 0xcd offset in data sheet */
+#define HHI_HDMI_PLL_CNTL7 0x338 /* 0xce offset in data sheet */
#define HDMI_PLL_RESET BIT(28)
+#define HDMI_PLL_RESET_G12ABIT(29)
#define HDMI_PLL_LOCK BIT(31)
+#define HDMI_PLL_LOCK_G12A (3 << 30)
#define FREQ_1000_1001(_freq) DIV_ROUND_CLOSEST(_freq * 1000, 1001)
@@ -257,6 +260,10 @@ static void meson_venci_cvbs_clock_config(struct meson_drm
*priv)
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x71486980);
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x0e55);
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x4800023d);
+
+ /* Poll for lock bit */
+ regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
+(val & HDMI_PLL_LOCK), 10, 0);
} else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x427b);
@@ -271,11 +278,26 @@ static void meson_venci_cvbs_clock_config(struct
meson_drm *priv)
HDMI_PLL_RESET, HDMI_PLL_RESET);
regmap_update_bits(priv->hhi, HHI_HDMI_PLL_CNTL,
HDMI_PLL_RESET, 0);
- }
- /* Poll for lock bit */
- regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
-(val & HDMI_PLL_LOCK), 10, 0);
+ /* Poll for lock bit */
+ regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
+(val & HDMI_PLL_LOCK), 10, 0);
+ } else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL2, 0x0001);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL3, 0x);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4, 0x6a28dc00);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x65771290);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x39272000);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL7, 0x5654);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x3a0504f7);
+ regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
+
+ /* Poll for lock bit */
+ regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
+ ((val & HDMI_PLL_LOCK_G12A) == HDMI_PLL_LOCK_G12A),
+ 10, 0);
+ }
/* Disable VCLK2 */
regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, 0);
@@ -288,8 +310,13 @@ static void meson_venci_cvbs_clock_config(struct meson_drm
*priv)
VCLK2_DIV_MASK, (55 - 1));
/* select vid_pll for vclk2 */
- regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
- VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
+ VCLK2_SEL_MASK, (0 << VCLK2_SEL_SHIFT));
+ else
+ regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
+ VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
+
/* enable vclk2 gate */
regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, VCLK2_EN);
@@ -476,32 +503,80 @@ void meson_hdmi_pll_set_params(struct meson_drm *priv,
unsigned int m,
/* Poll for lock bit */
regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
(val & HDMI_PLL_LOCK), 10, 0);
+ } else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+
[PATCH 10/11] drm/meson: Add G12A compatible
Finally add the Amlogic G12A SoC compatible for the VPU driver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 079d22299d78..faf1b1b0357c 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -447,6 +447,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "amlogic,meson-gxbb-vpu" },
{ .compatible = "amlogic,meson-gxl-vpu" },
{ .compatible = "amlogic,meson-gxm-vpu" },
+ { .compatible = "amlogic,meson-g12a-vpu" },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] drm/meson: Add G12A support for the DW-HDMI Glue
The Amlogic G12A embeds the same Synopsys DW-HDMI Controller,
but with :
- a "backport" of the HDR signaling registers from more recent
DW-HDMI controllers, this will need a tweak since it's not
normally present on this version of the DW-HDMI controller
- A direct mapping of TOP and DW-HDMI registers instead of an
internal bus accessed using read/write registers
- Support for RX-SENSE, but not yet implemented
- Support for HDMI 2.1 Dynamic HDR, but not yet implemented
- Different registers mapping for the HDMI PHY setup
This patchs adds support for these changes while providing exact
same support as the previous GXBB, GXL & GXM SoCs.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 163 --
drivers/gpu/drm/meson/meson_dw_hdmi.h | 32 -
2 files changed, 157 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 563953ec6ad0..779da21143b9 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -105,6 +106,7 @@
#define HDMITX_TOP_ADDR_REG0x0
#define HDMITX_TOP_DATA_REG0x4
#define HDMITX_TOP_CTRL_REG0x8
+#define HDMITX_TOP_G12A_OFFSET 0x8000
/* Controller Communication Channel */
#define HDMITX_DWC_ADDR_REG0x10
@@ -118,6 +120,8 @@
#define HHI_HDMI_PHY_CNTL1 0x3a4 /* 0xe9 */
#define HHI_HDMI_PHY_CNTL2 0x3a8 /* 0xea */
#define HHI_HDMI_PHY_CNTL3 0x3ac /* 0xeb */
+#define HHI_HDMI_PHY_CNTL4 0x3b0 /* 0xec */
+#define HHI_HDMI_PHY_CNTL5 0x3b4 /* 0xed */
static DEFINE_SPINLOCK(reg_lock);
@@ -127,12 +131,26 @@ enum meson_venc_source {
MESON_VENC_SOURCE_ENCP = 2,
};
+struct meson_dw_hdmi;
+
+struct meson_dw_hdmi_data {
+ unsigned int(*top_read)(struct meson_dw_hdmi *dw_hdmi,
+ unsigned int addr);
+ void(*top_write)(struct meson_dw_hdmi *dw_hdmi,
+unsigned int addr, unsigned int data);
+ unsigned int(*dwc_read)(struct meson_dw_hdmi *dw_hdmi,
+ unsigned int addr);
+ void(*dwc_write)(struct meson_dw_hdmi *dw_hdmi,
+unsigned int addr, unsigned int data);
+};
+
struct meson_dw_hdmi {
struct drm_encoder encoder;
struct dw_hdmi_plat_data dw_plat_data;
struct meson_drm *priv;
struct device *dev;
void __iomem *hdmitx;
+ const struct meson_dw_hdmi_data *data;
struct reset_control *hdmitx_apb;
struct reset_control *hdmitx_ctrl;
struct reset_control *hdmitx_phy;
@@ -174,6 +192,12 @@ static unsigned int dw_hdmi_top_read(struct meson_dw_hdmi
*dw_hdmi,
return data;
}
+static unsigned int dw_hdmi_g12a_top_read(struct meson_dw_hdmi *dw_hdmi,
+ unsigned int addr)
+{
+ return readl(dw_hdmi->hdmitx + HDMITX_TOP_G12A_OFFSET + (addr << 2));
+}
+
static inline void dw_hdmi_top_write(struct meson_dw_hdmi *dw_hdmi,
unsigned int addr, unsigned int data)
{
@@ -191,18 +215,24 @@ static inline void dw_hdmi_top_write(struct meson_dw_hdmi
*dw_hdmi,
spin_unlock_irqrestore(_lock, flags);
}
+static inline void dw_hdmi_g12a_top_write(struct meson_dw_hdmi *dw_hdmi,
+ unsigned int addr, unsigned int data)
+{
+ writel(data, dw_hdmi->hdmitx + HDMITX_TOP_G12A_OFFSET + (addr << 2));
+}
+
/* Helper to change specific bits in PHY registers */
static inline void dw_hdmi_top_write_bits(struct meson_dw_hdmi *dw_hdmi,
unsigned int addr,
unsigned int mask,
unsigned int val)
{
- unsigned int data = dw_hdmi_top_read(dw_hdmi, addr);
+ unsigned int data = dw_hdmi->data->top_read(dw_hdmi, addr);
data &= ~mask;
data |= val;
- dw_hdmi_top_write(dw_hdmi, addr, data);
+ dw_hdmi->data->top_write(dw_hdmi, addr, data);
}
static unsigned int dw_hdmi_dwc_read(struct meson_dw_hdmi *dw_hdmi,
@@ -226,6 +256,12 @@ static unsigned int dw_hdmi_dwc_read(struct meson_dw_hdmi
*dw_hdmi,
return data;
}
+static unsigned int dw_hdmi_g12a_dwc_read(struct meson_dw_hdmi *dw_hdmi,
+ unsigned int addr)
+{
+ return readb(dw_hdmi->hdmitx + addr);
+}
+
static inline void dw_hdmi_dwc_write(struct meson_dw_hdmi *dw_hdmi,
unsigned int addr, unsigned int data)
{
@@ -243,18 +279,24 @@ static inline void dw_hdmi_dwc_write(struct meson_dw_hdmi
*dw_hdmi,
spin_unlock_irqrestore(_lock, flags);
}
+static inline void dw_hdmi_g12a_dwc_write(struct meson_dw_hdmi *dw_hdmi,
+
[PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer
The Meson G12A SoCs uses the exact same CVBS encoder except a simple
CVBS DAC register offset and settings delta.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_venc.c | 11 +--
drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++---
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 66d73a932d19..6faca7313339 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -73,7 +73,9 @@
/* HHI Registers */
#define HHI_GCLK_MPEG2 0x148 /* 0x52 offset in data sheet */
#define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
+#define HHI_VDAC_CNTL0_G12A0x2EC /* 0xbd offset in data sheet */
#define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
+#define HHI_VDAC_CNTL1_G12A0x2F0 /* 0xbe offset in data sheet */
#define HHI_HDMI_PHY_CNTL0 0x3a0 /* 0xe8 offset in data sheet */
struct meson_cvbs_enci_mode meson_cvbs_enci_pal = {
@@ -1675,8 +1677,13 @@ void meson_venc_disable_vsync(struct meson_drm *priv)
void meson_venc_init(struct meson_drm *priv)
{
/* Disable CVBS VDAC */
- regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
- regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 8);
+ } else {
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
+ }
/* Power Down Dacs */
writel_relaxed(0xff, priv->io_base + _REG(VENC_VDAC_SETTING));
diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c
b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index d622d817b6df..2c5341c881c4 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -37,7 +37,9 @@
/* HHI VDAC Registers */
#define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
+#define HHI_VDAC_CNTL0_G12A0x2EC /* 0xbd offset in data sheet */
#define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
+#define HHI_VDAC_CNTL1_G12A0x2F0 /* 0xbe offset in data sheet */
struct meson_venc_cvbs {
struct drm_encoder encoder;
@@ -166,8 +168,13 @@ static void meson_venc_cvbs_encoder_disable(struct
drm_encoder *encoder)
struct meson_drm *priv = meson_venc_cvbs->priv;
/* Disable CVBS VDAC */
- regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
- regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
+ } else {
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
+ }
}
static void meson_venc_cvbs_encoder_enable(struct drm_encoder *encoder)
@@ -179,13 +186,17 @@ static void meson_venc_cvbs_encoder_enable(struct
drm_encoder *encoder)
/* VDAC0 source is not from ATV */
writel_bits_relaxed(BIT(5), 0, priv->io_base + _REG(VENC_VDAC_DACSEL0));
- if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu"))
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu")) {
regmap_write(priv->hhi, HHI_VDAC_CNTL0, 1);
- else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
-meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
+ } else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
+meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0xf0001);
-
- regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
+ } else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0x906001);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
+ }
}
static void meson_venc_cvbs_encoder_mode_set(struct drm_encoder *encoder,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/meson: Add G12A support for OSD1 Plane
Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the
previous SoCs) and a brand new OSD plane blender module.
This patch uses the same OSD1 plane G12A, using the exact same scaler
and OSD1 setup registers, except using the new blender register to
disable the plane.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_plane.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index b7786218cb10..bf8f1fab63aa 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -294,6 +294,13 @@ static void meson_plane_atomic_update(struct drm_plane
*plane,
priv->viu.osd1_blk0_cfg[3] = ((dest.x2 - 1) << 16) | dest.x1;
priv->viu.osd1_blk0_cfg[4] = ((dest.y2 - 1) << 16) | dest.y1;
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ priv->viu.osd_blend_din0_scope_h = ((dest.x2 - 1) << 16) |
dest.x1;
+ priv->viu.osd_blend_din0_scope_v = ((dest.y2 - 1) << 16) |
dest.y1;
+ priv->viu.osb_blend0_size = dst_h << 16 | dst_w;
+ priv->viu.osb_blend1_size = dst_h << 16 | dst_w;
+ }
+
/* Update Canvas with buffer address */
gem = drm_fb_cma_get_gem_obj(fb, 0);
@@ -320,8 +327,12 @@ static void meson_plane_atomic_disable(struct drm_plane
*plane,
struct meson_drm *priv = meson_plane->priv;
/* Disable OSD1 */
- writel_bits_relaxed(VPP_OSD1_POSTBLEND, 0,
- priv->io_base + _REG(VPP_MISC));
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ writel_bits_relaxed(BIT(0) | BIT(21), 0,
+ priv->io_base + _REG(VIU_OSD1_CTRL_STAT));
+ else
+ writel_bits_relaxed(VPP_OSD1_POSTBLEND, 0,
+ priv->io_base + _REG(VPP_MISC));
meson_plane->enabled = false;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/meson: Add G12A Support for VPP setup
Amlogic G12A needs a different VPP setup code, handle it here.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_vpp.c | 51 ++-
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vpp.c
b/drivers/gpu/drm/meson/meson_vpp.c
index f9efb431e953..8c52a3455ef4 100644
--- a/drivers/gpu/drm/meson/meson_vpp.c
+++ b/drivers/gpu/drm/meson/meson_vpp.c
@@ -112,32 +112,39 @@ void meson_vpp_init(struct meson_drm *priv)
writel_relaxed(0x2, priv->io_base + _REG(VPP_DOLBY_CTRL));
writel_relaxed(0x1020080,
priv->io_base + _REG(VPP_DUMMY_DATA1));
- }
+ } else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ writel_relaxed(0xf, priv->io_base + _REG(DOLBY_PATH_CTRL));
/* Initialize vpu fifo control registers */
- writel_relaxed(readl_relaxed(priv->io_base + _REG(VPP_OFIFO_SIZE)) |
- 0x77f, priv->io_base + _REG(VPP_OFIFO_SIZE));
+ if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
+ writel_relaxed(0xfff << 20 | 0x1000,
+ priv->io_base + _REG(VPP_OFIFO_SIZE));
+ else
+ writel_relaxed(readl_relaxed(priv->io_base +
_REG(VPP_OFIFO_SIZE)) |
+ 0x77f, priv->io_base + _REG(VPP_OFIFO_SIZE));
writel_relaxed(0x08080808, priv->io_base + _REG(VPP_HOLD_LINES));
- /* Turn off preblend */
- writel_bits_relaxed(VPP_PREBLEND_ENABLE, 0,
- priv->io_base + _REG(VPP_MISC));
-
- /* Turn off POSTBLEND */
- writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
- priv->io_base + _REG(VPP_MISC));
-
- /* Force all planes off */
- writel_bits_relaxed(VPP_OSD1_POSTBLEND | VPP_OSD2_POSTBLEND |
- VPP_VD1_POSTBLEND | VPP_VD2_POSTBLEND |
- VPP_VD1_PREBLEND | VPP_VD2_PREBLEND, 0,
- priv->io_base + _REG(VPP_MISC));
-
- /* Setup default VD settings */
- writel_relaxed(4096,
- priv->io_base + _REG(VPP_PREBLEND_VD1_H_START_END));
- writel_relaxed(4096,
- priv->io_base + _REG(VPP_BLEND_VD2_H_START_END));
+ if (!meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
+ /* Turn off preblend */
+ writel_bits_relaxed(VPP_PREBLEND_ENABLE, 0,
+ priv->io_base + _REG(VPP_MISC));
+
+ /* Turn off POSTBLEND */
+ writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
+ priv->io_base + _REG(VPP_MISC));
+
+ /* Force all planes off */
+ writel_bits_relaxed(VPP_OSD1_POSTBLEND | VPP_OSD2_POSTBLEND |
+ VPP_VD1_POSTBLEND | VPP_VD2_POSTBLEND |
+ VPP_VD1_PREBLEND | VPP_VD2_PREBLEND, 0,
+ priv->io_base + _REG(VPP_MISC));
+
+ /* Setup default VD settings */
+ writel_relaxed(4096,
+ priv->io_base +
_REG(VPP_PREBLEND_VD1_H_START_END));
+ writel_relaxed(4096,
+ priv->io_base +
_REG(VPP_BLEND_VD2_H_START_END));
+ }
/* Disable Scalers */
writel_relaxed(0, priv->io_base + _REG(VPP_OSD_SC_CTRL0));
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/3] Mixel DPHY support for i.MX8
tl;dr: v7 fixes a build issued due to the lack of a HAS_IOMEM
This adds initial support for the Mixel IP based mipi dphy as found on i.MX8
processors. It has support for the i.MX8MQ, support for other variants can be
added - once the platform specific parts are in - via the provided devdata.
The driver is somewhat based on what's found in NXPs BSP.
Public documentation on the DPHY's registers is currently thin in the i.MX8
reference manuals (even on the i.MX8QXP form 11/18) so most of the values were
taken from existing drivers. Newer NXP drivers have a bit more details so where
possible the timings are calculated and validated.
I've also sent out an initial version of a NWL mipi dsi host controller driver
using this:
https://lists.freedesktop.org/archives/dri-devel/2019-March/209685.html
Robert Chiras (the author of the corresponding driver in NXPs vendor tree) got
this driver to work in his tree as well:
https://www.spinics.net/lists/arm-kernel/msg711950.html
Chages from v6
* Depend on HAS_IOMEM (fixes a build problem on UM spotted by kbuild)
Chages from v5
* Fix build problems on mips (spotted by the kbuild test robot) by using u32
consistently and long long for lp_t.
Changes from v4
* Build by default on ARCH_MXC && ARM64
Changes form v3
* Check correct variable after devm_ioremap_resource
* Add Robert Chiras as Co-authored-by since he's the author
of the driver in NXPs BSP.
Changes from v2
* As per review comments from Fabio Estevam
* KConfig: select REGMAP_MMIO
* Drop phy_read
* Don't make phy_write inline
* Remove duplicate debugging output
* Comment style and typo fixes
* Add #defines's for PLL lock timing values
* Return correct error value when PLL fails to lock
* Check error when enabling clock
* Use devm_ioremap_resource
* As per review comments from Robert Chiras
* Deassert PD_DPHY after PLL lock (as per mixel ref manual)
* Assert PD_{DPHY,PLL} before power on (as per mixel ref manual)manual
* Add exit phy_op to reset CN/CM/CO
Changes from v1
* As per review comments from Fabio Estevam
* Kconfig: tristate mixel dphy support.
* Drop unused 'ret' in mixel_dphy_ref_power_off.
* Match values of DPHY_RXL{PRP,DRP} to those of
https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_4.14.78_1.0.0_ga
The previous values were based on 4.9.
* Use resource size on devm_ioremap, we have that in dt already.
* Use regmap so it's simple to dump the registers.
* Use regmap_read_poll_timeout instead of open coded loop.
* Add undocumented rxhs_settle register
* As per review comments from Sam Ravnborg
* Move driver to d/phy/freescale/
* Move SPDX-License-Identifier to top of file.
* Drop '/* #define DEBUG 1 */'.
* Use GPL-2.0+ since the vendor driver uses that as well.
* Drop the mutex, register access is now protected by regmap.
* Fix various style / indentation issues.
* Check for register read, write and ioremap errors
* Improve phy timing calculations
* Use LP clock rate where sensible, check for errors
* Use ad hoc forumulas for timings involving hs clock
* Switch from dphy_ops to devdata. Other i.MX8 variants
differ in register layout too
* Add Mixel Inc to vendor-prefixes.txt
Guido Günther (3):
dt-bindings: Add vendor prefix for Mixel Inc
dt-bindings: phy: Add documentation for mixel dphy
phy: Add driver for mixel dphy found on imx8
.../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/phy/freescale/Kconfig | 11 +
drivers/phy/freescale/Makefile| 1 +
.../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 506 ++
5 files changed, 548 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/3] dt-bindings: phy: Add documentation for mixel dphy
Add support for the MIXEL DPHY IP as found in the NXP's i.MX8MQ.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
.../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
new file mode 100644
index ..d3646580412a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
@@ -0,0 +1,29 @@
+Mixel DSI PHY for i.MX8
+
+The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the
+MIPI-DSI IP from Northwest Logic). It represents the physical layer for the
+electrical signals for DSI.
+
+Required properties:
+- compatible: Must be:
+ - "mixel,imx8mq-mipi-dphy"
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must contain the following entries:
+ - "phy_ref": phandle and specifier referring to the DPHY ref clock
+- reg: the register range of the PHY controller
+- #phy-cells: number of cells in PHY, as defined in
+ Documentation/devicetree/bindings/phy/phy-bindings.txt
+ this must be <0>
+
+Optional properties:
+- power-domains: phandle to power domain
+
+Example:
+ mipi_dphy: mipi_dphy@30A0030 {
+ compatible = "mixel,imx8mq-mipi-dphy";
+ clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
+ clock-names = "phy_ref";
+ reg = <0x30A00300 0x100>;
+ power-domains = <_mipi0>;
+ #phy-cells = <0>;
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/3] phy: Add driver for mixel dphy found on imx8
This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
this is an IP core it will likely be found on others in the future. So
instead of adding this to the nwl host driver make it a generic PHY
driver.
The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added once the necessary system controller bits are in via
mixel_dphy_devdata.
Co-authored-by: Robert Chiras
Signed-off-by: Guido Günther
---
drivers/phy/freescale/Kconfig | 11 +
drivers/phy/freescale/Makefile| 1 +
.../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 506 ++
3 files changed, 518 insertions(+)
create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 832670b4952b..a111b130f9d2 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -3,3 +3,14 @@ config PHY_FSL_IMX8MQ_USB
depends on OF && HAS_IOMEM
select GENERIC_PHY
default ARCH_MXC && ARM64
+
+config PHY_MIXEL_MIPI_DPHY
+ tristate "Mixel MIPI DSI PHY support"
+ depends on OF && HAS_IOMEM
+ select GENERIC_PHY
+ select GENERIC_PHY_MIPI_DPHY
+ select REGMAP_MMIO
+ default ARCH_MXC && ARM64
+ help
+ Enable this to add support for the Mixel DSI PHY as found
+ on NXP's i.MX8 family of SOCs.
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index dc2b3f1f2f80..07491c926a2c 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
+obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
new file mode 100644
index ..fd487a9e5a35
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -0,0 +1,506 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2017,2018 NXP
+ * Copyright 2019 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DPHY registers */
+#define DPHY_PD_DPHY 0x00
+#define DPHY_M_PRG_HS_PREPARE 0x04
+#define DPHY_MC_PRG_HS_PREPARE 0x08
+#define DPHY_M_PRG_HS_ZERO 0x0c
+#define DPHY_MC_PRG_HS_ZERO0x10
+#define DPHY_M_PRG_HS_TRAIL0x14
+#define DPHY_MC_PRG_HS_TRAIL 0x18
+#define DPHY_PD_PLL0x1c
+#define DPHY_TST 0x20
+#define DPHY_CN0x24
+#define DPHY_CM0x28
+#define DPHY_CO0x2c
+#define DPHY_LOCK 0x30
+#define DPHY_LOCK_BYP 0x34
+#define DPHY_REG_BYPASS_PLL0x4C
+
+#define MBPS(x) ((x) * 100)
+
+#define DATA_RATE_MAX_SPEED MBPS(1500)
+#define DATA_RATE_MIN_SPEED MBPS(80)
+
+#define PLL_LOCK_SLEEP 10
+#define PLL_LOCK_TIMEOUT 1000
+
+#define CN_BUF 0xcb7a89c0
+#define CO_BUF 0x63
+#define CM(x) ( \
+ ((x) < 32)?0xe0|((x)-16) : \
+ ((x) < 64)?0xc0|((x)-32) : \
+ ((x) < 128)?0x80|((x)-64) : \
+ ((x) - 128))
+#define CN(x) (((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
+#define CO(x) ((CO_BUF)>>(8-(x))&0x3)
+
+/* PHY power on is active low */
+#define PWR_ON 0
+#define PWR_OFF1
+
+enum mixel_dphy_devtype {
+ MIXEL_IMX8MQ,
+};
+
+struct mixel_dphy_devdata {
+ u8 reg_tx_rcal;
+ u8 reg_auto_pd_en;
+ u8 reg_rxlprp;
+ u8 reg_rxcdrp;
+ u8 reg_rxhs_settle;
+};
+
+static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
+ [MIXEL_IMX8MQ] = {
+ .reg_tx_rcal = 0x38,
+ .reg_auto_pd_en = 0x3c,
+ .reg_rxlprp = 0x40,
+ .reg_rxcdrp = 0x44,
+ .reg_rxhs_settle = 0x48,
+ },
+};
+
+struct mixel_dphy_cfg {
+ /* DPHY PLL parameters */
+ u32 cm;
+ u32 cn;
+ u32 co;
+ /* DPHY register values */
+ u8 mc_prg_hs_prepare;
+ u8 m_prg_hs_prepare;
+ u8 mc_prg_hs_zero;
+ u8 m_prg_hs_zero;
+ u8 mc_prg_hs_trail;
+ u8 m_prg_hs_trail;
+ u8 rxhs_settle;
+};
+
+struct mixel_dphy_priv {
+ struct mixel_dphy_cfg cfg;
+ struct regmap *regs;
+ struct clk *phy_ref_clk;
+ const struct mixel_dphy_devdata *devdata;
+};
+
+static const struct regmap_config mixel_dphy_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = DPHY_REG_BYPASS_PLL,
+ .name = "mipi-dphy",
+};
+
+static int phy_write(struct phy *phy, u32 value, unsigned int reg)
+{
+ struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
+ int ret;
+
+ ret =
Re: [PATCH v4 2/3] dt-bindings: Add Rocktech jh057n00900 panel bindings
On Mon, Mar 25, 2019 at 11:06 AM Guido Günther wrote:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> @@ -0,0 +1,18 @@
> +Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "rocktech,jh057n00900"
> +- reg: DSI virtual channel of the peripheral
> +- reset-gpios: panel reset gpio
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + _dsi {
> + panel {
> + compatible = "rocktech,jh057n00900";
> + reg = <0>;
Passing the reg property without its corresponding @0 would cause a
dtc warning when building with W=1.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/panel: Add Rocktech jh057n00900 panel driver
Support Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel. It is a MIPI
DSI video mode panel.
The panel seems to use a Sitronix ST7703 look alike (most of the
commands look similar to the ST7703's data sheet but use a different
number of parameters). The initial version of the DSI init sequence
(including sleeps) were provided by the vendor. Sleeps were reduced
considerably though to speed up initialization.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 13 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-rocktech-jh057n00900.c| 386 ++
4 files changed, 406 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f1f505920df..57968eabe844 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4999,6 +4999,12 @@ S: Orphan / Obsolete
F: drivers/gpu/drm/r128/
F: include/uapi/drm/r128_drm.h
+DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
+M: Guido Günther
+S: Maintained
+F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
+
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f53f817356db..645ceb5776a9 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -149,6 +149,19 @@ config DRM_PANEL_RAYDIUM_RM68200
Say Y here if you want to enable support for Raydium RM68200
720x1280 DSI video mode panel.
+config DRM_PANEL_ROCKTECH_JH057N00900
+ tristate "Rocktech JH057N00900 MIPI touchscreen panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Rocktech JH057N00900
+ MIPI DSI panel as e.g. used in the Librem 5 devkit. It has a
+ resolution of 720x1440 pixels, a built in backlight and touch
+ controller.
+ Touch input support is provided by the goodix driver and needs to be
+ selected separately.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7834947a53b0..0e739bbc44b8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) +=
panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
+obj-$(CONFIG_DRM_PANEL_ROCKTECH_JH057N00900) += panel-rocktech-jh057n00900.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
new file mode 100644
index ..158a6d548068
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
@@ -0,0 +1,386 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockteck jh057n00900 5.5" MIPI-DSI panel driver
+ *
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-rocktech-jh057n00900"
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+struct jh057n {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct backlight_device *backlight;
+ bool prepared;
+
+ struct dentry *debugfs;
+};
+
+static inline struct jh057n *panel_to_jh057n(struct drm_panel *panel)
+{
+ return container_of(panel, struct jh057n, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
[PATCH v4 1/3] dt-bindings: Add vendor prefix for ROCKTECH DISPLAYS LIMITED
Add ROCKTECH DISPLAYS LIMITED (https://rocktech.com.hk) LCD panel supplier. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index fae55f50b2d3..326a4b278186 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -346,6 +346,7 @@ ricoh Ricoh Co. Ltd. rikomagic Rikomagic Tech Corp. Ltd riscv RISC-V Foundation rockchip Fuzhou Rockchip Electronics Co., Ltd +rocktech ROCKTECH DISPLAYS LIMITED rohm ROHM Semiconductor Co., Ltd ronbo Ronbo Electronics roofullShenzhen Roofull Technology Co, Ltd -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator
https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #12 from e88z4 --- I usually build mesa master weekly since November 2018. This bug can be reproduced with latest Mesa from git master branch. Do you want me to try to build 18.3.5 and reproduce it? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator
https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #11 from glencoesm...@hotmail.com --- Can you reproduce the bug on 18.3.5? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/vc4: Disable V3D interactions if the v3d component didn't probe.
Hi,
On Wed, 2019-02-20 at 13:03 -0800, Eric Anholt wrote:
> One might want to use the VC4 display stack without using Mesa.
> Similar to the debugfs fixes for not having all of the possible
> display bits enabled, make sure you can't oops in vc4 if v3d isn't
> enabled.
See a comment below.
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 11 +++
> drivers/gpu/drm/vc4/vc4_gem.c | 10 ++
> drivers/gpu/drm/vc4/vc4_irq.c | 9 +
> drivers/gpu/drm/vc4/vc4_perfmon.c | 18 ++
> 4 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 1927d1b756f5..de1d0ce11831 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -72,6 +72,9 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void
> *data,
> if (args->pad != 0)
> return -EINVAL;
>
> + if (!vc4->v3d)
> + return -EINVAL;
> +
> switch (args->param) {
> case DRM_VC4_PARAM_V3D_IDENT0:
> ret = pm_runtime_get_sync(>v3d->pdev->dev);
> @@ -251,6 +254,7 @@ static int vc4_drm_bind(struct device *dev)
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm;
> struct vc4_dev *vc4;
> + struct device_node *node;
> int ret = 0;
>
> dev->coherent_dma_mask = DMA_BIT_MASK(32);
> @@ -259,6 +263,13 @@ static int vc4_drm_bind(struct device *dev)
> if (!vc4)
> return -ENOMEM;
>
> + /* If VC4 V3D is missing, don't advertise render nodes. */
> + node = of_find_compatible_node(NULL, NULL, "brcm,bcm2835-v3d");
It looks like we support more compatibles than this one, so it could be
worth having a separate helper to check if we can find a v3d-compatible
node. It could certainly reuse the platform driver's of_match_table;
With that fixed, this is:
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> + if (node)
> + of_node_put(node);
> + else
> + vc4_drm_driver.driver_features &= ~DRIVER_RENDER;
> +
> drm = drm_dev_alloc(_drm_driver, dev);
> if (IS_ERR(drm))
> return PTR_ERR(drm);
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 5ee5bf7fedf7..8d816e5ed762 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -74,6 +74,11 @@ vc4_get_hang_state_ioctl(struct drm_device *dev, void
> *data,
> u32 i;
> int ret = 0;
>
> + if (!vc4->v3d) {
> + DRM_DEBUG("VC4_GET_HANG_STATE with no VC4 V3D probed\n");
> + return -EINVAL;
> + }
> +
> spin_lock_irqsave(>job_lock, irqflags);
> kernel_state = vc4->hang_state;
> if (!kernel_state) {
> @@ -1124,6 +1129,11 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
> struct dma_fence *in_fence;
> int ret = 0;
>
> + if (!vc4->v3d) {
> + DRM_DEBUG("VC4_SUBMIT_CL with no VC4 V3D probed\n");
> + return -EINVAL;
> + }
> +
> if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
>VC4_SUBMIT_CL_FIXED_RCL_ORDER |
>VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
> diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
> index 4cd2ccfe15f4..ffd0a4388752 100644
> --- a/drivers/gpu/drm/vc4/vc4_irq.c
> +++ b/drivers/gpu/drm/vc4/vc4_irq.c
> @@ -229,6 +229,9 @@ vc4_irq_preinstall(struct drm_device *dev)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
>
> + if (!vc4->v3d)
> + return;
> +
> init_waitqueue_head(>job_wait_queue);
> INIT_WORK(>overflow_mem_work, vc4_overflow_mem_work);
>
> @@ -243,6 +246,9 @@ vc4_irq_postinstall(struct drm_device *dev)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
>
> + if (!vc4->v3d)
> + return 0;
> +
> /* Enable both the render done and out of memory interrupts. */
> V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
>
> @@ -254,6 +260,9 @@ vc4_irq_uninstall(struct drm_device *dev)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
>
> + if (!vc4->v3d)
> + return;
> +
> /* Disable sending interrupts for our driver's IRQs. */
> V3D_WRITE(V3D_INTDIS, V3D_DRIVER_IRQS);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c
> b/drivers/gpu/drm/vc4/vc4_perfmon.c
> index 495150415020..6562d3d30b20 100644
> --- a/drivers/gpu/drm/vc4/vc4_perfmon.c
> +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
> @@ -100,12 +100,18 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file)
> int vc4_perfmon_create_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv)
> {
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_file *vc4file = file_priv->driver_priv;
> struct drm_vc4_perfmon_create *req = data;
> struct vc4_perfmon *perfmon;
> unsigned int i;
> int
[PULL] drm-intel-next
Hi Dave & Daniel, First batch of features for 5.2, tagged last week. Most notably there are a lot of Icelake fixes that finally lead to removal of alpha_support protection for it. We're also adding Cometlake PCI IDs (Gen9 ~= Coffeelake), so those platforms should be supported. Then we have HDCP 2.2 support, PSR2 enabling by default and VBT data parsing fixes on display side. On GT side there is an option to allow Mesa to better recover from GPU hangs and fixes to the mmap behaviour. Then the usual assortment of fixes and some prep code for Virtual Engine work, parts of which will follow in next PR. Best Regards, Joonas PS. This contains a backmerge and Maarten's topic/hdr-format topic branch merged twice + MEI topic branch merged from Daniel. *** drm-intel-next-2019-03-20: UAPI Changes: - Report an error early instead of SIGBUS later when mmap beyond BO size Core Changes: - This includes backmerge of drm-next and two merges of Maarten's topic/hdr-formats Driver Changes: - Add Comet Lake (Gen9) PCI IDs to Coffee Lake ID list (Anusha) - Add missing ICL PCI ID (Jose) - Fix legacy gamma mode for ICL (Ville) - Assume eDP is present on port A when there is no VBT (Thomas) - Corrections to eDP training patterns (Jose) - Fix PSR2 selective update corruption after PSR1 setup (Jose) - Fix CRC mismatch error for DP link layer compliance (Aditya) - Fix CNL DPLL readout and clean up code (Ville) - Turn off the CUS when turning off a HDR plane (Ville) - Avoid a race with execlist tasklet during race (Chris) - Add missing CSC readout and clean up code (Ville) - Avoid unnecessary wakeref during debugfs/drop_caches/set (Chris, Caz) - Hold references to ring/HW context/context explicitly when used (Chris) - Assume next platforms inherit old platform (Rodrigo) - Use HWS indices rather than addresses for breadcrumbs (Chris) - Add REG_BIT/REG_GENMASK and REG_FIELD_PREP macros (Jani) - Convert crept in C99 types to kernel fixed size types (Jani) - Avoid passing full dev_priv in forcewake functions (Daniele) - Reset GuC on GPU reset (Sujaritha) - Rework MG and Combo PLLs to vfuncs (Lucas) - Explicitly track ppGTT size (Chris, Bob) - Coding style improvements and code modularization (Ville) - Selftest and debugging improvements (Chris) drm-intel-next-2019-03-11: UAPI Changes: - Disallow creating user context when GPU is wedged (Chris) Mesa: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.html - Remove engine instance from GEM_BUSY extended info (Chris) Only user of extended info is ddx/sna and it doesn't use instance Driver Changes: - Remove alpha_support protection for ICL - HDCP 2.2 support (Ramalingam) - HDMI infoframe support (Ville) - Enable PSR2 by default (Jose) - Support CRC on more planes on SKL+ (Ville) - Read out memory type on Gen9+ (Ville) - Pretend to only have 1 DBuf slice on ICL for now (Imre) - Fix gamma mode state check on ICL (Uma) - Fix the state checker for ICL Y planes (Ville) - Force modeset when resetting HDMI link (Jose) - Remove broken DP CRC support on g4x (Ville) - Remove last global seqno and use random number in hangcheck to identify progress (Chris) - Suppress mere WAIT and redundant preemption (Chris) - Fix Bugzilla #109580: Limit deboosting and boosting for more GPU frequency hysteresis (Chris, Lyude) - Use HW semaphores for inter-engine synchronization on Gen8+ (Chris) - Avoid reporting GPU wedged while check is still in progress (Chris) - Always sample an active ringbuffer in PMU (Chris) - Report engines are idle if already parked (Chris) - Default to Thread Group preemption for compute workloads on ICL (Michal) - Fix a regression caused by the mmap VMA check (Tvrtko, Guenter) - Remove assumptions about request ordering (Chris) - Use single point of truth for PPS divisor register (Jani) - Selftest improvements and CI bug fixes (Chris) - Prepare codebase for Virtual Engine (Chris) - Populate pipe_offsets[] & co. accurately (Ville) - Make request/object/vma allocation caches global (Chris) - Remove redundant likely/unlikely annotations (Chengguang) - Reset locking fixes (Chris) - GuC code refactoring (Sujaritha) - Skip scanning signalers for inflight requests (Chris) - Remove second level open-coded rcu work (Chris) - Order if-ladders from newer to older platform (Rodrigo) - Move MG pll hw_state readout / AUX mask code to separate function (Lucas) - Track active contexts and pinning in context (Chris) drm-intel-next-2019-02-20: UAPI Changes: - Optionally disable automatic recovery after a GPU reset (Chris) Mesa changes at: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html - Added reminders about not leaving holes to uAPI number sequences Cross-subsystem Changes: - Includes the backmerge of drm-next and merge of Daniel's mei-hdcp/i915 component interface work Driver Changes: - Correctly interpret Raw VBT Data Address on OpRegion version 2.1 (ICL+) (Jani) - Fix to actually configure untiled fbdev displays (Maarten,
Re: [PATCH] drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups
On 25/03/2019 12:37, Andrzej Hajda wrote:
> On 15.03.2019 10:54, Neil Armstrong wrote:
>> This patch is an attempt to limit HDMI 2.0 SCDC setup when :
>> - the SoC embeds an HDMI 1.4 only controller
>> - the EDID supports SCDC but not scrambling
>> - the EDID supports SCDC scrambling but not for low TMDS bit rates,
>> while only supporting low TMDS bit rates
>>
>> This to avoid communicating with the SCDC DDC slave uncessary, and
>> setting the DW-HDMI TMDS Scrambler setup when not supported by the
>> underlying hardware.
>>
>> Reported-by: Rob Herring
>> Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
>> support")
>> Signed-off-by: Neil Armstrong
>> ---
>>
>> Rob,
>>
>> this patch should also solve your issue with your 11' display, could you
>> test it ?
>> If this works, I will focus on the underlying issue where the RK3399 SoC
>> freezes in your setup.
>>
>> Thanks,
>> Neil
>>
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 ---
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index a63e5f0dae56..db761329a1e3 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -1037,6 +1037,31 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
>> unsigned short data,
>> }
>> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>>
>> +/* Filter out invalid setups to avoid configuring SCDC and scrambling */
>> +static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
>> +{
>> +struct drm_display_info *display = >connector.display_info;
>> +
>> +/* Completely disable SCDC support for older controllers */
>> +if (hdmi->version < 0x200a)
>> +return false;
>> +
>> +/* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
>> +if (!display->hdmi.scdc.supported ||
>> +!display->hdmi.scdc.scrambling.supported)
>> +return false;
>> +
>> +/*
>> + * Disable if display only support low TMDS rates and scrambling
>> + * for low rates is not supported either
>> + */
>> +if (!display->hdmi.scdc.scrambling.low_rates &&
>> +display->max_tmds_clock <= 34)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> /*
>> * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
>> * - The Source shall suspend transmission of the TMDS clock and data
>> @@ -1055,7 +1080,7 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
>> *hdmi)
>> unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
>>
>> /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
>> -if (hdmi->connector.display_info.hdmi.scdc.supported) {
>> +if (dw_hdmi_support_scdc(hdmi)) {
>> if (mtmdsclock > HDMI14_MAX_TMDSCLK)
>> drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
>> else
>> @@ -1579,8 +1604,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>>
>> /* Set up HDMI_FC_INVIDCONF */
>> inv_val = (hdmi->hdmi_data.hdcp_enable ||
>> - vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
>> - hdmi_info->scdc.scrambling.low_rates ?
>> + (dw_hdmi_support_scdc(hdmi) &&
>> +(vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
>> + hdmi_info->scdc.scrambling.low_rates)) ?
>> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
>> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);
>
>
> The condition is hard to read, but I have no idea atm how make it
> compact and pretty :)
I made my best to make it barely readable...
We may need to reword this condition since on the DW-HMI in the Allwinner
H6, this is no more needed for scrambling !
>
> Anyway:
>
> Reviewed-by: Andrzej Hajda
>
>
> As I remember you can queue it to drm-misc, if not I can do it, just let
> me know.
I can and I'm queuing it right now, thanks for the review !
Neil
>
>
> --
> Regards
> Andrzej
>
>
>
>>
>> @@ -1646,7 +1672,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>> }
>>
>> /* Scrambling Control */
>> -if (hdmi_info->scdc.supported) {
>> +if (dw_hdmi_support_scdc(hdmi)) {
>> if (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
>> hdmi_info->scdc.scrambling.low_rates) {
>> /*
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: task hung in process_measurement
On 23/03/2019 08:58, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 8fe5616b20e5742bb5fee0e77dffe2fc76ac92a0
> Author: Jyri Sarha
> Date: Tue Jun 14 08:43:30 2016 +
>
> drm/tilcdc: Restore old dpms state in pm_resume()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10daff1b20
> start commit: 291d0e5d Merge tag 'for-linus-20180929' of
> git://git.kerne..
> git tree: upstream
> final crash: https://syzkaller.appspot.com/x/report.txt?x=12daff1b20
> console output: https://syzkaller.appspot.com/x/log.txt?x=14daff1b20
> kernel config: https://syzkaller.appspot.com/x/.config?x=a8212f992609a887
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=cdc562bc26a2b2b0a94f
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=140e285e40
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1237fe8140
>
> Reported-by: syzbot+cdc562bc26a2b2b0a...@syzkaller.appspotmail.com
> Fixes: 8fe5616b20e5 ("drm/tilcdc: Restore old dpms state in pm_resume()")
>
> For information about bisection process see:
> https://goo.gl/tpsmEJ#bisection
I don't think the patch from Jyri is related to the crash here.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups
On 15.03.2019 10:54, Neil Armstrong wrote:
> This patch is an attempt to limit HDMI 2.0 SCDC setup when :
> - the SoC embeds an HDMI 1.4 only controller
> - the EDID supports SCDC but not scrambling
> - the EDID supports SCDC scrambling but not for low TMDS bit rates,
> while only supporting low TMDS bit rates
>
> This to avoid communicating with the SCDC DDC slave uncessary, and
> setting the DW-HDMI TMDS Scrambler setup when not supported by the
> underlying hardware.
>
> Reported-by: Rob Herring
> Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
> support")
> Signed-off-by: Neil Armstrong
> ---
>
> Rob,
>
> this patch should also solve your issue with your 11' display, could you
> test it ?
> If this works, I will focus on the underlying issue where the RK3399 SoC
> freezes in your setup.
>
> Thanks,
> Neil
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 ---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a63e5f0dae56..db761329a1e3 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,6 +1037,31 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data,
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>
> +/* Filter out invalid setups to avoid configuring SCDC and scrambling */
> +static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
> +{
> + struct drm_display_info *display = >connector.display_info;
> +
> + /* Completely disable SCDC support for older controllers */
> + if (hdmi->version < 0x200a)
> + return false;
> +
> + /* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
> + if (!display->hdmi.scdc.supported ||
> + !display->hdmi.scdc.scrambling.supported)
> + return false;
> +
> + /*
> + * Disable if display only support low TMDS rates and scrambling
> + * for low rates is not supported either
> + */
> + if (!display->hdmi.scdc.scrambling.low_rates &&
> + display->max_tmds_clock <= 34)
> + return false;
> +
> + return true;
> +}
> +
> /*
> * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
> * - The Source shall suspend transmission of the TMDS clock and data
> @@ -1055,7 +1080,7 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
> *hdmi)
> unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
>
> /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> - if (hdmi->connector.display_info.hdmi.scdc.supported) {
> + if (dw_hdmi_support_scdc(hdmi)) {
> if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> else
> @@ -1579,8 +1604,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>
> /* Set up HDMI_FC_INVIDCONF */
> inv_val = (hdmi->hdmi_data.hdcp_enable ||
> -vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> -hdmi_info->scdc.scrambling.low_rates ?
> +(dw_hdmi_support_scdc(hdmi) &&
> + (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> + hdmi_info->scdc.scrambling.low_rates)) ?
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);
The condition is hard to read, but I have no idea atm how make it
compact and pretty :)
Anyway:
Reviewed-by: Andrzej Hajda
As I remember you can queue it to drm-misc, if not I can do it, just let
me know.
--
Regards
Andrzej
>
> @@ -1646,7 +1672,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> }
>
> /* Scrambling Control */
> - if (hdmi_info->scdc.supported) {
> + if (dw_hdmi_support_scdc(hdmi)) {
> if (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> hdmi_info->scdc.scrambling.low_rates) {
> /*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/atomic-helper: Make atomic_enable/disable crtc callbacks optional
On 03/15, Daniel Vetter wrote:
> On Thu, Mar 14, 2019 at 03:48:45PM -0300, Rodrigo Siqueira wrote:
> > Allow atomic_enable and atomic_disable operations from
> > drm_crtc_helper_funcs struct optional. With this, the target display
> > drivers don't need to define a dummy function if they don't need one.
> >
> > Changes since v2:
> > * Don't make funcs optional
> > * Update kerneldoc for atomic_enable/disable
> > * Replace "if (funcs->atomic_enable)" by "if (funcs->commit)"
> > * Improve commit message
> >
> > Signed-off-by: Rodrigo Siqueira
>
> Reviewed-by: Daniel Vetter
Hi,
Is it ok if I apply this patch?
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 5 ++---
> > include/drm/drm_modeset_helper_vtables.h | 4
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 540a77a2ade9..d506e13c2945 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1034,7 +1034,7 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> > funcs->atomic_disable(crtc, old_crtc_state);
> > else if (funcs->disable)
> > funcs->disable(crtc);
> > - else
> > + else if (funcs->dpms)
> > funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> >
> > if (!(dev->irq_enabled && dev->num_crtcs))
> > @@ -1277,10 +1277,9 @@ void drm_atomic_helper_commit_modeset_enables(struct
> > drm_device *dev,
> > if (new_crtc_state->enable) {
> > DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
> > crtc->base.id, crtc->name);
> > -
> > if (funcs->atomic_enable)
> > funcs->atomic_enable(crtc, old_crtc_state);
> > - else
> > + else if (funcs->commit)
> > funcs->commit(crtc);
> > }
> > }
> > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > b/include/drm/drm_modeset_helper_vtables.h
> > index cfb7be40bed7..ce4de6b1e444 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -418,6 +418,8 @@ struct drm_crtc_helper_funcs {
> > * Drivers can use the @old_crtc_state input parameter if the operations
> > * needed to enable the CRTC don't depend solely on the new state but
> > * also on the transition between the old state and the new state.
> > +*
> > +* This function is optional.
> > */
> > void (*atomic_enable)(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_crtc_state);
> > @@ -441,6 +443,8 @@ struct drm_crtc_helper_funcs {
> > * parameter @old_crtc_state which could be used to access the old
> > * state. Atomic drivers should consider to use this one instead
> > * of @disable.
> > +*
> > +* This function is optional.
> > */
> > void (*atomic_disable)(struct drm_crtc *crtc,
> >struct drm_crtc_state *old_crtc_state);
> > --
> > 2.21.0
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dma-fence: Propagate errors to dma-fence-array container
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc2 next-20190325]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-fence-Propagate-errors-to-dma-fence-array-container/20190325-074009
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
drivers/dma-buf/dma-fence-array.c: In function 'dma_fence_array_cb_func':
>> drivers/dma-buf/dma-fence-array.c:50:3: error: implicit declaration of
>> function 'cmpxchg_local'; did you mean 'cmpxchg_relaxed'?
>> [-Werror=implicit-function-declaration]
cmpxchg_local(>base.error, 0, f->error);
^
cmpxchg_relaxed
cc1: some warnings being treated as errors
vim +50 drivers/dma-buf/dma-fence-array.c
41
42 static void dma_fence_array_cb_func(struct dma_fence *f,
43 struct dma_fence_cb *cb)
44 {
45 struct dma_fence_array_cb *array_cb =
46 container_of(cb, struct dma_fence_array_cb, cb);
47 struct dma_fence_array *array = array_cb->array;
48
49 if (atomic_read(>num_pending) > 0)
> 50 cmpxchg_local(>base.error, 0, f->error);
51
52 if (atomic_dec_and_test(>num_pending))
53 irq_work_queue(>work);
54 else
55 dma_fence_put(>base);
56 }
57
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Daniel, Dave, Here is a PR for drm-misc-fixes. Thanks! Maxime drm-misc-fixes-2019-03-25: - A bunch of fixes to cleanup path in meson - Fix the DMT TDMS clock filtering on meson - Fix an issue with NV12 buffers on rockchip when scaling is active - Fix a couple of use-after-free The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-03-25 for you to fetch changes up to 3d565a21f2ce1f37479e91914734478c39b5c6fc: drm/meson: fix TMDS clock filtering for DMT monitors (2019-03-25 11:19:50 +0100) - A bunch of fixes to cleanup path in meson - Fix the DMT TDMS clock filtering on meson - Fix an issue with NV12 buffers on rockchip when scaling is active - Fix a couple of use-after-free Eric Biggers (2): drm/vgem: fix use-after-free when drm_gem_handle_create() fails drm/vkms: fix use-after-free when drm_gem_handle_create() fails Jean-Philippe Brucker (2): drm/meson: Fix invalid pointer in meson_drv_unbind() drm/meson: Uninstall IRQ handler Jonas Karlman (1): drm/rockchip: vop: reset scale mode when win is disabled Neil Armstrong (1): drm/meson: fix TMDS clock filtering for DMT monitors drivers/gpu/drm/meson/meson_drv.c | 9 ++--- drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 ++- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 +++--- drivers/gpu/drm/vgem/vgem_drv.c | 6 +- drivers/gpu/drm/vkms/vkms_gem.c | 5 + 5 files changed, 25 insertions(+), 16 deletions(-) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: radeon: fix a potential NULL-pointer dereference
Hi Kangjie,
thanks for your patch.
On 2019-03-23 3:29 a.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index aa898c699101..a31305755a77 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -678,6 +678,11 @@ static void radeon_crtc_init(struct drm_device *dev, int
> index)
> drm_mode_crtc_set_gamma_size(_crtc->base, 256);
> radeon_crtc->crtc_id = index;
> radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
> + if (!radeon_crtc->flip_queue) {
> + DRM_ERROR("failed to allocate the flip queue\n");
> + kfree(radeon_crtc);
This would leak some memory referenced by struct drm_crtc. To solve
this, I suggest calling radeon_crtc_destroy here and making that cope
with radeon_crtc->flip_queue being NULL.
Also, I'm not sure all driver code can handle some CRTCs not
initializing. Given that, and as alloc_workqueue presumably only fails
if the system is essentially out of memory anyway, it's probably better
for radeon_crtc_init to return -ENOMEM in this case and for
radeon_modeset_init to propagate that, which will prevent the driver as
a whole from initializing.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-next
On Thu, Mar 21, 2019 at 6:08 PM Sean Paul wrote: > > > Hi Da.*, > Here's the first 5.2 PR from -misc. There's a bit of everything in the PR, > enjoy! Pulled, thanks. -Daniel > drm-misc-next-2019-03-21: > drm-misc-next for 5.2: > > UAPI Changes: > - Add Colorspace connector property (Uma) > - fourcc: Several new YUV formats from ARM (Brian & Ayan) > - fourcc: Fix merge conflicts between new formats above and Swati's that > went in via topic/hdr-formats-2019-03-07 branch (Maarten) > > Cross-subsystem Changes: > - Typed component support via topic/component-typed-2019-02-11 (Maxime/Daniel) > > Core Changes: > - Improve component helper documentation (Daniel) > - Avoid calling drm_dev_unregister() twice on unplugged devices (Noralf) > - Add device managed (devm) drm_device init function (Noralf) > - Graduate TINYDRM_MODE to DRM_SIMPLE_MODE in core (Noralf) > - Move MIPI/DSI rate control params computation into core from i915 (David) > - Add support for shmem backed gem objects (Noralf) > > Driver Changes: > - various: Use of_node_name_eq for node name comparisons (Rob Herring) > - sun4i: Add DSI burst mode support (Konstantin) > - panel: Add Ronbo RB070D30 MIPI/DSI panel support (Konstantin) > - virtio: A few prime improvements (Gerd) > - tinydrm: Remove tinydrm_device (Noralf) > - vc4: Add load tracker to driver to detect underflow in atomic check (Boris) > - vboxvideo: Move it out of staging \o/ (Hans) > - v3d: Add support for V3D v4.2 (Eric) > > Cc: Konstantin Sudakov > Cc: Rob Herring > Cc: Daniel Vetter > Cc: Maxime Ripard > Cc: Uma Shankar > Cc: Noralf Trønnes > Cc: Gerd Hoffmann > Cc: David Francis > Cc: Boris Brezillon > Cc: Eric Anholt > Cc: Hans de Goede > Cc: Brian Starkey > Cc: Ayan Kumar Halder > Cc: Maarten Lankhorst > > Cheers, Sean > > > The following changes since commit 4b057e73f28f1df13b77b77a52094238ffdf8abd: > > Merge tag 'drm-misc-fixes-2019-02-22' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-03-05 08:14:22 > +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-03-21 > > for you to fetch changes up to ff01e6971ecd9ba6a9c0538c46d713f38a751f11: > > drm/fourcc: Fix conflicting Y41x definitions (2019-03-21 09:49:04 +0100) > > > drm-misc-next for 5.2: > > UAPI Changes: > - Add Colorspace connector property (Uma) > - fourcc: Several new YUV formats from ARM (Brian & Ayan) > - fourcc: Fix merge conflicts between new formats above and Swati's that > went in via topic/hdr-formats-2019-03-07 branch (Maarten) > > Cross-subsystem Changes: > - Typed component support via topic/component-typed-2019-02-11 (Maxime/Daniel) > > Core Changes: > - Improve component helper documentation (Daniel) > - Avoid calling drm_dev_unregister() twice on unplugged devices (Noralf) > - Add device managed (devm) drm_device init function (Noralf) > - Graduate TINYDRM_MODE to DRM_SIMPLE_MODE in core (Noralf) > - Move MIPI/DSI rate control params computation into core from i915 (David) > - Add support for shmem backed gem objects (Noralf) > > Driver Changes: > - various: Use of_node_name_eq for node name comparisons (Rob Herring) > - sun4i: Add DSI burst mode support (Konstantin) > - panel: Add Ronbo RB070D30 MIPI/DSI panel support (Konstantin) > - virtio: A few prime improvements (Gerd) > - tinydrm: Remove tinydrm_device (Noralf) > - vc4: Add load tracker to driver to detect underflow in atomic check (Boris) > - vboxvideo: Move it out of staging \o/ (Hans) > - v3d: Add support for V3D v4.2 (Eric) > > Cc: Konstantin Sudakov > Cc: Rob Herring > Cc: Daniel Vetter > Cc: Maxime Ripard > Cc: Uma Shankar > Cc: Noralf Trønnes > Cc: Gerd Hoffmann > Cc: David Francis > Cc: Boris Brezillon > Cc: Eric Anholt > Cc: Hans de Goede > Cc: Brian Starkey > Cc: Ayan Kumar Halder > Cc: Maarten Lankhorst > > > Andrey Grodzovsky (1): > drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched. > > Andy Shevchenko (2): > drm/tinydrm: Trivia typo fix > drm/selftests/mm: Switch to bitmap_zalloc() > > Arnd Bergmann (1): > drm/stm: fix CONFIG_FB dependency > > Ayan Kumar Halder (9): > drm: Added a new format DRM_FORMAT_XVYU2101010 > drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC > modifier > drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and > DP650 > drm/arm/malidp:- Define a common list of AFBC format modifiers > supported for DP500, DP550 and DP650 > drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV > formats > drm/arm/malidp:- Writeback framebuffer does not support any modifiers > drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() > instead of relying on cpp for calculating framebuffer size > drm/arm/malidp:- Disregard the pitch
[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 Michel Dänzer changed: What|Removed |Added Attachment #143754|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/meson: Fix invalid pointer in meson_drv_unbind()
On 22/03/2019 16:26, Jean-Philippe Brucker wrote:
> meson_drv_bind() registers a meson_drm struct as the device's privdata,
> but meson_drv_unbind() tries to retrieve a drm_device. This may cause a
> segfault on shutdown:
>
> [ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual
> address 0197
> ...
> [ 5194.788850] Call trace:
> [ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm]
> [ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm]
>
> Retrieve the right pointer in meson_drv_unbind().
>
> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/gpu/drm/meson/meson_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 2281ed3eb774..7e85802c5398 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -356,8 +356,8 @@ static int meson_drv_bind(struct device *dev)
>
> static void meson_drv_unbind(struct device *dev)
> {
> - struct drm_device *drm = dev_get_drvdata(dev);
> - struct meson_drm *priv = drm->dev_private;
> + struct meson_drm *priv = dev_get_drvdata(dev);
> + struct drm_device *drm = priv->drm;
>
> if (priv->canvas) {
> meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
>
Applied both to drm-misc-fixes, thanks !
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel
On Fri, 22 Mar 2019, "Souza, Jose" wrote:
> On Fri, 2019-03-22 at 13:35 -0700, Anusha wrote:
>> Straight copy from the kernel file.
>>
>> Add PCI IDs for CML, add additional PCI ID
>> for ICL.
>>
>> Align with kernel commits:
>>
>> a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS")
>> 9a751b999d17a ("drm/i915: Add new ICL PCI ID")
>>
>> v2: Do a copy from kernel header (Jose)
>> - Change commit message (Lucas)
>>
>> v3: Add corresponding kernel commit IDs (Antonio)
>
> Not sure if libdrm have a style rule but in i915 we use 12 digits for
> the commit hash, other than that:
Protip, 'dim cite' gives you the references in the right format, or you
can add this to your .gitconfig alias section for a 'git cite' alias:
cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e
's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"
BR,
Jani.
>
> Reviewed-by: José Roberto de Souza
>
>>
>> Cc: Antonio Argenziano
>> Cc: José Roberto de Souza
>> Cc: Lucas De Marchi
>> Signed-off-by: Anusha Srivatsa
>> ---
>> intel/i915_pciids.h | 31 +--
>> 1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/intel/i915_pciids.h b/intel/i915_pciids.h
>> index d2fad7b0..291b5e3f 100644
>> --- a/intel/i915_pciids.h
>> +++ b/intel/i915_pciids.h
>> @@ -373,6 +373,30 @@
>> #define INTEL_AML_CFL_GT2_IDS(info) \
>> INTEL_VGA_DEVICE(0x87CA, info)
>>
>> +/* CML GT1 */
>> +#define INTEL_CML_GT1_IDS(info) \
>> +INTEL_VGA_DEVICE(0x9B21, info), \
>> +INTEL_VGA_DEVICE(0x9BAA, info), \
>> +INTEL_VGA_DEVICE(0x9BAB, info), \
>> +INTEL_VGA_DEVICE(0x9BAC, info), \
>> +INTEL_VGA_DEVICE(0x9BA0, info), \
>> +INTEL_VGA_DEVICE(0x9BA5, info), \
>> +INTEL_VGA_DEVICE(0x9BA8, info), \
>> +INTEL_VGA_DEVICE(0x9BA4, info), \
>> +INTEL_VGA_DEVICE(0x9BA2, info)
>> +
>> +/* CML GT2 */
>> +#define INTEL_CML_GT2_IDS(info) \
>> +INTEL_VGA_DEVICE(0x9B41, info), \
>> +INTEL_VGA_DEVICE(0x9BCA, info), \
>> +INTEL_VGA_DEVICE(0x9BCB, info), \
>> +INTEL_VGA_DEVICE(0x9BCC, info), \
>> +INTEL_VGA_DEVICE(0x9BC0, info), \
>> +INTEL_VGA_DEVICE(0x9BC5, info), \
>> +INTEL_VGA_DEVICE(0x9BC8, info), \
>> +INTEL_VGA_DEVICE(0x9BC4, info), \
>> +INTEL_VGA_DEVICE(0x9BC2, info)
>> +
>> #define INTEL_KBL_IDS(info) \
>> INTEL_KBL_GT1_IDS(info), \
>> INTEL_KBL_GT2_IDS(info), \
>> @@ -436,7 +460,9 @@
>> INTEL_WHL_U_GT1_IDS(info), \
>> INTEL_WHL_U_GT2_IDS(info), \
>> INTEL_WHL_U_GT3_IDS(info), \
>> -INTEL_AML_CFL_GT2_IDS(info)
>> +INTEL_AML_CFL_GT2_IDS(info), \
>> +INTEL_CML_GT1_IDS(info), \
>> +INTEL_CML_GT2_IDS(info)
>>
>> /* CNL */
>> #define INTEL_CNL_IDS(info) \
>> @@ -469,6 +495,7 @@
>> INTEL_VGA_DEVICE(0x8A57, info), \
>> INTEL_VGA_DEVICE(0x8A56, info), \
>> INTEL_VGA_DEVICE(0x8A71, info), \
>> -INTEL_VGA_DEVICE(0x8A70, info)
>> +INTEL_VGA_DEVICE(0x8A70, info), \
>> +INTEL_VGA_DEVICE(0x8A53, info)
>>
>> #endif /* _I915_PCIIDS_H */
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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/bridge: dw-hdmi: disable SCDC configuration for invalid setups
Hi Andrzej, Laurent,
Gentle ping,
Did you have time to review this fix ?
Thanks !
Neil
On 15/03/2019 10:54, Neil Armstrong wrote:
> This patch is an attempt to limit HDMI 2.0 SCDC setup when :
> - the SoC embeds an HDMI 1.4 only controller
> - the EDID supports SCDC but not scrambling
> - the EDID supports SCDC scrambling but not for low TMDS bit rates,
> while only supporting low TMDS bit rates
>
> This to avoid communicating with the SCDC DDC slave uncessary, and
> setting the DW-HDMI TMDS Scrambler setup when not supported by the
> underlying hardware.
>
> Reported-by: Rob Herring
> Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
> support")
> Signed-off-by: Neil Armstrong
> ---
>
> Rob,
>
> this patch should also solve your issue with your 11' display, could you
> test it ?
> If this works, I will focus on the underlying issue where the RK3399 SoC
> freezes in your setup.
>
> Thanks,
> Neil
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 ---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a63e5f0dae56..db761329a1e3 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,6 +1037,31 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi,
> unsigned short data,
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>
> +/* Filter out invalid setups to avoid configuring SCDC and scrambling */
> +static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
> +{
> + struct drm_display_info *display = >connector.display_info;
> +
> + /* Completely disable SCDC support for older controllers */
> + if (hdmi->version < 0x200a)
> + return false;
> +
> + /* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
> + if (!display->hdmi.scdc.supported ||
> + !display->hdmi.scdc.scrambling.supported)
> + return false;
> +
> + /*
> + * Disable if display only support low TMDS rates and scrambling
> + * for low rates is not supported either
> + */
> + if (!display->hdmi.scdc.scrambling.low_rates &&
> + display->max_tmds_clock <= 34)
> + return false;
> +
> + return true;
> +}
> +
> /*
> * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
> * - The Source shall suspend transmission of the TMDS clock and data
> @@ -1055,7 +1080,7 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
> *hdmi)
> unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mtmdsclock;
>
> /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
> - if (hdmi->connector.display_info.hdmi.scdc.supported) {
> + if (dw_hdmi_support_scdc(hdmi)) {
> if (mtmdsclock > HDMI14_MAX_TMDSCLK)
> drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
> else
> @@ -1579,8 +1604,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>
> /* Set up HDMI_FC_INVIDCONF */
> inv_val = (hdmi->hdmi_data.hdcp_enable ||
> -vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> -hdmi_info->scdc.scrambling.low_rates ?
> +(dw_hdmi_support_scdc(hdmi) &&
> + (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> + hdmi_info->scdc.scrambling.low_rates)) ?
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE :
> HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE);
>
> @@ -1646,7 +1672,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
> }
>
> /* Scrambling Control */
> - if (hdmi_info->scdc.supported) {
> + if (dw_hdmi_support_scdc(hdmi)) {
> if (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
> hdmi_info->scdc.scrambling.low_rates) {
> /*
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: fix TMDS clock filtering for DMT monitors
On 20/03/2019 09:11, Neil Armstrong wrote:
> DMT monitors does not necessarely report a maximum TMDS clock
> in a VSDB EDID extension.
>
> In this case, all modes are wrongly rejected, including
> the DRM fallback EDID.
>
> This patch only rejects modes whith clock > max_tmds_clock if
> the max_tmds_clock is specified. This will only reject
> 4:2:0 HDMI2.0 modes, who reports a clock > max_tmds_clock.
>
> Reported-by: Maxime Jourdan
> Fixes: d7d8fb7046b6 ("drm/meson: add HDMI div40 TMDS mode")
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index e28814f4ea6c..563953ec6ad0 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -569,7 +569,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
> DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
>
> /* If sink max TMDS clock, we reject the mode */
> - if (mode->clock > connector->display_info.max_tmds_clock)
> + if (connector->display_info.max_tmds_clock &&
> + mode->clock > connector->display_info.max_tmds_clock)
> return MODE_BAD;
>
> /* Check against non-VIC supported modes */
>
Applied to drm-misc-fixes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Michel Dänzer changed: What|Removed |Added Version|18.3|19.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #3 from fin4...@hotmail.com --- You both have cheap low quality Sapphire cards with 2 year warranty here when Asus has 3 years. Custom bios in those cards are famous to cause problems with Linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Michel Dänzer changed: What|Removed |Added Component|Drivers/DRI/R100|Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 Michel Dänzer changed: What|Removed |Added Attachment #143755|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix an error code in i915_gem_context_open()
If gem_context_register() fails then "ctx" is a valid pointer, not an
error pointer. We should just return "err".
Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and
registration to userspace")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index e6f594668245..25f267a03d3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -709,7 +709,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
idr_destroy(_priv->context_idr);
mutex_destroy(_priv->vm_idr_lock);
mutex_destroy(_priv->context_idr_lock);
- return PTR_ERR(ctx);
+ return err;
}
void i915_gem_context_close(struct drm_file *file)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix an error code in i915_gem_context_open()
Quoting Dan Carpenter (2019-03-25 09:23:49)
> If gem_context_register() fails then "ctx" is a valid pointer, not an
> error pointer. We should just return "err".
>
> Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and
> registration to userspace")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index e6f594668245..25f267a03d3d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -709,7 +709,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
> idr_destroy(_priv->context_idr);
> mutex_destroy(_priv->vm_idr_lock);
> mutex_destroy(_priv->context_idr_lock);
> - return PTR_ERR(ctx);
> + return err;
I beat you by mere moments! Thanks for the patch, will be fixed
momentarily.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers
On Fri, Mar 15, 2019 at 06:56:07AM -0500, Benoit Parrot wrote:
> Daniel Vetter wrote on Fri [2019-Mar-15 11:50:57 +0100]:
> > On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> > > During a suspend cycle the atomic state is saved to be used during the
> > > restore cycle.
> > >
> > > However the current state duplication logic does not duplicate private
> > > objects. This leads to state inconsistencies at resume time.
> > >
> > > With private objects modeset lock now integrated, we can make sure that
> > > private object state are properly saved and restored.
> > >
> > > Signed-off-by: Benoit Parrot
> >
> > Why do you need this? We're doing a full atomic_check, and your
> > atomic_check should be pulling in any private state objects and
> > recomputing their states. This smells like papering over a driver bug.
>
> I have not seen any atomic_check called during the suspend duplicate
> helper. And you are correct normally the private_object state in my case
> would get pulled in during a plane atomic_check but that does not happen
> here in this step.
Yeah duplicating in suspend won't call atomic_check. Restoring the
duplicated state on resume will (or there's going to be lots of broken
drivers).
> Why wouldn't we save all the "state" artifacts so that the whole atomic
> state is consistent?
It's not needed, and might possible paper over driver bugs ...
> > The duplicate helpers should only need to duplicate the uapi-relevant
> > states, i.e. connector/crtc/planes.
... because of this reason. If your driver can't recompute the private
state from just the duplicated uapi-relevant states it's broken. Because
essentially the exact same thing might happen through the atomic ioctl
from userspace.
Hence my question: Why do you need this?
-Daniel
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 540a77a2ade9..b108021cc092 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -3189,6 +3189,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> > > *dev,
> > > struct drm_connector_list_iter conn_iter;
> > > struct drm_plane *plane;
> > > struct drm_crtc *crtc;
> > > + struct drm_private_obj *privobj;
> > > int err = 0;
> > >
> > > state = drm_atomic_state_alloc(dev);
> > > @@ -3218,6 +3219,16 @@ drm_atomic_helper_duplicate_state(struct
> > > drm_device *dev,
> > > }
> > > }
> > >
> > > + drm_for_each_privobj(privobj, dev) {
> > > + struct drm_private_state *priv_state;
> > > +
> > > + priv_state = drm_atomic_get_private_obj_state(state, privobj);
> > > + if (IS_ERR(priv_state)) {
> > > + err = PTR_ERR(priv_state);
> > > + goto free;
> > > + }
> > > + }
> > > +
> > > drm_connector_list_iter_begin(dev, _iter);
> > > drm_for_each_connector_iter(conn, _iter) {
> > > struct drm_connector_state *conn_state;
> > > @@ -3325,12 +3336,17 @@ int
> > > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
> > > struct drm_connector_state *new_conn_state;
> > > struct drm_crtc *crtc;
> > > struct drm_crtc_state *new_crtc_state;
> > > + struct drm_private_obj *privobj;
> > > + struct drm_private_state *new_priv_state;
> > >
> > > state->acquire_ctx = ctx;
> > >
> > > for_each_new_plane_in_state(state, plane, new_plane_state, i)
> > > state->planes[i].old_state = plane->state;
> > >
> > > + for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
> > > + state->private_objs[i].old_state = privobj->state;
> > > +
> > > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > state->crtcs[i].old_state = crtc->state;
> > >
> > > --
> > > 2.17.1
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/ttm: remove set but not used variable 'vgdev'
On Wed, Mar 20, 2019 at 02:03:08AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type':
> drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning:
> variable 'vgdev' set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify':
> drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning:
> variable 'vgdev' set but not used [-Wunused-but-set-variable]
>
> It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.")
>
> Signed-off-by: YueHaibing
Subject prefix should be drm/virtio: which is maybe the reason Gerd hasn't
spotted this yet.
-Daniel
> ---
> drivers/gpu/drm/virtio/virtgpu_ttm.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
> b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> index d6225ba20b30..eb007c2569d8 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> @@ -114,10 +114,6 @@ static const struct ttm_mem_type_manager_func
> virtio_gpu_bo_manager_func = {
> static int virtio_gpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t
> type,
> struct ttm_mem_type_manager *man)
> {
> - struct virtio_gpu_device *vgdev;
> -
> - vgdev = virtio_gpu_get_vgdev(bdev);
> -
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> @@ -297,10 +293,8 @@ static void virtio_gpu_bo_move_notify(struct
> ttm_buffer_object *tbo,
> static void virtio_gpu_bo_swap_notify(struct ttm_buffer_object *tbo)
> {
> struct virtio_gpu_object *bo;
> - struct virtio_gpu_device *vgdev;
>
> bo = container_of(tbo, struct virtio_gpu_object, tbo);
> - vgdev = (struct virtio_gpu_device *)bo->gem_base.dev->dev_private;
>
> if (bo->pages)
> virtio_gpu_object_free_sg_table(bo);
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 RESEND 01/24] arm64: dts: exynos: configure GSCALER related clocks
On Mon, 25 Mar 2019 at 09:32, Andrzej Hajda wrote: > > On 25.03.2019 08:50, Krzysztof Kozlowski wrote: > > On Mon, 25 Mar 2019 at 08:13, Andrzej Hajda wrote: > >> GSCALER should be feed with clock at certain rates. > >> > >> Signed-off-by: Andrzej Hajda > >> --- > >> Already merged !!! > > Then you should skip it because someone might not notice it and apply > > second time. > > > I was asked to rebase the patchset on exynos-drm-next, but it does not > contains yet these patches, > > so without adding it here "someone might not notice it and" can complain > that patchset is broken :) > > Maybe better solution would be point to point out samsung-soc tree tag > which should exynos-drm-next be based on? Next time I will try this way. Yes, I see. If needed, I can provide stable tag with DTS patches however in general this is discouraged because it means that you break the ABI. Updated driver does not work with old DTBs... so the best way is to split the patchset and bring in the second part of driver changes later. :) Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm: Add panic handling
On Mon, Mar 18, 2019 at 12:06:13AM +0100, Ahmed S. Darwish wrote: > > => Now that the dust has settled, here's a summary of this huge >50-email thread (thanks Daniel, Noralf, John, everyone!). > > => Parts of this document are a direct rewording of Daniel's replies, >so I took the liberty of adding a Co-developed-by tag here.. > > => This is only a summary, and _not_ an official patch submission. >It's now Show-me-the-code time ;-) > > Subject: [PATCH] Documentation: gpu: Add initial DRM panic design > > Co-developed-by: Daniel Vetter > Signed-off-by: Ahmed S. Darwish > --- > Documentation/gpu/drm-panic-design.rst | 124 + > 1 file changed, 124 insertions(+) > create mode 100644 Documentation/gpu/drm-panic-design.rst > > diff --git a/Documentation/gpu/drm-panic-design.rst > b/Documentation/gpu/drm-panic-design.rst > new file mode 100644 > index ..ba306193f347 > --- /dev/null > +++ b/Documentation/gpu/drm-panic-design.rst > @@ -0,0 +1,124 @@ > + > + > +A DRM-based panic viewer > + > + > +The Linux Kernel currently contains the necessary plumbing for viewing > +a kernel panic log using DRM-based kmsg dumpers, even if the system is > +currently running a graphical session (e.g. wayland). > + > +.. _drm_panic_design: > + > +Implementation design > += > + > +Code pathes running in a panic context face several constraints: > + > +1. Code must be fully synchronous: interrupts are disabled > +2. Dynamic memory allocations are not allowed > +3. Cannot acquire any mutexes: atomic context, due to 1. > +4. Cannot acquire any spin locks: potential spinning-forever risk Maybe rephrase as: 3. No sleeping (there's other ways to sleep than just memory allocations and acquiring a mutex) 4. No unconditional locking at all (there's more than spinlocks/mutexes). E.g. one of the most important locks is drm_modest_lock, which is a ww_mutex. > + > +For the *DRM* panic code, the extra conditions below apply: > + > +5. Code must only trylock relevant DRM subsystem locks > +6. If any trylock operation fails, the code *must not* go through > +7. All rendering is done on the GPU's "current display buffer" used > + at the time of panic(): no HW programming is done at all. Maybe let's clarify this a bit, since from the discussions it sounded like at least amdgpu needs to touch a few bits (disable tiling, the indirect vram write registers to access vram outside of the bar): "Only the least amount of HW programming (preferrably none) is done, exceptions would be disabling tiled/compressed scanout." > +8. The code must be non-intrusive, and *must not* affect any other > + panic handling mechanism (netconsole, ramoops, kexec, etc.) Hm, I'm not entirely clear on what you mean here. Maybe some more examples of what would be a bad idea? > + > +Rationale follows. > + > + > +Spin locks > +-- > + > +Acquiring a spin lock in a panic() context is potentially lethal: > +the lock might've been already acquired, _permanently_, by another > +core that is now fully shut down through an IPI from the panic()-ing > +core. > + > +Moreover, at least on x86, the first target architecture for this > +work, the panic()-ing core wait by default for *a full second* until > +all other cores finish their non-preemptible regions and terminate. > +If that did not work out, it even tries more aggressively with NMIs. > + > +So if the other non panic()-ing cores was holding a DRM-related lock > +through spin_lock_irqsave() for more than one second, then it's a > +bug in the DRM layer code. Thus, the DRM panic viewer cannot do > +anything and should just exit. [A] > + > +What if the non panic()-ing core was holding a DRM lock through > +barebone spin_lock()? Interrupts are enabled there, so the IPI will be > +handled, and thus that core will effectively die while the lock is > +*forever held*. [B] > + > + > +Trylocking > +-- > + > +The DRM panic code always *tries* to acquire the *minimum relevant > +set* of DRM related locks, through the basic :c:func:`spin_trylock()` > +mechanism. > + > +From case [A] and case [B] above, if the trylock operation fails, > +there's no point in retrying it multiple times: the relevant locks > +are in a broken and unrecoverable state anyway. > + > +Moreover, The panic code cannot also just ignore the DRM locks and > +force its way through: a broken non-preemptible DRM region implies > +either invalid SW state (e.g. broken linked list pointers), or a GPU > +in an unknown HW state. > + > +A GPU in an unknown HW state is quite dangerous: it has access to the > +full system memory, and if poked incorrectly, there's a really good > +chance it can kill the entire machine. > + > + > +GPU hardware access > +--- > + > +In the current state, a full GPU reset, modesetting, or even disabling > +GPU planes, is not doable under a panic() context: it implies going > +through a
Re: [PATCH] drm: vkms: check status of alloc_ordered_workqueue
On Fri, Mar 22, 2019 at 09:32:07PM -0500, Kangjie Lu wrote:
>
>
> > On Mar 8, 2019, at 10:36 PM, Kangjie Lu wrote:
> >
> > alloc_ordered_workqueue may fail and return NULL.
> > The fix returns ENOMEM when it fails to avoid potential NULL
> > pointer dereference.
> >
> > Signed-off-by: Kangjie Lu
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 8a9aeb0a9ea8..bb66dbcd5e3f 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -219,6 +219,8 @@ int vkms_crtc_init(struct drm_device *dev, struct
> > drm_crtc *crtc,
> > spin_lock_init(_out->state_lock);
> >
> > vkms_out->crc_workq = alloc_ordered_workqueue("vkms_crc_workq", 0);
> > + if (!vkms_out->crc_workq)
> > + return -ENOMEM;
>
> Is this a reasonable patch?
lgtm, applied and thanks for your patch.
-Daniel
>
> >
> > return ret;
> > }
> > --
> > 2.17.1
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/amdgpu: update version for timeline syncobj support in amdgpu
Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 8a0732088640..4d8db87048d3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -74,9 +74,10 @@ * - 3.28.0 - Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES * - 3.29.0 - Add AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID * - 3.30.0 - Add AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE. + * - 3.31.0 - Add syncobj timeline support to AMDGPU_CS. */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 30 +#define KMS_DRIVER_MINOR 31 #define KMS_DRIVER_PATCHLEVEL 0 int amdgpu_vram_limit = 0; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/syncobj: add transition iotcls between binary and timeline v2
we need to import/export timeline point.
v2: unify to one transfer ioctl
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 74 ++
include/uapi/drm/drm.h | 10 +
4 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 695179bb88dc..dd11ae5f1eef 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -180,6 +180,8 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7a534c184e52..92b3b7b2fd81 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -686,6 +686,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
drm_syncobj_fd_to_handle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TRANSFER, drm_syncobj_transfer_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 087fd4e7eaf3..ee2d66e047e7 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -679,6 +679,80 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
>handle);
}
+static int drm_syncobj_transfer_to_timeline(struct drm_file *file_private,
+ struct drm_syncobj_transfer *args)
+{
+ struct drm_syncobj *timeline_syncobj = NULL;
+ struct dma_fence *fence;
+ struct dma_fence_chain *chain;
+ int ret;
+
+ timeline_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+ if (!timeline_syncobj) {
+ return -ENOENT;
+ }
+ ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags,
+);
+ if (ret)
+ goto err;
+ chain = kzalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
+ if (!chain) {
+ ret = -ENOMEM;
+ goto err1;
+ }
+ drm_syncobj_add_point(timeline_syncobj, chain, fence, args->dst_point);
+err1:
+ dma_fence_put(fence);
+err:
+ drm_syncobj_put(timeline_syncobj);
+
+ return ret;
+}
+
+static int
+drm_syncobj_transfer_to_binary(struct drm_file *file_private,
+ struct drm_syncobj_transfer *args)
+{
+ struct drm_syncobj *binary_syncobj = NULL;
+ struct dma_fence *fence;
+ int ret;
+
+ binary_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+ if (!binary_syncobj)
+ return -ENOENT;
+ ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags, );
+ if (ret)
+ goto err;
+ drm_syncobj_replace_fence(binary_syncobj, fence);
+ dma_fence_put(fence);
+err:
+ drm_syncobj_put(binary_syncobj);
+
+ return ret;
+}
+int
+drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_transfer *args = data;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad)
+ return -EINVAL;
+
+ if (args->dst_point)
+ ret = drm_syncobj_transfer_to_timeline(file_private, args);
+ else
+ ret = drm_syncobj_transfer_to_binary(file_private, args);
+
+ return ret;
+}
+
static void syncobj_wait_fence_func(struct dma_fence *fence,
struct dma_fence_cb *cb)
{
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index c62be0840ba5..e8d0d6b51875 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -735,6 +735,15 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct
[PATCH 6/9] drm/amdgpu: add timeline support in amdgpu CS v3
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 152 +
include/uapi/drm/amdgpu_drm.h | 8 ++
3 files changed, 144 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8d0d7f3dd5fb..deec2c796253 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -433,6 +433,12 @@ struct amdgpu_cs_chunk {
void*kdata;
};
+struct amdgpu_cs_post_dep {
+ struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
+ u64 point;
+};
+
struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -462,8 +468,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
- unsigned num_post_dep_syncobjs;
- struct drm_syncobj **post_dep_syncobjs;
+ unsignednum_post_deps;
+ struct amdgpu_cs_post_dep *post_deps;
};
static inline u32 amdgpu_get_ib_value(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 52a5e4fdc95b..2f6239b6be6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -215,6 +215,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
case AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
default:
@@ -804,9 +806,11 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser
*parser, int error,
ttm_eu_backoff_reservation(>ticket,
>validated);
- for (i = 0; i < parser->num_post_dep_syncobjs; i++)
- drm_syncobj_put(parser->post_dep_syncobjs[i]);
- kfree(parser->post_dep_syncobjs);
+ for (i = 0; i < parser->num_post_deps; i++) {
+ drm_syncobj_put(parser->post_deps[i].syncobj);
+ kfree(parser->post_deps[i].chain);
+ }
+ kfree(parser->post_deps);
dma_fence_put(parser->fence);
@@ -1117,13 +1121,18 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
}
static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
-uint32_t handle)
+uint32_t handle, u64 point,
+u64 flags)
{
- int r;
struct dma_fence *fence;
- r = drm_syncobj_find_fence(p->filp, handle, 0, 0, );
- if (r)
+ int r;
+
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags, );
+ if (r) {
+ DRM_ERROR("syncobj %u failed to find fence @ %llu (%d)!\n",
+ handle, point, r);
return r;
+ }
r = amdgpu_sync_fence(p->adev, >job->sync, fence, true);
dma_fence_put(fence);
@@ -1134,46 +1143,118 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
struct amdgpu_cs_chunk *chunk)
{
+ struct drm_amdgpu_cs_chunk_sem *deps;
unsigned num_deps;
int i, r;
- struct drm_amdgpu_cs_chunk_sem *deps;
deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
num_deps = chunk->length_dw * 4 /
sizeof(struct drm_amdgpu_cs_chunk_sem);
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle,
+ 0, 0);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+static int amdgpu_cs_process_syncobj_timeline_in_dep(struct amdgpu_cs_parser
*p,
+struct amdgpu_cs_chunk
*chunk)
+{
+ struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+ unsigned num_deps;
+ int i, r;
+
+ syncobj_deps = (struct drm_amdgpu_cs_chunk_syncobj *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_syncobj);
for (i = 0; i < num_deps; ++i) {
- r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
[PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v5
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
v4: remove v3 change and add checking to prevent out-of-order
v5: unify binary and timeline
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 73 ++
include/uapi/drm/drm.h | 1 +
4 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index dd11ae5f1eef..d9a483a5fce0 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 92b3b7b2fd81..d337f161909c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL,
drm_syncobj_timeline_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index ee2d66e047e7..099596190845 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1183,6 +1183,79 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+int
+drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_array *args = data;
+ struct drm_syncobj **syncobjs;
+ struct dma_fence_chain **chains;
+ uint64_t *points;
+ uint32_t i, j;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -EOPNOTSUPP;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+ if (ret < 0)
+ return ret;
+
+ points = kmalloc_array(args->count_handles, sizeof(*points),
+ GFP_KERNEL);
+ if (!points) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ if (!u64_to_user_ptr(args->points)) {
+ memset(points, 0, args->count_handles * sizeof(uint64_t));
+ } else if (copy_from_user(points, u64_to_user_ptr(args->points),
+ sizeof(uint64_t) * args->count_handles)) {
+ ret = -EFAULT;
+ goto err_points;
+ }
+
+ chains = kmalloc_array(args->count_handles, sizeof(void *), GFP_KERNEL);
+ if (!chains) {
+ ret = -ENOMEM;
+ goto err_points;
+ }
+ for (i = 0; i < args->count_handles; i++) {
+ chains[i] = kzalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
+ if (!chains[i]) {
+ for (j = 0; j < i; j++)
+ kfree(chains[j]);
+ ret = -ENOMEM;
+ goto err_chains;
+ }
+ }
+
+ for (i = 0; i < args->count_handles; i++) {
+ struct dma_fence *fence = dma_fence_get_stub();
+
+ drm_syncobj_add_point(syncobjs[i], chains[i],
+ fence, points[i]);
+ dma_fence_put(fence);
+ }
+err_chains:
+ kfree(chains);
+err_points:
+ kfree(points);
+out:
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
+
int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file
[PATCH 5/9] drm/syncobj: use the timeline point in drm_syncobj_find_fence v4
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence
Signed-off-by: Christian König
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_syncobj.c | 50 ---
1 file changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0e62a793c8dd..087fd4e7eaf3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -213,6 +213,8 @@ static void drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
dma_fence_put(fence);
}
+/* 5s default for wait submission */
+#define DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT 50ULL
/**
* drm_syncobj_find_fence - lookup and reference the fence in a sync object
* @file_private: drm file private pointer
@@ -233,16 +235,58 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
struct dma_fence **fence)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
- int ret = 0;
+ struct syncobj_wait_entry wait;
+ u64 timeout = nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
+ int ret;
if (!syncobj)
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
+ drm_syncobj_put(syncobj);
+
+ if (*fence) {
+ ret = dma_fence_chain_find_seqno(fence, point);
+ if (!ret)
+ return 0;
+ dma_fence_put(*fence);
+ } else {
ret = -EINVAL;
}
- drm_syncobj_put(syncobj);
+
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ return ret;
+
+ memset(, 0, sizeof(wait));
+ wait.task = current;
+ wait.point = point;
+ drm_syncobj_fence_add_wait(syncobj, );
+
+ do {
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (wait.fence) {
+ ret = 0;
+ break;
+ }
+if (timeout == 0) {
+ret = -ETIME;
+break;
+}
+
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+
+timeout = schedule_timeout(timeout);
+ } while (1);
+
+ __set_current_state(TASK_RUNNING);
+ *fence = wait.fence;
+
+ if (wait.node.next)
+ drm_syncobj_remove_wait(syncobj, );
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver
Le 25/03/2019 02:35, Laurent Pinchart a écrit :
> Hi Jernej,
>
> Thank you for the patch.
>
> On Sun, Mar 24, 2019 at 10:21:42PM +0100, Jernej Skrabec wrote:
>> DW HDMI controller on some Allwinner SoCs has support for CEC, but due
>> to additional logic put between CEC controller and pins, it doesn't work
>> correctly, at least not with a lot of instrusive changes. Fortunately,
>> it's still possible to bitbang protocol.
>>
>> For such cases, add a platform option to suppress loading CEC driver. If
>> DW HDMI CEC driver would be loaded, it wouldn't work anyway and only
>> cause a confusion with multiple /dev entries.
>>
>> Signed-off-by: Jernej Skrabec
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>> include/drm/bridge/dw_hdmi.h | 2 ++
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index a63e5f0dae56..fdda26f8b056 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2634,7 +2634,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> hdmi->audio = platform_device_register_full();
>> }
>>
>> -if (config0 & HDMI_CONFIG0_CEC) {
>> +if (!plat_data->is_cec_unusable && (config0 & HDMI_CONFIG0_CEC)) {
>> cec.hdmi = hdmi;
>> cec.ops = _hdmi_cec_ops;
>> cec.irq = irq;
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index 66e70770cce5..764b8bcfa62c 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -144,6 +144,8 @@ struct dw_hdmi_plat_data {
>> int (*configure_phy)(struct dw_hdmi *hdmi,
>> const struct dw_hdmi_plat_data *pdata,
>> unsigned long mpixelclock);
>> +
>> +unsigned int is_cec_unusable : 1;
>
> Strictly speaking your CEC controller isn't unusable, it's just a bit
> difficult to use it according to your commit message. Would disable_cec
> be a more appropriate field name ?
Actually, it would be useful to have in for Amlogic SoCs also, the dw-hdmi
is configured with the CEC engine, but isn't connected to an external I/O.
And we have easy way to disable it unless disabling the DW-HDMI CEC driver...
With a more appropriate name,
Reviewed-by: Neil Armstrong
> And how difficult would it be to
> support the hardware CEC controller, would that result in changes that
> could be useful to other vendors too ?
>
>> };
>>
>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/syncobj: add timeline payload query ioctl v6
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 62 ++
include/uapi/drm/drm.h | 10 ++
4 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 331ac6225b58..695179bb88dc 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -188,6 +188,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
/* drm_framebuffer.c */
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index c984654646fa..7a534c184e52 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -694,6 +694,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index eae51978cda4..0e62a793c8dd 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1064,3 +1064,65 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
return ret;
}
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_timeline_array *args = data;
+ struct drm_syncobj **syncobjs;
+ uint64_t __user *points = u64_to_user_ptr(args->points);
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < args->count_handles; i++) {
+ struct dma_fence_chain *chain;
+ struct dma_fence *fence;
+ uint64_t point;
+
+ fence = drm_syncobj_fence_get(syncobjs[i]);
+ chain = to_dma_fence_chain(fence);
+ if (chain) {
+ struct dma_fence *iter, *last_signaled = NULL;
+
+ dma_fence_chain_for_each(iter, fence) {
+ if (!iter)
+ break;
+ dma_fence_put(last_signaled);
+ last_signaled = dma_fence_get(iter);
+ if
(!to_dma_fence_chain(last_signaled)->prev_seqno)
+ /* It is most likely that timeline has
+* unorder points. */
+ break;
+ }
+ point = dma_fence_is_signaled(last_signaled) ?
+ last_signaled->seqno :
+ to_dma_fence_chain(last_signaled)->prev_seqno;
+ dma_fence_put(last_signaled);
+ } else {
+ point = 0;
+ }
+ ret = copy_to_user([i], , sizeof(uint64_t));
+ ret = ret ? -EFAULT : 0;
+ if (ret)
+ break;
+ }
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 44ebcdd9bd1d..c62be0840ba5 100644
--- a/include/uapi/drm/drm.h
+++
[PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4
From: Christian König
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace
Signed-off-by: Christian König
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_syncobj.c | 39 +++
include/drm/drm_syncobj.h | 5 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 5329e66598c6..19a9ce638119 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -122,6 +122,45 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
*syncobj,
spin_unlock(>lock);
}
+/**
+ * drm_syncobj_add_point - add new timeline point to the syncobj
+ * @syncobj: sync object to add timeline point do
+ * @chain: chain node to use to add the point
+ * @fence: fence to encapsulate in the chain node
+ * @point: sequence number to use for the point
+ *
+ * Add the chain node as new timeline point to the syncobj.
+ */
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+ struct dma_fence_chain *chain,
+ struct dma_fence *fence,
+ uint64_t point)
+{
+ struct syncobj_wait_entry *cur, *tmp;
+ struct dma_fence *prev;
+
+ dma_fence_get(fence);
+
+ spin_lock(>lock);
+
+ prev = drm_syncobj_fence_get(syncobj);
+ /* You are adding an unorder point to timeline, which could cause
payload returned from query_ioctl is 0! */
+ WARN_ON_ONCE(prev && prev->seqno >= point);
+ dma_fence_chain_init(chain, prev, fence, point);
+ rcu_assign_pointer(syncobj->fence, >base);
+
+ list_for_each_entry_safe(cur, tmp, >cb_list, node) {
+ list_del_init(>node);
+ syncobj_wait_syncobj_func(syncobj, cur);
+ }
+ spin_unlock(>lock);
+
+ /* Walk the chain once to trigger garbage collection */
+ dma_fence_chain_for_each(fence, prev);
+ dma_fence_put(prev);
+}
+EXPORT_SYMBOL(drm_syncobj_add_point);
+
/**
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 0311c9fdbd2f..6cf7243a1dc5 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -27,6 +27,7 @@
#define __DRM_SYNCOBJ_H__
#include
+#include
struct drm_file;
@@ -112,6 +113,10 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
u32 handle);
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+ struct dma_fence_chain *chain,
+ struct dma_fence *fence,
+ uint64_t point);
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence);
int drm_syncobj_find_fence(struct drm_file *file_private,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] dma-buf: add new dma_fence_chain container v7
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node
v6: add __rcu for member 'prev' of struct chain node
v7: fix rcu warnings from kernel robot
Signed-off-by: Christian König
Cc: Lionel Landwerlin
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/dma-fence-chain.c | 241 ++
include/linux/dma-fence-chain.h | 81 ++
3 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dma-fence-chain.c
create mode 100644 include/linux/dma-fence-chain.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..c729f98a7bd3
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,241 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct dma_fence_chain
*chain)
+{
+ struct dma_fence *prev;
+
+ rcu_read_lock();
+ prev = dma_fence_get_rcu_safe(>prev);
+ rcu_read_unlock();
+ return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL if we are at
+ * the end of the chain. Garbage collects chain nodes which are already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain, *prev_chain;
+ struct dma_fence *prev, *replacement, *tmp;
+
+ chain = to_dma_fence_chain(fence);
+ if (!chain) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ while ((prev = dma_fence_chain_get_prev(chain))) {
+
+ prev_chain = to_dma_fence_chain(prev);
+ if (prev_chain) {
+ if (!dma_fence_is_signaled(prev_chain->fence))
+ break;
+
+ replacement = dma_fence_chain_get_prev(prev_chain);
+ } else {
+ if (!dma_fence_is_signaled(prev))
+ break;
+
+ replacement = NULL;
+ }
+
+ tmp = cmpxchg((void **)>prev, (void *)prev, (void
*)replacement);
+ if (tmp == prev)
+ dma_fence_put(tmp);
+ else
+ dma_fence_put(replacement);
+ dma_fence_put(prev);
+ }
+
+ dma_fence_put(fence);
+ return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno)
+{
+ struct dma_fence_chain *chain;
+
+ if (!seqno)
+ return 0;
+
+ chain =
[PATCH 3/9] drm/syncobj: add support for timeline point wait v8
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 153 ++---
include/uapi/drm/drm.h | 15
4 files changed, 143 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 251d67e04c2d..331ac6225b58 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,6 +182,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 687943df58e1..c984654646fa 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -688,6 +688,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 19a9ce638119..eae51978cda4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -61,6 +61,7 @@ struct syncobj_wait_entry {
struct task_struct *task;
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
+ u64point;
};
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
@@ -95,6 +96,8 @@ EXPORT_SYMBOL(drm_syncobj_find);
static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait)
{
+ struct dma_fence *fence;
+
if (wait->fence)
return;
@@ -103,11 +106,15 @@ static void drm_syncobj_fence_add_wait(struct drm_syncobj
*syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence)
- wait->fence = dma_fence_get(
- rcu_dereference_protected(syncobj->fence, 1));
- else
+ fence = dma_fence_get(rcu_dereference_protected(syncobj->fence, 1));
+ if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
+ dma_fence_put(fence);
list_add_tail(>node, >cb_list);
+ } else if (!fence) {
+ wait->fence = dma_fence_get_stub();
+ } else {
+ wait->fence = fence;
+ }
spin_unlock(>lock);
}
@@ -149,10 +156,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
dma_fence_chain_init(chain, prev, fence, point);
rcu_assign_pointer(syncobj->fence, >base);
- list_for_each_entry_safe(cur, tmp, >cb_list, node) {
- list_del_init(>node);
+ list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
spin_unlock(>lock);
/* Walk the chain once to trigger garbage collection */
@@ -184,10 +189,8 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
rcu_assign_pointer(syncobj->fence, fence);
if (fence != old_fence) {
- list_for_each_entry_safe(cur, tmp, >cb_list, node) {
- list_del_init(>node);
+ list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
}
spin_unlock(>lock);
@@ -644,13 +647,27 @@ static void syncobj_wait_fence_func(struct dma_fence
